On Tue, 28 Jan 2014 12:37:40 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Please set your client not to embed people's email addresses in your
> responses: it's spambait in web archives. Thanks.

It's as much a spambait as it is listed in the From: header on the web
archives; in other words, it are the web archives that need to fix this.

Unless you want to keep spamming this sentence to everyone you talk to;
and/or besides that, wasting your time on changing the quote lines.

> Tom Wijsman wrote:
> "moves us closer to bleeding-edge" is completely useless;

It might be for you; depends, but not completely useless in general.

> there are already an immense amount of ways to run more up to date
> software, or you wouldn't have users already doing it. That doesn't
> detract from the merits of the stabilisation process, which you
> apparently don't get despite trumpeting your QA membership.
> 
> The latter leaves me rather worried, to be frank.

For there to be a stabilization process there need to be people; and
thus, other solutions need to be explored. And thus some of those other
solutions are detracting from the merits of the stabilization process.

> > > > > I don't think that's what was being proposed, though. The
> > > > > question was really the old complaint about slow
> > > > > architectures; the "-* arch" solution sounds like the most
> > > > > reasonable definition of "dropping" keywords, in the absence
> > > > > of AT communication otherwise.
> > > > 
> > > > Dropping keywords and specifying -* are a world apart of each
> > > > other.
> > > 
> > > That's why it's in quotes.
> > 
> > Why is there at all if you intend it to be irrelevant to this
> > thread?
> 
> What? OFC it's relevant; it's just not dropping keywords, it's
> dropping the ebuild from most archs, and leaving it in-place for
> those which haven't stabilised a newer version.

Dropping a keyword or ebuild means removing it; -* is a step further
than that, and thus beyond the scope of this thread. It is there to
indicate the package does not work on that particular architecture, it
is a world apart from just dropping the keyword; hence it is irrelevant.

> > > > The former means that it is not ready for wide stable or testing
> > > > users, the latter means that it has been tested to not work at
> > > > all; furthermore, we need to explicitly specify which arches in
> > > > that case.
> > > 
> > > You're missing the point, again. The question was what does
> > > "dropping keywords" mean, when the maintainer has stabilised a
> > > newer version on the arch/s s/he has available, but feels that
> > > slower archs are holding up that process.
> > 
> > Where is that question? 
> 
> *sigh* Are you really saying you don't understand the point of this
> thread? It's yaf "slow archs are slow and i don't want them"
> complaint, which recur every year or so, going back at least 10,
> though we haven't had this for the last couple of years that I
> recall; Gentoo has moved pretty quickly.
> 
> It comes up more from openrc, imo, since the upstream maintainer is
> also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds
> for a core system package. That's an old argument, though, and his
> call. I mention it simply because the QA process for that package is
> squashed, in comparison to its importance within the framework. Git
> ebuilds are not the same as distribution stabilisation.
> 
> No, I'm not expecting it to change. I'm just pointing out that it's
> very different to the other packages in the tree (being in-house it
> hasn't gone through any upstream testing at all, since Gentoo is
> effectively the upstream), and a case could be made that in fact its
> QA needs better handling, rather than changing policy to the detriment
> of archs across the board in response to this complaint.

So, where is that question?

> > > I'm slightly at a loss as to why it's such a big deal to just
> > > leave the old ebuild as-is, given that anyone on a stabled arch
> > > should upgrade automatically.
> > 
> > It is when you are running the arch that only has the old version.
> 
> FGS that's up the AT and their users to collaborate on them with. It's
> not up to some external "developer" to tell the AT which ebuilds are
> stable for their arch: that's their *job*. The ebuild dev only gets to
> request testing, just like users only get to request a version bump.

Sometimes users get to put it in their overlay because their version
bump, or even a new package request, yields no succes; in the same way,
sometimes there are no people that fill in the *job*, hence we come to
the point of this thread to look into options to change it.

> > > But given that the maintainer feels they don't want that old
> > > ebuild around, and that the arch in question has not got round to
> > > testing the new one, for whatever reason (it's their call, after
> > > all, as to how their arch progresses), instead of simply removing
> > > that ebuild, or bumping it to unstable (which makes zero sense),
> > > just leave it stable on the slow arch/s in question, and remove
> > > the others.
> > 
> > There are situations (security, stability, incompatibility) where
> > keeping it in place becomes a much harder task; at which point,
> > removal is bound to happen. At that point, such action is required.
> > 
> > It becomes faster than you think; if you depend on a library, and
> > the compatible range of that library gets wiped by a security bug,
> > your package will suddenly depend on an incompatible newer
> > stabilized version of the library at which point you are up for
> > either a lot of hard work or plain out starting the progress of
> > masking and removing it.
> 
> Security bugs have a separate process, as you know,

It affects the visibility of the package or its ebuilds.

> and reverse dep checking is a standard thing.

On new stabilizations, yes; those that were around for a long time, no.

