1 |
On Fri, Feb 14, 2014 Tom Wijsman wrote: |
2 |
> On Thu, 13 Feb 2014 "Steven J. Long" wrote: |
3 |
> |
4 |
> > > > Much better for the arch in question to field the bug, than tell |
5 |
> > > > the user there is no problem, and we don't care. That way you can |
6 |
> > > > get the user involved in stabilisation and AT via that bug, |
7 |
> > > > instead of turning them away with priggishness. |
8 |
> > > |
9 |
> > > Problems should be visible instead of hidden, as well as resolved. A |
10 |
> > > move in work means a move in work, further implications are yours... |
11 |
> > |
12 |
> > Very gnomic: nothing's being hidden in the above approach. |
13 |
> |
14 |
> Filing a bug but not telling the user about it is hiding the problem. |
15 |
|
16 |
"The bug" in the above is a bug the user on the arch in question has |
17 |
filed, which would be duped to the stabilisation bug (for the arch if |
18 |
there's more than one) so the user a) knows there's a newer version, |
19 |
which they can try out and help stabilise, and b) isn't kicked back |
20 |
with a WONTFIX, when they could be put in touch with the AT instead. |
21 |
|
22 |
So the user filed the bug in the first place: by definition they know |
23 |
about it. |
24 |
|
25 |
> > I can't make sense of the rest so I'll move on, noting only that it's |
26 |
> > up to the arch team, as to what _they_ decide to kick back to |
27 |
> > unstable. |
28 |
> |
29 |
> They need manpower to decide it, which they don't have. |
30 |
|
31 |
It's still no-one else's call, though given the approach it's easy |
32 |
enough to allow a further say 180 days after the "-* arch" marking, |
33 |
before the maintainer is allowed to mark the package as a whole |
34 |
unstable on the arch in question, given no movement. |
35 |
|
36 |
> > And that can work without a problem if we have a mechanism |
37 |
> > in place to relieve maintainers of those bugs. |
38 |
> |
39 |
> Such mechanism could be to assign those bug to the arch team, this idea |
40 |
> came up at FOSDEM; it won't solve the lack of manpower, but it will at |
41 |
> least relieve the maintainers and make the problem more visible. |
42 |
|
43 |
Exactly. What the AT does with it is their problem: if they don't move |
44 |
after another 180 days, they can't complain, but there's at least a more |
45 |
formal process, and there's no row, nor even discussion needed. You had |
46 |
a chance to stabilise, we've waited, and you've still got the stable |
47 |
ebuild in your tree, but now any users on your arch are going to get |
48 |
redirected to you, so you can discuss moving the package forward or |
49 |
bumping it to unstable. |
50 |
|
51 |
To me that makes the action something positive, rather than negative. |
52 |
Especially coupled with an indicator in the package manager output, |
53 |
similar to how unstable ebuilds are marked if you're running stable, |
54 |
or forced-rebuilds. That would spur more users to help, since they're |
55 |
using the package in question, and are on a slow arch. |
56 |
|
57 |
> > Personally I'd do it after 45 days to speed things up, and let the |
58 |
> > ATs concerned, take the bug as and when (eg turn the stabilisation |
59 |
> > into a tracker for the slow archs concerned, if there are multiple.) |
60 |
> |
61 |
> Since this is a soft measure I've seen a lot of people want the time to |
62 |
> be longer; if it still continues to be a problem, then shortening it |
63 |
> might be a solution but I think we'll want to avoid a too hard approach |
64 |
> for now. 45 days are over before you know it... |
65 |
|
66 |
No the whole point is that the slower archs are not losing a stable |
67 |
ebuild in their tree: so it's fine for the maintainer to wait a shorter |
68 |
time before marking it as no-longer-my-problem. It's not the same as |
69 |
dropping the ebuild altogether; it leaves the arch-tree intact, and |
70 |
still marks a new phase for interested users to collaborate around, |
71 |
while relieving the maintainer of the burden. |
72 |
|
73 |
And if desired, that can be seen as the start of a phase toward bumping |
74 |
it to unstable, but with more notice, and a defined process. |
75 |
|
76 |
> The part about ATs taking the bug sounds like what came up at FOSDEM. +1 |
77 |
|
78 |
<snip> |
79 |
> > The wonderful thing about policy is that it reflects (or is supposed |
80 |
> > to) consensus opinion with light to contemporaneous circumstance. |
81 |
> > Since circumstances change, so too must policy be open to change or |
82 |
> > adaptation, in line with basic principles. |
83 |
> |
84 |
> In this case -* works fine for what it intends to work; changing the |
85 |
> policy to redefine it to fit another purpose, while no longer |
86 |
> reflecting its original purpose is what we should avoid at all cost. |
87 |
|
88 |
Utter nonsense. Back that up with some consequent to justify why we |
89 |
should "avoid it at all costs", bearing in mind the below. |
90 |
|
91 |
> > So let's look at extending it, since there is *no* technical problem: |
92 |
> |
93 |
> You have colons after the above quoted sentence with nothing after it. |
94 |
> |
95 |
> (An eye for an eye... :D) |
96 |
|
97 |
Don't be so facile: the proposed extended policy is what follows. |
98 |
|
99 |
> > 'The redundant -* keyword is a metadata marker. |
100 |
> |
101 |
> The keyword has a meaning, therefore it is not redundant. |
102 |
|
103 |
It is technically redundant, since the package manager does not infer |
104 |
any existing keywords, so there is nothing to strip. As a metadata |
105 |
marker, no ofc it's not redundant: but that's what I'm proposing to |
106 |
use. |
107 |
|
108 |
> > It is used to indicate, in line with the semantic of "strip all", |
109 |
> > that the ebuild in question can only be used for the specific archs |
110 |
> > noted for one of two reasons: |
111 |
> > |
112 |
> > 1) The package-maintainer has stabilised a newer version on at least |
113 |
> > one arch personally, the ATs for the archs listed have taken longer |
114 |
> > than XX days to test and stabilise, and the maintainer would |
115 |
> > otherwise drop the ebuild altogether. |
116 |
> > |
117 |
> > 2) The package version is not worth trying to test on unlisted archs.' |
118 |
> |
119 |
> (1) changes its meaning in a way that you can no longer interpret the |
120 |
> keyword solely as (2). The whole purpose of (2) is that you can |
121 |
> interpret it that you should not test it as it was found not to work; |
122 |
> (1) is different from that, as it means that there was no manpower to |
123 |
> test it. (1) would move ebuilds to -* and be misinterpreted as (2). |
124 |
|
125 |
Nope: 1) implies 2) so any existing use of the marker solely in the |
126 |
context of 2) still works. It certainly is not worth testing an old |
127 |
ebuild that would have been dropped on an unlisted arch: whoever is |
128 |
looking at the ebuild, should instead use a newer version. |
129 |
|
130 |
> > The policy which flows from that is: |
131 |
> > |
132 |
> > 'In the first case, it is QA policy that a comment of the form: |
133 |
> > # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN |
134 |
> > is required on the line immediately above the KEYWORDS declaration. |
135 |
> > |
136 |
> > This is to aid both automated identification, and human |
137 |
> > collaboration.' |
138 |
> > |
139 |
> > (The latter explains why a URL, not a bug id, is required. We're |
140 |
> > trying to get end-users to help us, so let's make it easy for them.) |
141 |
> > |
142 |
> > I'd personally add: |
143 |
> > 'It is envisaged that the line will be added by an automated tool at |
144 |
> > some point.' |
145 |
> > |
146 |
> > ..as well as a requirement for a bug id in the second case, but I |
147 |
> > don't know it well enough; I'd certainly want some sort of tracking. |
148 |
> |
149 |
> This yields extra commits; comments in ebuilds are directed towards |
150 |
> maintainers, for users we should use another approach to contact them. |
151 |
|
152 |
No it keeps all the useful info in one place: the ebuild, where it's |
153 |
easy to edit and see. The commit is already implicit in dropping the |
154 |
ebuild to "-* slower arch": all the policy does is require a link to |
155 |
the original stabilisation bug, which may be a tracker if multiple |
156 |
archs are involved. However none of that is the maintainer's concern: |
157 |
all they need do, when facing this rare situation, is change the |
158 |
keywords and add a link to the bug (commenting is SOP for most unusual |
159 |
situations in ebuilds), instead of dropping the arch's stable version. |
160 |
|
161 |
The link is easy to extract for an automated external to show to the |
162 |
user, like the mangler in the above, or a porcelain layer, given an |
163 |
indicator from the mangler. |
164 |
|
165 |
It's also a helluva lot less work than package.mask, as well as |
166 |
keeping all the info in the ebuild, where it's easier to handle. |
167 |
|
168 |
> > It's hardly an onerous requirement, and a small price to pay: if |
169 |
> > we have a policy for how a maintainer drops an ebuild from his |
170 |
> > queue due to it being stabilised, which we can trigger scripts |
171 |
> > from, we avoid the arguments every year or so, and stop archs from |
172 |
> > being borked. We can also speed it up, since we have a mechanism |
173 |
> > in-place to support it, as opposed to ad-hoc, flawed decision-making. |
174 |
> > |
175 |
> > The thing I think that's missing from this debate, is an |
176 |
> > acknowledgement, or an understanding, that arch-teams are all |
177 |
> > effectively working on their own variant of the shared Gentoo tree. |
178 |
> > (This includes the concept of upgrades working as smoothly as they |
179 |
> > do on other archs, at the PM level.) Similar to other portability |
180 |
> > efforts, the tree must support them in that, not make it harder. |
181 |
> > |
182 |
> > Especially not because another developer doesn't care about the arch |
183 |
> > in question. That's *natural*, but _cannot_ be cause for dropping |
184 |
> > stable ebuilds. The only issue is to take the bugs off their hands, |
185 |
> > and we can do that with a simple tweak in metadata, so ffs let's |
186 |
> > get on and do it. |
187 |
> |
188 |
> +1 on this thought. |
189 |
|
190 |
Well I wish you could see that steev's solution, with a bit of standard |
191 |
commenting, fulfils both your +1s and doesn't lead to broken arch-trees. |
192 |
It also doesn't require any communication with a non-responsive arch, |
193 |
and can form the basis of a much more useful mode of collaboration, |
194 |
from where I'm sitting. |
195 |
|
196 |
Post-facto complaints about an upstream project decision to keep |
197 |
migration code, or about the anguish of seeing an older version |
198 |
stable on some arch you don't even care about (or you wouldn't be |
199 |
dropping their last stable version) are an order-of-magnitude less |
200 |
concerning. By all means address them (up to the project in the |
201 |
first case, adjust your script in the second) but let's at least |
202 |
admit they are less of a problem than this continual argument, and |
203 |
the consequent ill-feeling brought about by lack of a defined |
204 |
action to take. |
205 |
|
206 |
The issue about confusion with multiple archs has already been |
207 |
addressed by making the original stabilisation bug a tracker for |
208 |
the N slow archs, if there are more than one. |
209 |
|
210 |
Most of this can be automated, or is at least amenable to it. And |
211 |
that discussion is *far* more interesting than "you broke our arch" |
212 |
vs "so what, you're too slow". |
213 |
|
214 |
-- |
215 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |