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

[Sergei Trofimovich <slyfox@gentoo.org>]

[-- 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 --]