1 |
On Tue, 4 Feb 2014 21:03:20 +0000 |
2 |
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote: |
3 |
|
4 |
> Tom Wijsman wrote: |
5 |
> |
6 |
> > They are less work; since it lets the slower arches move their work |
7 |
> > to bugs of important packages that need their attention, instead of |
8 |
> > bugs of non-important packages were the stabilization isn't really |
9 |
> > necessary. |
10 |
> |
11 |
> Huh? The slower arch is not keeping up with stabilisation. How can the |
12 |
> stabilisation suddenly be unnecessary? If it is not needed, there is |
13 |
> no problem, and we wouldn't be having this discussion. |
14 |
|
15 |
It is still necessary, as clear from the difference in importance. |
16 |
|
17 |
> Much better for the arch in question to field the bug, than tell the |
18 |
> user there is no problem, and we don't care. That way you can get the |
19 |
> user involved in stabilisation and AT via that bug, instead of turning |
20 |
> them away with priggishness. |
21 |
|
22 |
Problems should be visible instead of hidden, as well as resolved. A |
23 |
move in work means a move in work, further implications are yours... |
24 |
|
25 |
> > > The arguments and headaches at the user, bug |
26 |
> > > and AT sides are causing more work (or detracting from real work) |
27 |
> > > too. |
28 |
> > |
29 |
> > Yes, the less work that we can do, the more work the user has to do |
30 |
> > as a natural consequence; discussions like these are there to |
31 |
> > prevent those headaches way in advance, as we can proper adapt |
32 |
> > and/or respond to the situation. And if needed, bring out news such |
33 |
> > that the user is well informed. Not sure which argumentation this |
34 |
> > is about though. |
35 |
> |
36 |
> Perfectly simple: instead of having this row repeatedly, or borking |
37 |
> archs, let's use the solution proposed by the ARM AT: provide a |
38 |
> technical reason why it won't work, rather than a conceptual problem |
39 |
> with the "hack". |
40 |
|
41 |
Searching for such technical reasoning is a leeway for hacking & hoping. |
42 |
|
43 |
Solutions were provided, a policy has been made; we are exactly |
44 |
avoiding to row repeatedly, and this is yet another solution I propose: |
45 |
|
46 |
Provide a technical reason why it will work? |
47 |
|
48 |
You further demonstrate this solution that I propose we should use: |
49 |
|
50 |
> The history of computing is littered with hacks that turned out to |
51 |
> shed new light on a problem: it's called exploring the problem |
52 |
> domain. It's only when you have idiomatic knowledge of the |
53 |
> language/tools *and* the specific domain, that you can envision |
54 |
> oddball solutions and more importantly _know_ that they will work |
55 |
> (perhaps with a bit of tweaking.) |
56 |
|
57 |
It is called prototyping. |
58 |
|
59 |
> <snip> |
60 |
> > [1] Quality Assurance / Policies / Dropping Stable KEYWORDs |
61 |
> > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs |
62 |
> |
63 |
> That's not a policy: it's a two-line statement of intent. |
64 |
|
65 |
It is policy, as it permits implementation of that intent; at the very |
66 |
least, it is a policy change that allows you something you were disallowed. |
67 |
|
68 |
> Further, the solution steev brought up is much much better than |
69 |
> simply dropping the ebuild. |
70 |
> |
71 |
> > > Just keep the old ebuilds as useful metadata, subject to the usual |
72 |
> > > version-control cycle, but iff it's causing you problems and you |
73 |
> > > want to drop it, mark it with: "-* slowe rarch" so we can script |
74 |
> > > off it and automate bug-handling etc. so your life is easier, as |
75 |
> > > well as the archs in question (and their users.) |
76 |
> > |
77 |
> > As stated before, -* means something way different; it is a |
78 |
> > suggestion that does not fit this thread. Like before, did you mean |
79 |
> > "slower arch"? |
80 |
> |
81 |
> No, it's an example, like foo bar, but indicating that we're talking |
82 |
> about slower archs, and likely more than one in some instances. As |
83 |
> before did you mean to raise a technical objection with clear |
84 |
> explanation of what and why it would break? |
85 |
> |
86 |
> > And even if you did, we have then already been using this practice |
87 |
> > for a long while; it is different from the problem that was brought |
88 |
> > up here. |
89 |
> |
90 |
> Yes, yes, you can keep going on about the "conceptual difficulty", but |
91 |
> the simple fact is the solution works, or it wouldn't have been |
92 |
> raised. steev's idiomatic knowledge and solution wins, IMNSHO. |
93 |
|
94 |
"The -* keyword is special. It is used to indicate package versions |
95 |
which are not worth trying to test on unlisted archs." [1] |
96 |
|
97 |
You can keep rehashing about "winning", but all it does is break policy. |
98 |
|
99 |
[1]: http://devmanual.gentoo.org/keywording |
100 |
|
101 |
-- |
102 |
With kind regards, |
103 |
|
104 |
Tom Wijsman (TomWij) |
105 |
Gentoo Developer |
106 |
|
107 |
E-mail address : TomWij@g.o |
108 |
GPG Public Key : 6D34E57D |
109 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |