Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Aaron Bauman]

On Tue, Dec 04, 2018 at 04:41:32AM +0100, Michał Górny wrote:
> On Mon, 2018-12-03 at 19:16 -0500, Aaron Bauman wrote:
> > > On 25.11.2018 15:31, Mart Raudsepp wrote:
> > > > In two weeks from now, there will be a council meeting again. Now is
> > > > the time to raise and prepare agenda items that you want us to discuss
> > > > and/or vote upon.
> > > >
> > > > Please respond to this message on the gentoo-project mailing list with
> > > > agenda items.
> > > > The final agenda will be sent out on 2018-12-02, so please make sure
> > > > you post any agenda items before that, or we may not be able to
> > > > accommodate it into the next meeting.
> > > >
> > > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the
> > > > #gentoo-council FreeNode IRC channel.
> > > >
> > > >
> > > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19
> > > >
> > > >
> > > > Thanks,
> > > > Mart Raudsepp
> >
> > I would like to propose, once again, that the council vote on the
> > following items:
> >
> > 1. The council approves all architectures that are maintained as stable
> > architectures.
> >  - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> >
> > Conversely, the council also may remove/drop such architectures as
> > needed (c.f. item 2).
>
> What happens if Council votes 'no' to this item?  Do all arches become
> unstable?
>

Of course not, that would be silly. I suppose better wording would have
been something like:

"The council will begin approving the addition and removal of all
architectures considered stable. Upon approval of this item, all
current stable architectures will remain."

> Don't introduce votes for confirming status quo because they make no
> sense.  If there's a specific change you're proposing, propose it
> and be specific so that people can discuss it ahead of time.
>

Ugh... status quo? I am not sure how this is status quo...

> > 2. The council approves that all stable architectures are subsequently
> > determined to be security supported. Thus, an architecture may not be
> > stable and *not* security supported.  This disparity has implications in
> > processes and timeliness of actions taken to mitigate vulnerabilities
> > reported.
> >  - e.g. amd64 is approved as stable arch and thus is security supported.
> >  - e.g. arm is dropped as a stable arch thus is no longer security supported.
> >
> > Overall, both of these items will provide a much clearer understanding
> > of how security is able to proceed with mitigating vulnerabilities in
> > the tree, how users view and understand what architectures are stable
> > and security supported, and allow the security team and maintainers a
> > clearer/cleaner process to follow.
> >
>
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team?  Because this
> sounds like you're implying that security team can't make up their mind.
>

Absolutely, but we have the GLEP draft in the open now. So, here we go.

> Also, if the Council votes 'yes', what happens next?  Does security
> accept all stable arches?  Do stable arches get demoted implicitly based
> on security project considerations?
>

Yes, we would accept all stable arches as security supported. 

No, security would simply petition the council should an arch need to be
removed from stable.

> --
> Best regards,
> Michał Górny



-- 
Cheers,
Aaron