> No-one said maintaining the tree is easy: that's why there's so many
> of you collaborating on it, rather than a team of 5. Nor that you
> can't mask ever: just that the standard stabilisation cycle should
> not involve you removing the prior stable ebuild on an arch before a
> newer version is stabilised.
> 
> The latter becomes an issue when someone wants to remove the ebuild,
> for whatever reason. If you do find yourself wanting to remove the
> ebuild, and it's still not stable, then just remove the keywords on
> all archs except the specific slow ones. There must be a bug for
> stabilisation already, so note it there, and get on with your life
> without whinging. It's not your problem, it's the AT's: let them get
> on with it without you messing up their arch with no warning.

An AT problem can quickly become a problem on the distribution level;
if it weren't a problem, we'd not even get bothered or care.

For example, it causes bugs that depend on the stabilization bug to get
blocked; delaying progress of bugs that depend on it. There might be
other reasons listed in the previous thread regarding the minor arches.

> > > This seems like a rarity, but when it's an issue, people get
> > > annoyed on either side. The solution proposed by the ARM team,
> > 
> > Where is this solution?
> 
> What? Pay attention: "-* arch"

It's irrelevant to this thread. So, maybe "arch" was meant instead?

> > > seems like a simple way round, and indicates clearly to anyone
> > > perusing the ebuild, that a newer version needs stabling on the
> > > "slow" archs.
> > 
> > Masking works fine for that too; what this does is make clear to the
> > user that (1) the current stable version has breakage for a specific
> > reason, (2) a newer stable version is not yet available and (3)
> > that the user can choose to keep the breakage or upgrade to an
> > unstable version.
> 
> It's more work, and there's no reason for it: "-* arch" is a lot
> quicker, simple to do and blindingly obvious as to its intent.

But also plain wrong, see above; maybe "arch" is thus meant, but we are
already doing that today. The problem here isn't the other listed
arches, but rather the arch itself; as it blocks progress, see above.

> Note we are not talking about "breakage" for security (a separate
> process and team are in place for that.)

It affects the visibility, as I mentioned before.

> It indicates 1) The arch is lagging on this ebuild and 2) there is a
> newer ebuild which the maintainer has stabilised on other archs, so
> work on that if you want a newer version, and *know that the work
> will be much welcomed*, and 3) the user can unmask a newer ebuild
> should they wish to (and thus feedback for stabilisation.)

3) The newer ebuild is unmasked, this means accepting the keyword?

> It's much better metadata, easily detectable via script, in the right
> place: the ebuild, not a profile mask file somewhere in the stack. If
> we agree on it as a mechanism (and I still have not seen why not, for
> the case that started this thread and other standard cases) then it's
> trivial for portage/pkgcore to flag it in output, leading to better
> user feedback and the chance of quicker stabilisation.

That stack can very well be the profile directory of the arch team,
which is a rather good place for this metadata.

> > > By all means, raise technical objections; just not a philosophical
> > > one.
> > 
> > Where are these philosophical objections?
> 
> All over the shop. "Where is this solution"

If I tell you to "check out my solution"; then which one would that be?

I've given several through-out the thread; if you were to pick one,
that would merely be an assumption. Thus this is an actual question,
rather than something philosophical; it makes the discussion harder if
you refer to matters using generic keywords instead of being specific.

> "Please point out X" instead of simply reading what is in front of
> you

Where did I use this exact wording? It's probably for a good reason to
get something clarified; clarifications are natural in a discussion,
you can't expect other individuals to fully understand each other.

> along with digression about the nature of software, the
> development process and how things could be considered, but very
> little practical insight, IMO, resulting in frustrated responses, as
> usual.

What are you talking about? IMO, this misses reference, as usual.

> Again, what is so wrong with removing keywords for all archs except
> the ones which have not caught up and stabilised, instead of removing
> the ebuild? (Or indeed forcing people through the whole mask cycle
> without good cause.)

Nothing, it is just irrelevant to this thread; it is something we
already do, it doesn't address with the problem put forward in this
thread as well as that it forms no actual solution to the problem here.

> =
> I concur that "QA should be focusing on making stable, actually
> stable, not more bleeding edge." That's not a "performance" issue as
> you put it, except in management nuspeek. It's the whole bloody point
> of the distro, in overarching terms: to test and stabilise robust
> ebuilds. That process is what leads to better software, not staying
> at the "bleeding-edge" and forgetting about robustness since "a new
> version is out."

A process needs people to fulfill it.

> There's plenty of ways to stay on the bleeding-edge; throwing out the
> baby with the bathwater will only tip you over it, and bork the distro
> for the rest of us, and everyone down the line.

Why do we have the baby in the first place?

> I'm slightly worried as to the composition of the QA team now, where I
> wasn't before. "QA comes in to reorganize our efforts as well as
> policy" is over-reaching afaic.

Consider starting a new thread about the role and/or composition of the
QA team if that is a concern.

> But a QA team only interested in the bleeding-edge,

Where is there an implication that we are /only/ interested in that?

> or even /thinking/ that losing the stable tree will improve either
> quality or the distro? *shudder*

Where is there an implication where we think we /should/ lose it?

> I thought QA was a hard team to get onto, and not because it's a
> clique, but because it's central to the mission. Oh well.

s/QA/an arch team/

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D