Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Fri, 24 Jan 2014 10:33:52
In Reply to: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Tom Wijsman
1 Tom Wijsman wrote:
2 > "Steven J. Long" wrote:
3 > > What? Without a stable tree, Gentoo is useless afaic.
4 >
5 > It moves us closer to upstream releases, a little more bleeding edge; a
6 > lot of users and developers run that already, it is found to be useful.
8 What? More vague. As are many of your philosophical statements in later
9 and prior mails, so I'll ignore those.
11 > > I don't think that's what was being proposed, though. The question was
12 > > really the old complaint about slow architectures; the "-* arch"
13 > > solution sounds like the most reasonable definition of "dropping"
14 > > keywords, in the absence of AT communication otherwise.
15 >
16 > Dropping keywords and specifying -* are a world apart of each other.
18 That's why it's in quotes.
20 > The former means that it is not ready for wide stable or testing users,
21 > the latter means that it has been tested to not work at all;
22 > furthermore, we need to explicitly specify which arches in that case.
24 You're missing the point, again. The question was what does "dropping
25 keywords" mean, when the maintainer has stabilised a newer version on
26 the arch/s s/he has available, but feels that slower archs are holding
27 up that process. I'm slightly at a loss as to why it's such a big deal
28 to just leave the old ebuild as-is, given that anyone on a stabled
29 arch should upgrade automatically.
31 But given that the maintainer feels they don't want that old ebuild
32 around, and that the arch in question has not got round to testing the
33 new one, for whatever reason (it's their call, after all, as to how
34 their arch progresses), instead of simply removing that ebuild, or
35 bumping it to unstable (which makes zero sense), just leave it stable
36 on the slow arch/s in question, and remove the others.
38 If you must do anything, which I'm unpersuaded about, but it's your
39 call, as maintainer.
41 This seems like a rarity, but when it's an issue, people get annoyed on
42 either side. The solution proposed by the ARM team, seems like a simple
43 way round, and indicates clearly to anyone perusing the ebuild, that a
44 newer version needs stabling on the "slow" archs.
46 By all means, raise technical objections; just not a philosophical one.
48 Again this is a minor issue afaic, in terms of frequency, need for
49 change, and how difficult it is to solve. Resolve it, and let's get back
50 to the fun stuff instead.
51 --
52 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


Subject Author
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Tom Wijsman <TomWij@g.o>