Re: [gentoo-project] Gentoo Council agenda for 8/13

[Michał Górny]

Dnia 9 sierpnia 2017 01:29:09 CEST, Daniel Campbell <zlg@g.o> napisał(a):
>On 08/08/2017 02:40 PM, Michał Górny wrote:
>> On wto, 2017-08-08 at 13:46 -0700, Daniel Campbell wrote:
>>> On 08/08/2017 09:49 AM, William Hubbs wrote:
>>>>
>>>> All,
>>>>
>>>> here is the council agenda for 8/13:
>>>>
>>>> 1. roll call
>>>>
>>>> 2. decide whether the kernel team can stabilize minor releases on
>their
>>>> own once the arch teams have stabilized a major release [1].
>>>>
>>>> 3. open bugs with council involvement
>>>>
>>>> 4. open floor
>>>>
>>>> Thanks,
>>>>
>>>> William
>>>>
>>>> [1]
>https://wiki.gentoo.org/wiki/Project:Kernel#Kernel_stabilization
>>>>
>>>
>>> I would like the council to consider clarifying the text found in
>the
>>> devmanual regarding revision bumps. [1] At present, the text
>indicates
>>> that in general we don't want to touch ebuilds that have hit stable.
>>> However, there are exceptions that are not explicitly laid out, that
>>> some of us expect other developers to "just understand", despite a
>>> complete lack of documentation. Developers can't be expected to
>follow
>>> policy that isn't clear. "Use your best judgment" isn't good enough
>when
>>> a developer gets berated for using it.
>>>
>>> Thus, I would ask the council to answer this one question: When is
>it
>>> acceptable to correct an ebuild that has already gotten stable
>keywords?
>>> If more intrepid developers would like to make a flow chart or other
>>> guided aid, that'd be even better.
>>>
>>
>> This is a matter for QA, and there are patches for devmanual with a
>more
>> detailed policy in review already
>>
>> Besides, flow charts won't replace common sense. They will only serve
>as
>> an excuse to abuse the policy against the spirit it was written on.
>>
>It would have been helpful for a link. Instead, I found a rabbit hole
>that eventually led to what you're talking about. On GitHub, no less,
>which is separate from our own infra and not as discoverable.

Pointing you to the wip was not my goal. I merely wanted to point out that:

1. This is a matter for QA, and there is no reason to take it straight to Council.

2. Bringing up points like this 4 days before the meeting doesn't give enough time for proper on-list discussion.

3. Having a strict policy makes no sense if you aren't going to strictly enforce it. You can't strictly enforce a policy for that because there are too many corner cases, and you won't be able to reliably cover them all.

>
>I first searched for devmanual bugs, and ctrl+F'd "bump". That led me
>to
>[1], whose "Depends On" pointed to [2]. [2] has a "See also" that
>points
>to a GitHub PR [3], which appears to have been linked *yesterday*. How
>exactly did you expect someone who's interested in the subject to find
>the work that's been done unless you link to it?
>
>Regardless, thank you for taking initiative to make things clearer. The
>flow chart was merely a "nice to have" suggestion. I'm willing to build
>it myself if guidelines are clear enough to make it feasible and/or if
>it will be considered for inclusion. If not, I won't waste my time on
>it.
>
>We both know "common sense" is a misnomer and lacks any useful,
>relevant
>definition in our work. Our work is built on expectations and policies.
>If those aren't clear, we end up with breakage. I find it
>intellectually
>lazy to write current practices off as 'common sense'. It may be common
>sense to *you*, but you are not everyone else. The average competency
>of
>our developers only stands to rise by better documenting our "common
>sense" practices.
>
>Now that I see the work's in motion (and have shared the links so
>others
>can follow), this will be my last mail in this particular thread.
>Thanks
>again for the initiative and sorry for the noise.
>
>~zlg
>
>[1]: https://bugs.gentoo.org/show_bug.cgi?id=223153
>[2]: https://bugs.gentoo.org/show_bug.cgi?id=565560
>[3]: https://github.com/gentoo/devmanual.gentoo.org/pull/67


-- 
Best regards,
Michał Górny (by phone)