1 |
On Tue, 28 Jan 2014 12:37:40 +0000 |
2 |
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote: |
3 |
|
4 |
> Please set your client not to embed people's email addresses in your |
5 |
> responses: it's spambait in web archives. Thanks. |
6 |
|
7 |
It's as much a spambait as it is listed in the From: header on the web |
8 |
archives; in other words, it are the web archives that need to fix this. |
9 |
|
10 |
Unless you want to keep spamming this sentence to everyone you talk to; |
11 |
and/or besides that, wasting your time on changing the quote lines. |
12 |
|
13 |
> Tom Wijsman wrote: |
14 |
> "moves us closer to bleeding-edge" is completely useless; |
15 |
|
16 |
It might be for you; depends, but not completely useless in general. |
17 |
|
18 |
> there are already an immense amount of ways to run more up to date |
19 |
> software, or you wouldn't have users already doing it. That doesn't |
20 |
> detract from the merits of the stabilisation process, which you |
21 |
> apparently don't get despite trumpeting your QA membership. |
22 |
> |
23 |
> The latter leaves me rather worried, to be frank. |
24 |
|
25 |
For there to be a stabilization process there need to be people; and |
26 |
thus, other solutions need to be explored. And thus some of those other |
27 |
solutions are detracting from the merits of the stabilization process. |
28 |
|
29 |
> > > > > I don't think that's what was being proposed, though. The |
30 |
> > > > > question was really the old complaint about slow |
31 |
> > > > > architectures; the "-* arch" solution sounds like the most |
32 |
> > > > > reasonable definition of "dropping" keywords, in the absence |
33 |
> > > > > of AT communication otherwise. |
34 |
> > > > |
35 |
> > > > Dropping keywords and specifying -* are a world apart of each |
36 |
> > > > other. |
37 |
> > > |
38 |
> > > That's why it's in quotes. |
39 |
> > |
40 |
> > Why is there at all if you intend it to be irrelevant to this |
41 |
> > thread? |
42 |
> |
43 |
> What? OFC it's relevant; it's just not dropping keywords, it's |
44 |
> dropping the ebuild from most archs, and leaving it in-place for |
45 |
> those which haven't stabilised a newer version. |
46 |
|
47 |
Dropping a keyword or ebuild means removing it; -* is a step further |
48 |
than that, and thus beyond the scope of this thread. It is there to |
49 |
indicate the package does not work on that particular architecture, it |
50 |
is a world apart from just dropping the keyword; hence it is irrelevant. |
51 |
|
52 |
> > > > The former means that it is not ready for wide stable or testing |
53 |
> > > > users, the latter means that it has been tested to not work at |
54 |
> > > > all; furthermore, we need to explicitly specify which arches in |
55 |
> > > > that case. |
56 |
> > > |
57 |
> > > You're missing the point, again. The question was what does |
58 |
> > > "dropping keywords" mean, when the maintainer has stabilised a |
59 |
> > > newer version on the arch/s s/he has available, but feels that |
60 |
> > > slower archs are holding up that process. |
61 |
> > |
62 |
> > Where is that question? |
63 |
> |
64 |
> *sigh* Are you really saying you don't understand the point of this |
65 |
> thread? It's yaf "slow archs are slow and i don't want them" |
66 |
> complaint, which recur every year or so, going back at least 10, |
67 |
> though we haven't had this for the last couple of years that I |
68 |
> recall; Gentoo has moved pretty quickly. |
69 |
> |
70 |
> It comes up more from openrc, imo, since the upstream maintainer is |
71 |
> also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds |
72 |
> for a core system package. That's an old argument, though, and his |
73 |
> call. I mention it simply because the QA process for that package is |
74 |
> squashed, in comparison to its importance within the framework. Git |
75 |
> ebuilds are not the same as distribution stabilisation. |
76 |
> |
77 |
> No, I'm not expecting it to change. I'm just pointing out that it's |
78 |
> very different to the other packages in the tree (being in-house it |
79 |
> hasn't gone through any upstream testing at all, since Gentoo is |
80 |
> effectively the upstream), and a case could be made that in fact its |
81 |
> QA needs better handling, rather than changing policy to the detriment |
82 |
> of archs across the board in response to this complaint. |
83 |
|
84 |
So, where is that question? |
85 |
|
86 |
> > > I'm slightly at a loss as to why it's such a big deal to just |
87 |
> > > leave the old ebuild as-is, given that anyone on a stabled arch |
88 |
> > > should upgrade automatically. |
89 |
> > |
90 |
> > It is when you are running the arch that only has the old version. |
91 |
> |
92 |
> FGS that's up the AT and their users to collaborate on them with. It's |
93 |
> not up to some external "developer" to tell the AT which ebuilds are |
94 |
> stable for their arch: that's their *job*. The ebuild dev only gets to |
95 |
> request testing, just like users only get to request a version bump. |
96 |
|
97 |
Sometimes users get to put it in their overlay because their version |
98 |
bump, or even a new package request, yields no succes; in the same way, |
99 |
sometimes there are no people that fill in the *job*, hence we come to |
100 |
the point of this thread to look into options to change it. |
101 |
|
102 |
> > > But given that the maintainer feels they don't want that old |
103 |
> > > ebuild around, and that the arch in question has not got round to |
104 |
> > > testing the new one, for whatever reason (it's their call, after |
105 |
> > > all, as to how their arch progresses), instead of simply removing |
106 |
> > > that ebuild, or bumping it to unstable (which makes zero sense), |
107 |
> > > just leave it stable on the slow arch/s in question, and remove |
108 |
> > > the others. |
109 |
> > |
110 |
> > There are situations (security, stability, incompatibility) where |
111 |
> > keeping it in place becomes a much harder task; at which point, |
112 |
> > removal is bound to happen. At that point, such action is required. |
113 |
> > |
114 |
> > It becomes faster than you think; if you depend on a library, and |
115 |
> > the compatible range of that library gets wiped by a security bug, |
116 |
> > your package will suddenly depend on an incompatible newer |
117 |
> > stabilized version of the library at which point you are up for |
118 |
> > either a lot of hard work or plain out starting the progress of |
119 |
> > masking and removing it. |
120 |
> |
121 |
> Security bugs have a separate process, as you know, |
122 |
|
123 |
It affects the visibility of the package or its ebuilds. |
124 |
|
125 |
> and reverse dep checking is a standard thing. |
126 |
|
127 |
On new stabilizations, yes; those that were around for a long time, no. |
128 |
|
129 |
> No-one said maintaining the tree is easy: that's why there's so many |
130 |
> of you collaborating on it, rather than a team of 5. Nor that you |
131 |
> can't mask ever: just that the standard stabilisation cycle should |
132 |
> not involve you removing the prior stable ebuild on an arch before a |
133 |
> newer version is stabilised. |
134 |
> |
135 |
> The latter becomes an issue when someone wants to remove the ebuild, |
136 |
> for whatever reason. If you do find yourself wanting to remove the |
137 |
> ebuild, and it's still not stable, then just remove the keywords on |
138 |
> all archs except the specific slow ones. There must be a bug for |
139 |
> stabilisation already, so note it there, and get on with your life |
140 |
> without whinging. It's not your problem, it's the AT's: let them get |
141 |
> on with it without you messing up their arch with no warning. |
142 |
|
143 |
An AT problem can quickly become a problem on the distribution level; |
144 |
if it weren't a problem, we'd not even get bothered or care. |
145 |
|
146 |
For example, it causes bugs that depend on the stabilization bug to get |
147 |
blocked; delaying progress of bugs that depend on it. There might be |
148 |
other reasons listed in the previous thread regarding the minor arches. |
149 |
|
150 |
> > > This seems like a rarity, but when it's an issue, people get |
151 |
> > > annoyed on either side. The solution proposed by the ARM team, |
152 |
> > |
153 |
> > Where is this solution? |
154 |
> |
155 |
> What? Pay attention: "-* arch" |
156 |
|
157 |
It's irrelevant to this thread. So, maybe "arch" was meant instead? |
158 |
|
159 |
> > > seems like a simple way round, and indicates clearly to anyone |
160 |
> > > perusing the ebuild, that a newer version needs stabling on the |
161 |
> > > "slow" archs. |
162 |
> > |
163 |
> > Masking works fine for that too; what this does is make clear to the |
164 |
> > user that (1) the current stable version has breakage for a specific |
165 |
> > reason, (2) a newer stable version is not yet available and (3) |
166 |
> > that the user can choose to keep the breakage or upgrade to an |
167 |
> > unstable version. |
168 |
> |
169 |
> It's more work, and there's no reason for it: "-* arch" is a lot |
170 |
> quicker, simple to do and blindingly obvious as to its intent. |
171 |
|
172 |
But also plain wrong, see above; maybe "arch" is thus meant, but we are |
173 |
already doing that today. The problem here isn't the other listed |
174 |
arches, but rather the arch itself; as it blocks progress, see above. |
175 |
|
176 |
> Note we are not talking about "breakage" for security (a separate |
177 |
> process and team are in place for that.) |
178 |
|
179 |
It affects the visibility, as I mentioned before. |
180 |
|
181 |
> It indicates 1) The arch is lagging on this ebuild and 2) there is a |
182 |
> newer ebuild which the maintainer has stabilised on other archs, so |
183 |
> work on that if you want a newer version, and *know that the work |
184 |
> will be much welcomed*, and 3) the user can unmask a newer ebuild |
185 |
> should they wish to (and thus feedback for stabilisation.) |
186 |
|
187 |
3) The newer ebuild is unmasked, this means accepting the keyword? |
188 |
|
189 |
> It's much better metadata, easily detectable via script, in the right |
190 |
> place: the ebuild, not a profile mask file somewhere in the stack. If |
191 |
> we agree on it as a mechanism (and I still have not seen why not, for |
192 |
> the case that started this thread and other standard cases) then it's |
193 |
> trivial for portage/pkgcore to flag it in output, leading to better |
194 |
> user feedback and the chance of quicker stabilisation. |
195 |
|
196 |
That stack can very well be the profile directory of the arch team, |
197 |
which is a rather good place for this metadata. |
198 |
|
199 |
> > > By all means, raise technical objections; just not a philosophical |
200 |
> > > one. |
201 |
> > |
202 |
> > Where are these philosophical objections? |
203 |
> |
204 |
> All over the shop. "Where is this solution" |
205 |
|
206 |
If I tell you to "check out my solution"; then which one would that be? |
207 |
|
208 |
I've given several through-out the thread; if you were to pick one, |
209 |
that would merely be an assumption. Thus this is an actual question, |
210 |
rather than something philosophical; it makes the discussion harder if |
211 |
you refer to matters using generic keywords instead of being specific. |
212 |
|
213 |
> "Please point out X" instead of simply reading what is in front of |
214 |
> you |
215 |
|
216 |
Where did I use this exact wording? It's probably for a good reason to |
217 |
get something clarified; clarifications are natural in a discussion, |
218 |
you can't expect other individuals to fully understand each other. |
219 |
|
220 |
> along with digression about the nature of software, the |
221 |
> development process and how things could be considered, but very |
222 |
> little practical insight, IMO, resulting in frustrated responses, as |
223 |
> usual. |
224 |
|
225 |
What are you talking about? IMO, this misses reference, as usual. |
226 |
|
227 |
> Again, what is so wrong with removing keywords for all archs except |
228 |
> the ones which have not caught up and stabilised, instead of removing |
229 |
> the ebuild? (Or indeed forcing people through the whole mask cycle |
230 |
> without good cause.) |
231 |
|
232 |
Nothing, it is just irrelevant to this thread; it is something we |
233 |
already do, it doesn't address with the problem put forward in this |
234 |
thread as well as that it forms no actual solution to the problem here. |
235 |
|
236 |
> = |
237 |
> I concur that "QA should be focusing on making stable, actually |
238 |
> stable, not more bleeding edge." That's not a "performance" issue as |
239 |
> you put it, except in management nuspeek. It's the whole bloody point |
240 |
> of the distro, in overarching terms: to test and stabilise robust |
241 |
> ebuilds. That process is what leads to better software, not staying |
242 |
> at the "bleeding-edge" and forgetting about robustness since "a new |
243 |
> version is out." |
244 |
|
245 |
A process needs people to fulfill it. |
246 |
|
247 |
> There's plenty of ways to stay on the bleeding-edge; throwing out the |
248 |
> baby with the bathwater will only tip you over it, and bork the distro |
249 |
> for the rest of us, and everyone down the line. |
250 |
|
251 |
Why do we have the baby in the first place? |
252 |
|
253 |
> I'm slightly worried as to the composition of the QA team now, where I |
254 |
> wasn't before. "QA comes in to reorganize our efforts as well as |
255 |
> policy" is over-reaching afaic. |
256 |
|
257 |
Consider starting a new thread about the role and/or composition of the |
258 |
QA team if that is a concern. |
259 |
|
260 |
> But a QA team only interested in the bleeding-edge, |
261 |
|
262 |
Where is there an implication that we are /only/ interested in that? |
263 |
|
264 |
> or even /thinking/ that losing the stable tree will improve either |
265 |
> quality or the distro? *shudder* |
266 |
|
267 |
Where is there an implication where we think we /should/ lose it? |
268 |
|
269 |
> I thought QA was a hard team to get onto, and not because it's a |
270 |
> clique, but because it's central to the mission. Oh well. |
271 |
|
272 |
s/QA/an arch team/ |
273 |
|
274 |
-- |
275 |
With kind regards, |
276 |
|
277 |
Tom Wijsman (TomWij) |
278 |
Gentoo Developer |
279 |
|
280 |
E-mail address : TomWij@g.o |
281 |
GPG Public Key : 6D34E57D |
282 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |