1 |
On Wed, Feb 05, 2014 at 01:08:33AM +0100, Tom Wijsman wrote: |
2 |
> On Tue, 4 Feb 2014 21:03:20 +0000 |
3 |
> "Steven J. Long" wrote: |
4 |
> |
5 |
> > Tom Wijsman wrote: |
6 |
> > |
7 |
> > > They are less work; since it lets the slower arches move their work |
8 |
> > > to bugs of important packages that need their attention, instead of |
9 |
> > > bugs of non-important packages were the stabilization isn't really |
10 |
> > > necessary. |
11 |
> > |
12 |
> > Huh? The slower arch is not keeping up with stabilisation. How can the |
13 |
> > stabilisation suddenly be unnecessary? If it is not needed, there is |
14 |
> > no problem, and we wouldn't be having this discussion. |
15 |
> |
16 |
> It is still necessary, as clear from the difference in importance. |
17 |
> |
18 |
> > Much better for the arch in question to field the bug, than tell the |
19 |
> > user there is no problem, and we don't care. That way you can get the |
20 |
> > user involved in stabilisation and AT via that bug, instead of turning |
21 |
> > them away with priggishness. |
22 |
> |
23 |
> Problems should be visible instead of hidden, as well as resolved. A |
24 |
> move in work means a move in work, further implications are yours... |
25 |
|
26 |
Very gnomic: nothing's being hidden in the above approach. I can't make |
27 |
sense of the rest so I'll move on, noting only that it's up to the arch |
28 |
team, as to what _they_ decide to kick back to unstable. And that can |
29 |
work without a problem if we have a mechanism in place to relieve |
30 |
maintainers of those bugs. Personally I'd do it after 45 days to speed |
31 |
things up, and let the ATs concerned, take the bug as and when (eg |
32 |
turn the stabilisation into a tracker for the slow archs concerned, if |
33 |
there are multiple.) |
34 |
|
35 |
> > > > The arguments and headaches at the user, bug |
36 |
> > > > and AT sides are causing more work (or detracting from real work) |
37 |
> > > > too. |
38 |
> > > |
39 |
> > > Yes, the less work that we can do, the more work the user has to do |
40 |
> > > as a natural consequence; discussions like these are there to |
41 |
> > > prevent those headaches way in advance, as we can proper adapt |
42 |
> > > and/or respond to the situation. And if needed, bring out news such |
43 |
> > > that the user is well informed. Not sure which argumentation this |
44 |
> > > is about though. |
45 |
> > |
46 |
> > Perfectly simple: instead of having this row repeatedly, or borking |
47 |
> > archs, let's use the solution proposed by the ARM AT: provide a |
48 |
> > technical reason why it won't work, rather than a conceptual problem |
49 |
> > with the "hack". |
50 |
> |
51 |
> Searching for such technical reasoning is a leeway for hacking & hoping. |
52 |
|
53 |
Er what? |
54 |
|
55 |
> Solutions were provided, a policy has been made; we are exactly |
56 |
> avoiding to row repeatedly, and this is yet another solution I propose: |
57 |
> |
58 |
> Provide a technical reason why it will work? |
59 |
|
60 |
You have colons after a "solution I propose:" with nothing after it. |
61 |
Kinda sums up your discussion for me. And your answer to "tell us what it |
62 |
breaks" is "tell us why it works?" Pfft. |
63 |
|
64 |
> You further demonstrate this solution that I propose we should use: |
65 |
> |
66 |
> > The history of computing is littered with hacks that turned out to |
67 |
> > shed new light on a problem: it's called exploring the problem |
68 |
> > domain. It's only when you have idiomatic knowledge of the |
69 |
> > language/tools *and* the specific domain, that you can envision |
70 |
> > oddball solutions and more importantly _know_ that they will work |
71 |
> > (perhaps with a bit of tweaking.) |
72 |
> |
73 |
> It is called prototyping. |
74 |
|
75 |
That's just another word: "exploring the problem domain" is much more |
76 |
useful to keep in mind. Similar to how "Keep it Simple (and) Stupid" |
77 |
is much more useful while coding, than: |
78 |
"It is more important to make the purpose of the code unmistakable |
79 |
than to display virtuosity. The problem with obscure code is that |
80 |
debugging and modification become much more difficult, and these are |
81 |
already the hardest aspects of computer programming." |
82 |
(Kernighan and Plauger, 1976) |
83 |
|
84 |
..although the latter is still worth reading/knowing about. |
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 |
> You can keep rehashing about "winning", but all it does is break policy. |
95 |
|
96 |
*sigh* |
97 |
The wonderful thing about policy is that it reflects (or is supposed to) |
98 |
consensus opinion with light to contemporaneous circumstance. Since |
99 |
circumstances change, so too must policy be open to change or |
100 |
adaptation, in line with basic principles. So let's look at extending |
101 |
it, since there is *no* technical problem: |
102 |
|
103 |
'The redundant -* keyword is a metadata marker. It is used to indicate, |
104 |
in line with the semantic of "strip all", that the ebuild in question |
105 |
can only be used for the specific archs noted for one of two reasons: |
106 |
|
107 |
1) The package-maintainer has stabilised a newer version on at least one |
108 |
arch personally, the ATs for the archs listed have taken longer than |
109 |
XX days to test and stabilise, and the maintainer would otherwise drop |
110 |
the ebuild altogether. |
111 |
|
112 |
2) The package version is not worth trying to test on unlisted archs.' |
113 |
|
114 |
The policy which flows from that is: |
115 |
|
116 |
'In the first case, it is QA policy that a comment of the form: |
117 |
# STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN |
118 |
is required on the line immediately above the KEYWORDS declaration. |
119 |
|
120 |
This is to aid both automated identification, and human collaboration.' |
121 |
|
122 |
(The latter explains why a URL, not a bug id, is required. We're trying |
123 |
to get end-users to help us, so let's make it easy for them.) |
124 |
|
125 |
I'd personally add: |
126 |
'It is envisaged that the line will be added by an automated tool at |
127 |
some point.' |
128 |
|
129 |
..as well as a requirement for a bug id in the second case, but I |
130 |
don't know it well enough; I'd certainly want some sort of tracking. |
131 |
|
132 |
It's hardly an onerous requirement, and a small price to pay: if |
133 |
we have a policy for how a maintainer drops an ebuild from his |
134 |
queue due to it being stabilised, which we can trigger scripts |
135 |
from, we avoid the arguments every year or so, and stop archs from |
136 |
being borked. We can also speed it up, since we have a mechanism |
137 |
in-place to support it, as opposed to ad-hoc, flawed decision-making. |
138 |
|
139 |
The thing I think that's missing from this debate, is an |
140 |
acknowledgement, or an understanding, that arch-teams are all |
141 |
effectively working on their own variant of the shared Gentoo tree. |
142 |
(This includes the concept of upgrades working as smoothly as they |
143 |
do on other archs, at the PM level.) Similar to other portability |
144 |
efforts, the tree must support them in that, not make it harder. |
145 |
|
146 |
Especially not because another developer doesn't care about the arch |
147 |
in question. That's *natural*, but _cannot_ be cause for dropping |
148 |
stable ebuilds. The only issue is to take the bugs off their hands, |
149 |
and we can do that with a simple tweak in metadata, so ffs let's |
150 |
get on and do it. |
151 |
|
152 |
-- |
153 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |