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

[Daniel Campbell]

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.

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
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6