Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: slong@××××××××××××××××××.uk
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
Date: Wed, 05 Feb 2014 00:10:55
Message-Id: 20140205010833.1bcf8dca@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Re: Re: dropping redundant stable keywords by "Steven J. Long"
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

Replies

Subject Author
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords Steev Klimaszewski <steev@g.o>
[gentoo-dev] Re: Re: Re: dropping redundant stable keywords "Steven J. Long" <slong@××××××××××××××××××.uk>