public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Aaron Bauman <bman@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
Date: Tue, 4 Dec 2018 16:18:36 -0500	[thread overview]
Message-ID: <20181204211836.GM16376@monkey> (raw)
In-Reply-To: <1543894892.810.5.camel@gentoo.org>

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

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

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

  parent reply	other threads:[~2018-12-04 21:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 12:31 [gentoo-project] Call for agenda items - Council meeting 2018-12-09 Mart Raudsepp
2018-11-30 16:17 ` William Hubbs
2018-11-30 16:24   ` Alec Warner
2018-12-06 17:32     ` William Hubbs
2018-12-01  7:47 ` [gentoo-project] Re: [gentoo-dev-announce] " Mikle Kolyada
2018-12-02  9:30   ` grozin
2018-12-02 15:55     ` Michał Górny
2018-12-02 16:06     ` Michał Górny
2018-12-04  0:16   ` Aaron Bauman
2018-12-04  0:39     ` M. J. Everitt
2018-12-04  1:29       ` Aaron Bauman
2018-12-04  3:41     ` Michał Górny
2018-12-04  9:54       ` Kristian Fiskerstrand
2018-12-04 10:06         ` Mart Raudsepp
2018-12-04 21:18       ` Aaron Bauman [this message]
2018-12-04 22:51     ` Sergei Trofimovich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181204211836.GM16376@monkey \
    --to=bman@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox