1 |
On 08/08/2017 02:40 PM, Michał Górny wrote: |
2 |
> On wto, 2017-08-08 at 13:46 -0700, Daniel Campbell wrote: |
3 |
>> On 08/08/2017 09:49 AM, William Hubbs wrote: |
4 |
>>> |
5 |
>>> All, |
6 |
>>> |
7 |
>>> here is the council agenda for 8/13: |
8 |
>>> |
9 |
>>> 1. roll call |
10 |
>>> |
11 |
>>> 2. decide whether the kernel team can stabilize minor releases on their |
12 |
>>> own once the arch teams have stabilized a major release [1]. |
13 |
>>> |
14 |
>>> 3. open bugs with council involvement |
15 |
>>> |
16 |
>>> 4. open floor |
17 |
>>> |
18 |
>>> Thanks, |
19 |
>>> |
20 |
>>> William |
21 |
>>> |
22 |
>>> [1] https://wiki.gentoo.org/wiki/Project:Kernel#Kernel_stabilization |
23 |
>>> |
24 |
>> |
25 |
>> I would like the council to consider clarifying the text found in the |
26 |
>> devmanual regarding revision bumps. [1] At present, the text indicates |
27 |
>> that in general we don't want to touch ebuilds that have hit stable. |
28 |
>> However, there are exceptions that are not explicitly laid out, that |
29 |
>> some of us expect other developers to "just understand", despite a |
30 |
>> complete lack of documentation. Developers can't be expected to follow |
31 |
>> policy that isn't clear. "Use your best judgment" isn't good enough when |
32 |
>> a developer gets berated for using it. |
33 |
>> |
34 |
>> Thus, I would ask the council to answer this one question: When is it |
35 |
>> acceptable to correct an ebuild that has already gotten stable keywords? |
36 |
>> If more intrepid developers would like to make a flow chart or other |
37 |
>> guided aid, that'd be even better. |
38 |
>> |
39 |
> |
40 |
> This is a matter for QA, and there are patches for devmanual with a more |
41 |
> detailed policy in review already |
42 |
> |
43 |
> Besides, flow charts won't replace common sense. They will only serve as |
44 |
> an excuse to abuse the policy against the spirit it was written on. |
45 |
> |
46 |
It would have been helpful for a link. Instead, I found a rabbit hole |
47 |
that eventually led to what you're talking about. On GitHub, no less, |
48 |
which is separate from our own infra and not as discoverable. |
49 |
|
50 |
I first searched for devmanual bugs, and ctrl+F'd "bump". That led me to |
51 |
[1], whose "Depends On" pointed to [2]. [2] has a "See also" that points |
52 |
to a GitHub PR [3], which appears to have been linked *yesterday*. How |
53 |
exactly did you expect someone who's interested in the subject to find |
54 |
the work that's been done unless you link to it? |
55 |
|
56 |
Regardless, thank you for taking initiative to make things clearer. The |
57 |
flow chart was merely a "nice to have" suggestion. I'm willing to build |
58 |
it myself if guidelines are clear enough to make it feasible and/or if |
59 |
it will be considered for inclusion. If not, I won't waste my time on it. |
60 |
|
61 |
We both know "common sense" is a misnomer and lacks any useful, relevant |
62 |
definition in our work. Our work is built on expectations and policies. |
63 |
If those aren't clear, we end up with breakage. I find it intellectually |
64 |
lazy to write current practices off as 'common sense'. It may be common |
65 |
sense to *you*, but you are not everyone else. The average competency of |
66 |
our developers only stands to rise by better documenting our "common |
67 |
sense" practices. |
68 |
|
69 |
Now that I see the work's in motion (and have shared the links so others |
70 |
can follow), this will be my last mail in this particular thread. Thanks |
71 |
again for the initiative and sorry for the noise. |
72 |
|
73 |
~zlg |
74 |
|
75 |
[1]: https://bugs.gentoo.org/show_bug.cgi?id=223153 |
76 |
[2]: https://bugs.gentoo.org/show_bug.cgi?id=565560 |
77 |
[3]: https://github.com/gentoo/devmanual.gentoo.org/pull/67 |
78 |
-- |
79 |
Daniel Campbell - Gentoo Developer |
80 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
81 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |