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

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

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.

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

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

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.

If you must do anything, which I'm unpersuaded about, but it's your
call, as maintainer.

This seems like a rarity, but when it's an issue, people get annoyed on
either side. The solution proposed by the ARM team, seems like a simple
way round, and indicates clearly to anyone perusing the ebuild, that a
newer version needs stabling on the "slow" archs.

By all means, raise technical objections; just not a philosophical one.

Again this is a minor issue afaic, in terms of frequency, need for
change, and how difficult it is to solve. Resolve it, and let's get back
to the fun stuff instead.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)