1 |
On Thu, 13 Feb 2014 21:28:18 +0000 |
2 |
"Steven J. Long" <slong@××××××××××××××××××.uk> 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 |
> I can't make sense of the rest so I'll move on, noting only that it's |
17 |
> up to the arch team, as to what _they_ decide to kick back to |
18 |
> unstable. |
19 |
|
20 |
They need manpower to decide it, which they don't have. |
21 |
|
22 |
> And that can work without a problem if we have a mechanism |
23 |
> in place to relieve maintainers of those bugs. |
24 |
|
25 |
Such mechanism could be to assign those bug to the arch team, this idea |
26 |
came up at FOSDEM; it won't solve the lack of manpower, but it will at |
27 |
least relieve the maintainers and make the problem more visible. |
28 |
|
29 |
> Personally I'd do it after 45 days to speed things up, and let the |
30 |
> ATs concerned, take the bug as and when (eg turn the stabilisation |
31 |
> into a tracker for the slow archs concerned, if there are multiple.) |
32 |
|
33 |
Since this is a soft measure I've seen a lot of people want the time to |
34 |
be longer; if it still continues to be a problem, then shortening it |
35 |
might be a solution but I think we'll want to avoid a too hard approach |
36 |
for now. 45 days are over before you know it... |
37 |
|
38 |
The part about ATs taking the bug sounds like what came up at FOSDEM. +1 |
39 |
|
40 |
> > > > > The arguments and headaches at the user, bug |
41 |
> > > > > and AT sides are causing more work (or detracting from real |
42 |
> > > > > work) too. |
43 |
> > > > |
44 |
> > > > Yes, the less work that we can do, the more work the user has |
45 |
> > > > to do as a natural consequence; discussions like these are |
46 |
> > > > there to prevent those headaches way in advance, as we can |
47 |
> > > > proper adapt and/or respond to the situation. And if needed, |
48 |
> > > > bring out news such that the user is well informed. Not sure |
49 |
> > > > which argumentation this is about though. |
50 |
> > > |
51 |
> > > Perfectly simple: instead of having this row repeatedly, or |
52 |
> > > borking archs, let's use the solution proposed by the ARM AT: |
53 |
> > > provide a technical reason why it won't work, rather than a |
54 |
> > > conceptual problem with the "hack". |
55 |
> > |
56 |
> > Searching for such technical reasoning is a leeway for hacking & |
57 |
> > hoping. |
58 |
> |
59 |
> Er what? |
60 |
> |
61 |
> > Solutions were provided, a policy has been made; we are exactly |
62 |
> > avoiding to row repeatedly, and this is yet another solution I |
63 |
> > propose: Provide a technical reason why it will work? |
64 |
> |
65 |
> Kinda sums up your discussion for me. And your answer to "tell us |
66 |
> what it breaks" is "tell us why it works?" Pfft. |
67 |
|
68 |
We are searching for solutions that work. |
69 |
|
70 |
> > You further demonstrate this solution that I propose we should use: |
71 |
> > |
72 |
> > > The history of computing is littered with hacks that turned out to |
73 |
> > > shed new light on a problem: it's called exploring the problem |
74 |
> > > domain. It's only when you have idiomatic knowledge of the |
75 |
> > > language/tools *and* the specific domain, that you can envision |
76 |
> > > oddball solutions and more importantly _know_ that they will work |
77 |
> > > (perhaps with a bit of tweaking.) |
78 |
> > |
79 |
> > It is called prototyping. |
80 |
> |
81 |
> That's just another word: "exploring the problem domain" is much more |
82 |
> useful to keep in mind. |
83 |
|
84 |
We already know the problem, thus it is rather just called prototyping. |
85 |
|
86 |
> > > Further, the solution steev brought up is much much better than |
87 |
> > > simply dropping the ebuild. |
88 |
> <snip> |
89 |
> > "The -* keyword is special. It is used to indicate package versions |
90 |
> > which are not worth trying to test on unlisted archs." [1] |
91 |
> |
92 |
> Finally: some actual content. |
93 |
|
94 |
It works. |
95 |
|
96 |
> > You can keep rehashing about "winning", but all it does is break |
97 |
> > policy. |
98 |
> |
99 |
> *sigh* |
100 |
> The wonderful thing about policy is that it reflects (or is supposed |
101 |
> to) consensus opinion with light to contemporaneous circumstance. |
102 |
> Since circumstances change, so too must policy be open to change or |
103 |
> adaptation, in line with basic principles. |
104 |
|
105 |
In this case -* works fine for what it intends to work; changing the |
106 |
policy to redefine it to fit another purpose, while no longer |
107 |
reflecting its original purpose is what we should avoid at all cost. |
108 |
|
109 |
> So let's look at extending it, since there is *no* technical problem: |
110 |
|
111 |
You have colons after the above quoted sentence with nothing after it. |
112 |
|
113 |
(An eye for an eye... :D) |
114 |
|
115 |
> 'The redundant -* keyword is a metadata marker. |
116 |
|
117 |
The keyword has a meaning, therefore it is not redundant. |
118 |
|
119 |
> It is used to indicate, in line with the semantic of "strip all", |
120 |
> that the ebuild in question can only be used for the specific archs |
121 |
> noted for one of two reasons: |
122 |
> |
123 |
> 1) The package-maintainer has stabilised a newer version on at least |
124 |
> one arch personally, the ATs for the archs listed have taken longer |
125 |
> than XX days to test and stabilise, and the maintainer would |
126 |
> otherwise drop the ebuild altogether. |
127 |
> |
128 |
> 2) The package version is not worth trying to test on unlisted archs.' |
129 |
|
130 |
(1) changes its meaning in a way that you can no longer interpret the |
131 |
keyword solely as (2). The whole purpose of (2) is that you can |
132 |
interpret it that you should not test it as it was found not to work; |
133 |
(1) is different from that, as it means that there was no manpower to |
134 |
test it. (1) would move ebuilds to -* and be misinterpreted as (2). |
135 |
|
136 |
> The policy which flows from that is: |
137 |
> |
138 |
> 'In the first case, it is QA policy that a comment of the form: |
139 |
> # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN |
140 |
> is required on the line immediately above the KEYWORDS declaration. |
141 |
> |
142 |
> This is to aid both automated identification, and human |
143 |
> collaboration.' |
144 |
> |
145 |
> (The latter explains why a URL, not a bug id, is required. We're |
146 |
> trying to get end-users to help us, so let's make it easy for them.) |
147 |
> |
148 |
> I'd personally add: |
149 |
> 'It is envisaged that the line will be added by an automated tool at |
150 |
> some point.' |
151 |
> |
152 |
> ..as well as a requirement for a bug id in the second case, but I |
153 |
> don't know it well enough; I'd certainly want some sort of tracking. |
154 |
|
155 |
This yields extra commits; comments in ebuilds are directed towards |
156 |
maintainers, for users we should use another approach to contact them. |
157 |
|
158 |
> It's hardly an onerous requirement, and a small price to pay: if |
159 |
> we have a policy for how a maintainer drops an ebuild from his |
160 |
> queue due to it being stabilised, which we can trigger scripts |
161 |
> from, we avoid the arguments every year or so, and stop archs from |
162 |
> being borked. We can also speed it up, since we have a mechanism |
163 |
> in-place to support it, as opposed to ad-hoc, flawed decision-making. |
164 |
> |
165 |
> The thing I think that's missing from this debate, is an |
166 |
> acknowledgement, or an understanding, that arch-teams are all |
167 |
> effectively working on their own variant of the shared Gentoo tree. |
168 |
> (This includes the concept of upgrades working as smoothly as they |
169 |
> do on other archs, at the PM level.) Similar to other portability |
170 |
> efforts, the tree must support them in that, not make it harder. |
171 |
> |
172 |
> Especially not because another developer doesn't care about the arch |
173 |
> in question. That's *natural*, but _cannot_ be cause for dropping |
174 |
> stable ebuilds. The only issue is to take the bugs off their hands, |
175 |
> and we can do that with a simple tweak in metadata, so ffs let's |
176 |
> get on and do it. |
177 |
|
178 |
+1 on this thought. |
179 |
|
180 |
-- |
181 |
With kind regards, |
182 |
|
183 |
Tom Wijsman (TomWij) |
184 |
Gentoo Developer |
185 |
|
186 |
E-mail address : TomWij@g.o |
187 |
GPG Public Key : 6D34E57D |
188 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |