[gentoo-dev] On dropping sparc@ from CC on bugs

[gentoo-dev] On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

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

On Sun, 10 Sep 2017 22:18:08 +0000
bugzilla-daemon@gentoo.org wrote:

> DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> whose email is mentioned below. To comment on this bug, please visit:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=621130
> 
> Aaron Bauman <bman@gentoo.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|sparc@gentoo.org            |
> 
> --- Comment #16 from Aaron Bauman <bman@gentoo.org> ---
> sparc was dropped to exp.
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f12313a2925fcadd177a9

[ CCed gentoo-dev@ to raise general awareness ]

Why do you need to drop sparc@ from CC on all the bugs?

It takes away possibility from users using sparc@ to report
test status easily. Even after the bug is closed.

sh@ and s390@ are also exp profiles and CC is one of mechanisms
to ask arch teams to try keywording/stablereq.

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Aaron Bauman]

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

On Monday, September 11, 2017 3:43:13 AM EDT Sergei Trofimovich wrote:
> On Sun, 10 Sep 2017 22:18:08 +0000
> 
> bugzilla-daemon@gentoo.org wrote:
> > DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> > whose email is mentioned below. To comment on this bug, please visit:
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=621130
> > 
> > Aaron Bauman <bman@gentoo.org> changed:
> >            What    |Removed                     |Added
> > 
> > --------------------------------------------------------------------------
> > --> 
> >                  CC|sparc@gentoo.org            |
> > 
> > --- Comment #16 from Aaron Bauman <bman@gentoo.org> ---
> > sparc was dropped to exp.
> > 
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f1
> > 2313a2925fcadd177a9
> [ CCed gentoo-dev@ to raise general awareness ]
> 
> Why do you need to drop sparc@ from CC on all the bugs?
> 
> It takes away possibility from users using sparc@ to report
> test status easily. Even after the bug is closed.
> 
> sh@ and s390@ are also exp profiles and CC is one of mechanisms
> to ask arch teams to try keywording/stablereq.

You're right.  Fixed.


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

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Matt Turner]

On Mon, Sep 11, 2017 at 3:07 PM, Aaron Bauman <bman@gentoo.org> wrote:
> On Monday, September 11, 2017 3:43:13 AM EDT Sergei Trofimovich wrote:
>> On Sun, 10 Sep 2017 22:18:08 +0000
>>
>> bugzilla-daemon@gentoo.org wrote:
>> > DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
>> > whose email is mentioned below. To comment on this bug, please visit:
>> >
>> > https://bugs.gentoo.org/show_bug.cgi?id=621130
>> >
>> > Aaron Bauman <bman@gentoo.org> changed:
>> >            What    |Removed                     |Added
>> >
>> > --------------------------------------------------------------------------
>> > -->
>> >                  CC|sparc@gentoo.org            |
>> >
>> > --- Comment #16 from Aaron Bauman <bman@gentoo.org> ---
>> > sparc was dropped to exp.
>> >
>> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f1
>> > 2313a2925fcadd177a9
>> [ CCed gentoo-dev@ to raise general awareness ]
>>
>> Why do you need to drop sparc@ from CC on all the bugs?
>>
>> It takes away possibility from users using sparc@ to report
>> test status easily. Even after the bug is closed.
>>
>> sh@ and s390@ are also exp profiles and CC is one of mechanisms
>> to ask arch teams to try keywording/stablereq.
>
> You're right.  Fixed.

Aaron's agreement was not an agreement at all. He ignored the request
and instead removed the other exp arches from Cc.

Before I realized this, I assumed that he was agreeing, so I readded
sparc@ to the places he'd removed it. This evidently irritated him and
he told me so on IRC.

I suggested that when security bugs are complete, that if there are
exp architectures still Cc'd, that security simply reassign to the
maintainer and let the bug continue as a regular stabilization bug.

Unfortunately Aaron says that this is far too much work -- the hassle
of reassigning a bug and all.

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Ulrich Mueller]

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

>>>>> On Tue, 12 Sep 2017, Matt Turner wrote:

> I suggested that when security bugs are complete, that if there are
> exp architectures still Cc'd, that security simply reassign to the
> maintainer and let the bug continue as a regular stabilization bug.

> Unfortunately Aaron says that this is far too much work -- the hassle
> of reassigning a bug and all.

Let's look at the security team's own policy on that (thanks to K_F
for pointing me to it):
https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bstable.5D_status

| All arches (including "unsupported" arches) must be called. But note
| that only "supported" arches (as defined in the policy) are needed
| before the bug can advance to [glsa] status

Note that it says "unsupported arches", not "unsupported arches with a
stable profile". In fact, the whole guide doesn't mention profiles at
all.

The alternative scenario would be only to add supported arches to the
security bug. This would mean that the maintainer had to open a second
bug for stabilisation on unsupported arches (which includes not only
arches with experimental profiles, but also stable ones like arm).
Maybe that would take away some hassle from the security team, but it
would certainly mean more work for both maintainers and arch teams.

Ulrich

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

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

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

On Wed, 13 Sep 2017 09:00:06 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 12 Sep 2017, Matt Turner wrote:  
> 
> > I suggested that when security bugs are complete, that if there are
> > exp architectures still Cc'd, that security simply reassign to the
> > maintainer and let the bug continue as a regular stabilization bug.  
> 
> > Unfortunately Aaron says that this is far too much work -- the hassle
> > of reassigning a bug and all.  
> 
> Let's look at the security team's own policy on that (thanks to K_F
> for pointing me to it):
> https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bstable.5D_status
> 
> | All arches (including "unsupported" arches) must be called. But note
> | that only "supported" arches (as defined in the policy) are needed
> | before the bug can advance to [glsa] status
> 
> Note that it says "unsupported arches", not "unsupported arches with a
> stable profile". In fact, the whole guide doesn't mention profiles at
> all.
> 
> The alternative scenario would be only to add supported arches to the
> security bug. This would mean that the maintainer had to open a second
> bug for stabilisation on unsupported arches (which includes not only
> arches with experimental profiles, but also stable ones like arm).
> Maybe that would take away some hassle from the security team, but it
> would certainly mean more work for both maintainers and arch teams.

Thanks for spelling the question out!

[ CC security@, CC bman@ explicitly ]

Aaron, can you clarify on it how you perceive the rules on security side?

It's very hard to get a coherent picture from short sentences on IRC,
bugs and email. Here is what information I see:

  [irc/#gentoo-council]: 02:08:42 <+b-man> slyfox: security bugs do not
    require cc'ing unstable arches or non-security supported arches
  [bug/630680#c7]: No, it is not longer security supported and is not a
    stable arch.
  [mail] : You're right.  Fixed.

and I can't infer anything at all from it!

Does it mean normal STABLEREQ for exp arches should never be reassigned
to security bug of because their notion of exp arch is different from arch
team's?

If it's a documented rule link would help here. My intention to post
to -dev@ was specifically to clarify the rules for everyone to decrease
hassle and misunderstanding. Not to increase it.

https://bugs.gentoo.org/show_bug.cgi?id=630680#c7 is an example of
incomplete answer that does not give any more information to me.

The comments above imply sparc@ does not care about stable keywords.
sparc@ does care about stable keywords but does not want to make it a
burden on other teams.

Why CC clarity is important here?

Understanding the security workflow would help here:

Do you never close any security bug that has any arch CCed?
(Is there a policy around that?)

Do you never proceed with GLSA if there is any arch CCed?
(Stable or not)

What do you do if there is not only arches in CC but normal people
or other projects? Does it impede the process?

Thanks!

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Yury German]

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

OK so let me repeat the comments that were made on @dev  (and expand a bit further) and close the issue.

1. Maintainers are free to cc the non-stable and experimental arches as part of their call for stabilization. It is up to the maintainer of the package to decide.

2. This is providing that there is no problems caused by stableboy or extra dependencies raised
Note: as a follow up change was made: 07:47 <@kensington> leio: b-man: good point, dropped sparc from stable_arches

3. Clean up is required as part of the security bug process, and if an arch is holding it up (example hppa before Slyfox took it over) an issue would have to be raised with the QA team for action. [1]

4. Bugs will be closed without waiting for any non-security supported arches, once the security process is complete.

5. Security bugs are not re-assigned since they are assigned as a vulnerability in bugzilla. If you need to continue work on the bug, please feel free to open another bug for the particular arch for stabilization, fix, etc.

If you have any questions please let me know.


[1] - https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bcleanup.5D_status

________________
Yury German
Gentoo Security Team | Planet Gentoo | Gentoo Infrastructure
Email: blueknight@gentoo.org

GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD  FA00 EEAF ED89 024C 043

> On Sep 13, 2017, at 4:03 AM, Sergei Trofimovich <slyfox@gentoo.org> wrote:
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

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

On Wed, 13 Sep 2017 22:44:23 -0400
Yury German <blueknight@gentoo.org> wrote:

Thank you! That's very helpful. A few clarifying questions below
to be absolutely clear.

> OK so let me repeat the comments that were made on @dev  (and expand a bit further) and close the issue.
> 
> 1. Maintainers are free to cc the non-stable and experimental arches as part of their call for stabilization. It is up to the maintainer of the package to decide.
> 
> 2. This is providing that there is no problems caused by stableboy or extra dependencies raised
> Note: as a follow up change was made: 07:47 <@kensington> leio: b-man: good point, dropped sparc from stable_arches
> 
> 3. Clean up is required as part of the security bug process, and if an arch is holding it up (example hppa before Slyfox took it over) an issue would have to be raised with the QA team for action. [1]

'Cleanup' is only vulnerabe ebuild removal, not CC removal from the bug, right?

> 4. Bugs will be closed without waiting for any non-security supported arches, once the security process is complete.

CC for exp lagging arches are not removed from the bug, right?

> 5. Security bugs are not re-assigned since they are assigned as a vulnerability in bugzilla. If you need to continue work on the bug, please feel free to open another bug for the particular arch for stabilization, fix, etc.
> 
> If you have any questions please let me know.
> 
> 
> [1] - https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bcleanup.5D_status

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

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

On Thu, 14 Sep 2017 08:28:23 +0100
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> On Wed, 13 Sep 2017 22:44:23 -0400
> Yury German <blueknight@gentoo.org> wrote:
> 
> Thank you! That's very helpful. A few clarifying questions below
> to be absolutely clear.
> 
> > OK so let me repeat the comments that were made on @dev  (and expand a bit further) and close the issue.
> > 
> > 1. Maintainers are free to cc the non-stable and experimental arches as part of their call for stabilization. It is up to the maintainer of the package to decide.
> > 
> > 2. This is providing that there is no problems caused by stableboy or extra dependencies raised
> > Note: as a follow up change was made: 07:47 <@kensington> leio: b-man: good point, dropped sparc from stable_arches
> > 
> > 3. Clean up is required as part of the security bug process, and if an arch is holding it up (example hppa before Slyfox took it over) an issue would have to be raised with the QA team for action. [1]  
> 
> 'Cleanup' is only vulnerabe ebuild removal, not CC removal from the bug, right?
> 
> > 4. Bugs will be closed without waiting for any non-security supported arches, once the security process is complete.  
> 
> CC for exp lagging arches are not removed from the bug, right?
> 
> > 5. Security bugs are not re-assigned since they are assigned as a vulnerability in bugzilla. If you need to continue work on the bug, please feel free to open another bug for the particular arch for stabilization, fix, etc.
> > 
> > If you have any questions please let me know.
> > 
> > 
> > [1] - https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bcleanup.5D_status  

Ping.

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs

[Sergei Trofimovich]

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

On Sat, 23 Sep 2017 21:04:07 +0100
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> On Thu, 14 Sep 2017 08:28:23 +0100
> Sergei Trofimovich <slyfox@gentoo.org> wrote:
> 
> > On Wed, 13 Sep 2017 22:44:23 -0400
> > Yury German <blueknight@gentoo.org> wrote:
> > 
> > Thank you! That's very helpful. A few clarifying questions below
> > to be absolutely clear.
> >   
> > > OK so let me repeat the comments that were made on @dev  (and expand a bit further) and close the issue.
> > > 
> > > 1. Maintainers are free to cc the non-stable and experimental arches as part of their call for stabilization. It is up to the maintainer of the package to decide.
> > > 
> > > 2. This is providing that there is no problems caused by stableboy or extra dependencies raised
> > > Note: as a follow up change was made: 07:47 <@kensington> leio: b-man: good point, dropped sparc from stable_arches
> > > 
> > > 3. Clean up is required as part of the security bug process, and if an arch is holding it up (example hppa before Slyfox took it over) an issue would have to be raised with the QA team for action. [1]    
> > 
> > 'Cleanup' is only vulnerabe ebuild removal, not CC removal from the bug, right?
> >   
> > > 4. Bugs will be closed without waiting for any non-security supported arches, once the security process is complete.    
> > 
> > CC for exp lagging arches are not removed from the bug, right?
> >   
> > > 5. Security bugs are not re-assigned since they are assigned as a vulnerability in bugzilla. If you need to continue work on the bug, please feel free to open another bug for the particular arch for stabilization, fix, etc.
> > > 
> > > If you have any questions please let me know.
> > > 
> > > 
> > > [1] - https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs_in_.5Bcleanup.5D_status    
> 
> Ping.

Ping^2

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]