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

2017-10-13 Thread Sergei Trofimovich
On Sat, 23 Sep 2017 21:04:07 +0100
Sergei Trofimovich  wrote:

> On Thu, 14 Sep 2017 08:28:23 +0100
> Sergei Trofimovich  wrote:
> 
> > On Wed, 13 Sep 2017 22:44:23 -0400
> > Yury German  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


pgpdubsZsuMuN.pgp
Description: Цифровая подпись OpenPGP


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

2017-09-23 Thread Sergei Trofimovich
On Thu, 14 Sep 2017 08:28:23 +0100
Sergei Trofimovich  wrote:

> On Wed, 13 Sep 2017 22:44:23 -0400
> Yury German  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


pgpS9_exdyk7d.pgp
Description: Цифровая подпись OpenPGP


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

2017-09-14 Thread Sergei Trofimovich
On Wed, 13 Sep 2017 22:44:23 -0400
Yury German  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


pgpXroUy2YKpe.pgp
Description: Цифровая подпись OpenPGP


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

2017-09-13 Thread Yury German
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: bluekni...@gentoo.org

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

> On Sep 13, 2017, at 4:03 AM, Sergei Trofimovich  wrote:
> 



signature.asc
Description: Message signed with OpenPGP


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

2017-09-13 Thread Sergei Trofimovich
On Wed, 13 Sep 2017 09:00:06 +0200
Ulrich Mueller  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


pgpUPRBdzfZXM.pgp
Description: Цифровая подпись OpenPGP


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

2017-09-13 Thread Ulrich Mueller
> 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


pgpOLcjXAYHx2.pgp
Description: PGP signature


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

2017-09-12 Thread Matt Turner
On Mon, Sep 11, 2017 at 3:07 PM, Aaron Bauman  wrote:
> On Monday, September 11, 2017 3:43:13 AM EDT Sergei Trofimovich wrote:
>> On Sun, 10 Sep 2017 22:18:08 +
>>
>> bugzilla-dae...@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  changed:
>> >What|Removed |Added
>> >
>> > --
>> > -->
>> >  CC|sp...@gentoo.org|
>> >
>> > --- Comment #16 from Aaron Bauman  ---
>> > 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.



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

2017-09-11 Thread Aaron Bauman
On Monday, September 11, 2017 3:43:13 AM EDT Sergei Trofimovich wrote:
> On Sun, 10 Sep 2017 22:18:08 +
> 
> bugzilla-dae...@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  changed:
> >What|Removed |Added
> > 
> > --
> > --> 
> >  CC|sp...@gentoo.org|
> > 
> > --- Comment #16 from Aaron Bauman  ---
> > 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.



signature.asc
Description: This is a digitally signed message part.