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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]


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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1589 bytes --]

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 was the cause of a recent kerfuffle and I'd like to prevent it from
happening again. Thank you for your time.

~zlg

[1]:
https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Raymond Jennings]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Tue, Aug 8, 2017 at 1:46 PM, Daniel Campbell <zlg@gentoo.org> 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.
>

My two cents:

* I've heard a few times that once an ebuild hits the tree it is to be
considered immutable until deletion.  Concerns were raised at the time
regarding cache coherency and metadata and so on and the impression was
given that, apart from stabilizing and keywording, tinkering with ebuilds
in place was a major no-no stable or not.

* There's a couple of questions on the dev quiz that seem related to this
issue.  If any documentation is added or updated, I'd like the dev quiz to
be checked for any needed updates.

>
> This was the cause of a recent kerfuffle and I'd like to prevent it from
> happening again. Thank you for your time.
>
> ~zlg
>
> [1]:
> https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>
>

[-- Attachment #2: Type: text/html, Size: 3390 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 3519 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 514 bytes --]

On 08/09/2017 01:29 AM, Daniel Campbell wrote:
> 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.

Indeed, changes to devmanual should be a result of discussion on
bugzilla for tracking/audit purposes.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 834 bytes --]

On 08/09/2017 09:28 AM, Kristian Fiskerstrand wrote:
> On 08/09/2017 01:29 AM, Daniel Campbell wrote:
>> 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.
> 
> Indeed, changes to devmanual should be a result of discussion on
> bugzilla for tracking/audit purposes.
> 

Although this seems to be a result of discussion coming out of
https://bugs.gentoo.org/show_bug.cgi?id=223153 , it would be nice if a
reference to the QA meeting resolution / summary from a meeting
approving updated text is included in the bug.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Michał Górny]

Dnia 9 sierpnia 2017 01:29:09 CEST, Daniel Campbell <zlg@gentoo.org> 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)