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: Tue, 28 Jan 2014 12:25:12
In Reply to: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Tom Wijsman
1 Please set your client not to embed people's email addresses in your
2 responses: it's spambait in web archives. Thanks.
4 Tom Wijsman wrote:
5 > "Steven J. Long" wrote:
6 > > Tom Wijsman wrote:
7 > > > "Steven J. Long" wrote:
8 > > > > What? Without a stable tree, Gentoo is useless afaic.
9 > > >
10 > > > It moves us closer to upstream releases, a little more bleeding
11 > > > edge; a lot of users and developers run that already, it is found
12 > > > to be useful.
13 > >
14 > > What? More vague. As are many of your philosophical statements in
15 > > later and prior mails, so I'll ignore those.
16 >
17 > It is reality; and thus, without a stable tree, Gentoo is still useful
18 > for a lot of users and developers. What is vague about that?
20 "moves us closer to bleeding-edge" is completely useless; there are
21 already an immense amount of ways to run more up to date software, or
22 you wouldn't have users already doing it. That doesn't detract from
23 the merits of the stabilisation process, which you apparently don't get
24 despite trumpeting your QA membership.
26 The latter leaves me rather worried, to be frank.
28 > > > > I don't think that's what was being proposed, though. The
29 > > > > question was really the old complaint about slow architectures;
30 > > > > the "-* arch" solution sounds like the most reasonable definition
31 > > > > of "dropping" keywords, in the absence of AT communication
32 > > > > otherwise.
33 > > >
34 > > > Dropping keywords and specifying -* are a world apart of each other.
35 > >
36 > > That's why it's in quotes.
37 >
38 > Why is there at all if you intend it to be irrelevant to this thread?
40 What? OFC it's relevant; it's just not dropping keywords, it's dropping
41 the ebuild from most archs, and leaving it in-place for those which
42 haven't stabilised a newer version.
44 You could have worked that out: in fact I assumed you had since it's
45 been stated several times. Thanks for the show of "good faith" you
46 demand from users: always good to have an example to follow.
48 > > > The former means that it is not ready for wide stable or testing
49 > > > users, the latter means that it has been tested to not work at all;
50 > > > furthermore, we need to explicitly specify which arches in that
51 > > > case.
52 > >
53 > > You're missing the point, again. The question was what does "dropping
54 > > keywords" mean, when the maintainer has stabilised a newer version on
55 > > the arch/s s/he has available, but feels that slower archs are holding
56 > > up that process.
57 >
58 > Where is that question?
60 *sigh* Are you really saying you don't understand the point of this
61 thread? It's yaf "slow archs are slow and i don't want them" complaint,
62 which recur every year or so, going back at least 10, though we haven't
63 had this for the last couple of years that I recall; Gentoo has moved
64 pretty quickly.
66 It comes up more from openrc, imo, since the upstream maintainer is
67 also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds
68 for a core system package. That's an old argument, though, and his call.
69 I mention it simply because the QA process for that package is squashed,
70 in comparison to its importance within the framework. Git ebuilds are
71 not the same as distribution stabilisation.
73 No, I'm not expecting it to change. I'm just pointing out that it's
74 very different to the other packages in the tree (being in-house it
75 hasn't gone through any upstream testing at all, since Gentoo is
76 effectively the upstream), and a case could be made that in fact its
77 QA needs better handling, rather than changing policy to the detriment
78 of archs across the board in response to this complaint.
80 > > I'm slightly at a loss as to why it's such a big deal to just leave
81 > > the old ebuild as-is, given that anyone on a stabled arch should
82 > > upgrade automatically.
83 >
84 > It is when you are running the arch that only has the old version.
86 FGS that's up the AT and their users to collaborate on them with. It's
87 not up to some external "developer" to tell the AT which ebuilds are
88 stable for their arch: that's their *job*. The ebuild dev only gets to
89 request testing, just like users only get to request a version bump.
91 > > But given that the maintainer feels they don't want that old ebuild
92 > > around, and that the arch in question has not got round to testing the
93 > > new one, for whatever reason (it's their call, after all, as to how
94 > > their arch progresses), instead of simply removing that ebuild, or
95 > > bumping it to unstable (which makes zero sense), just leave it stable
96 > > on the slow arch/s in question, and remove the others.
97 >
98 > There are situations (security, stability, incompatibility) where
99 > keeping it in place becomes a much harder task; at which point, removal
100 > is bound to happen. At that point, such action is required.
101 >
102 > It becomes faster than you think; if you depend on a library, and the
103 > compatible range of that library gets wiped by a security bug, your
104 > package will suddenly depend on an incompatible newer stabilized
105 > version of the library at which point you are up for either a lot of
106 > hard work or plain out starting the progress of masking and removing it.
108 Security bugs have a separate process, as you know, and reverse dep
109 checking is a standard thing. No-one said maintaining the tree is easy:
110 that's why there's so many of you collaborating on it, rather than a team
111 of 5. Nor that you can't mask ever: just that the standard stabilisation
112 cycle should not involve you removing the prior stable ebuild on an arch
113 before a newer version is stabilised.
115 The latter becomes an issue when someone wants to remove the ebuild, for
116 whatever reason. If you do find yourself wanting to remove the ebuild,
117 and it's still not stable, then just remove the keywords on all archs
118 except the specific slow ones. There must be a bug for stabilisation
119 already, so note it there, and get on with your life without whinging.
120 It's not your problem, it's the AT's: let them get on with it without
121 you messing up their arch with no warning.
123 If it's a question of who'll field the bug-reports, change the maintainer
124 if that's possible per-ebuild, or "auto"-reassign.
125 (eg use a new alias if more than one arch, or the arch alias if only one.)
127 > > This seems like a rarity, but when it's an issue, people get annoyed
128 > > on either side. The solution proposed by the ARM team,
129 >
130 > Where is this solution?
132 What? Pay attention: "-* arch"
134 > > seems like a simple way round, and indicates clearly to anyone
135 > > perusing the ebuild, that a newer version needs stabling on the
136 > > "slow" archs.
137 >
138 > Masking works fine for that too; what this does is make clear to the
139 > user that (1) the current stable version has breakage for a specific
140 > reason, (2) a newer stable version is not yet available and (3) that the
141 > user can choose to keep the breakage or upgrade to an unstable version.
143 It's more work, and there's no reason for it: "-* arch" is a lot quicker,
144 simple to do and blindingly obvious as to its intent. Note we are not
145 talking about "breakage" for security (a separate process and team are in
146 place for that.) It indicates 1) The arch is lagging on this ebuild and
147 2) there is a newer ebuild which the maintainer has stabilised on other
148 archs, so work on that if you want a newer version, and *know that the
149 work will be much welcomed*, and 3) the user can unmask a newer ebuild
150 should they wish to (and thus feedback for stabilisation.)
152 It's much better metadata, easily detectable via script, in the right
153 place: the ebuild, not a profile mask file somewhere in the stack. If
154 we agree on it as a mechanism (and I still have not seen why not, for
155 the case that started this thread and other standard cases) then it's
156 trivial for portage/pkgcore to flag it in output, leading to better
157 user feedback and the chance of quicker stabilisation.
159 > > By all means, raise technical objections; just not a philosophical
160 > > one.
161 >
162 > Where are these philosophical objections?
164 All over the shop. "Where is this solution" "Please point out X" instead
165 of simply reading what is in front of you, along with digression about
166 the nature of software, the development process and how things could be
167 considered, but very little practical insight, IMO, resulting in
168 frustrated responses, as usual.
170 "Good programming is not learnt from generalities."
172 Again, what is so wrong with removing keywords for all archs except
173 the ones which have not caught up and stabilised, instead of removing
174 the ebuild? (Or indeed forcing people through the whole mask cycle
175 without good cause.)
177 It does the same thing, without screwing other archs the maintainer has
178 no interest in, and package.mask is still an option for trickier cases,
179 but we're not talking about those, since there are processes in place
180 for them, and communication is _required_ to sort them out.
182 For the standard case, where otherwise the maintainer would drop the
183 ebuild altogether, and thus bork the arch and its users, or be "forced"
184 to maintain an ebuild, it really does seem like a complete no-brainer.
186 =
187 I concur that "QA should be focusing on making stable, actually stable,
188 not more bleeding edge." That's not a "performance" issue as you put it,
189 except in management nuspeek. It's the whole bloody point of the distro,
190 in overarching terms: to test and stabilise robust ebuilds. That process
191 is what leads to better software, not staying at the "bleeding-edge"
192 and forgetting about robustness since "a new version is out."
194 There's plenty of ways to stay on the bleeding-edge; throwing out the
195 baby with the bathwater will only tip you over it, and bork the distro
196 for the rest of us, and everyone down the line.
198 I'm slightly worried as to the composition of the QA team now, where I
199 wasn't before. "QA comes in to reorganize our efforts as well as policy"
200 is over-reaching afaic. But a QA team only interested in the
201 bleeding-edge, or even /thinking/ that losing the stable tree will
202 improve either quality or the distro? *shudder*
204 I thought QA was a hard team to get onto, and not because it's a clique,
205 but because it's central to the mission. Oh well.
206 --
207 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


Subject Author
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Alan McKinnon <alan.mckinnon@×××××.com>
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Tom Wijsman <TomWij@g.o>