Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o, Daniel Campbell <zlg@g.o>
Subject: Re: [gentoo-project] Gentoo Council agenda for 8/13
Date: Wed, 09 Aug 2017 10:19:53
In Reply to: Re: [gentoo-project] Gentoo Council agenda for 8/13 by Daniel Campbell
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] > >>>> >>> >>> 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]: >[2]: >[3]:
-- Best regards, Michał Górny (by phone)