[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steven J. Long]

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

Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > Tom Wijsman wrote:
> > > "Steven J. Long" wrote:
> > > > What? Without a stable tree, Gentoo is useless afaic.
> > >
> > > It moves us closer to upstream releases, a little more bleeding
> > > edge; a lot of users and developers run that already, it is found
> > > to be useful.
> >
> > What? More vague. As are many of your philosophical statements in
> > later and prior mails, so I'll ignore those.
>
> It is reality; and thus, without a stable tree, Gentoo is still useful
> for a lot of users and developers. What is vague about that?

"moves us closer to bleeding-edge" is completely useless; 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.
 
> > > > 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.

You could have worked that out: in fact I assumed you had since it's
been stated several times. Thanks for the show of "good faith" you
demand from users: always good to have an example to follow.

> > > 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.

> > 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.

> > 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, and reverse dep
checking is a standard thing. 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.

If it's a question of who'll field the bug-reports, change the maintainer
if that's possible per-ebuild, or "auto"-reassign.
(eg use a new alias if more than one arch, or the arch alias if only one.)

> > 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"

> > 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. Note we are not
talking about "breakage" for security (a separate process and team are in
place for that.) 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.)

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.

> > By all means, raise technical objections; just not a philosophical
> > one.
>
> Where are these philosophical objections?

All over the shop. "Where is this solution" "Please point out X" instead
of simply reading what is in front of you, 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.

"Good programming is not learnt from generalities."

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.)

It does the same thing, without screwing other archs the maintainer has
no interest in, and package.mask is still an option for trickier cases,
but we're not talking about those, since there are processes in place
for them, and communication is _required_ to sort them out.

For the standard case, where otherwise the maintainer would drop the
ebuild altogether, and thus bork the arch and its users, or be "forced"
to maintain an ebuild, it really does seem like a complete no-brainer.

=
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."

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.

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. But a QA team only interested in the
bleeding-edge, or even /thinking/ that losing the stable tree will
improve either quality or the distro? *shudder*

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.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)