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

[Aaron Bauman]

On Tue, Dec 04, 2018 at 12:39:07AM +0000, M. J. Everitt wrote:
> On 04/12/18 00:16, 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).
> >
> > 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.
> >
> > Standing by to answer RFI's.
> >
> > --
> > Cheers,
> > Aaron
> By all means correct me if I'm wrong, but my understanding was that a
> stable *arch* meant that there was a consistent dependency tree, and this
> was maintained to ensure there was some integrity to that arch's packages.

Correct.  Which directly correlates to how the security team and
maintainers are able to proceed with security related matters. Very
simply put:

Vulnerability Identified->Package patched/bumped->Stabilization
occurs->Vulnerable package (read... ebuild) is removed->GLSA issued if
required->Bug closed.

> It had/has nothing to do with security-supported which was another separate
> classification entirely.
>

Correct. Historically, it has been treated separately, but due to the
previous statement above it is quite interdependent.

> I see merit in simplifying the categorisation of arch package sets, but I'm
> not sure this particular change/proposal will serve much of a purpose,
> other than further reinforcing that amd64 is the only arch that Gentoo
> officially supports; and sets the wheels in motion for eventual bitrot of

Our intent is not bitrot of any arch. Many "alt-arches"
(uncommon/exotic... pick a description) keep up just fine... if not
exceed more common arches.

> anything else, streamlining the way for deprecation and treecleaning
> anything which is not relevant for amd64 arch.
> Please clarify that this is not, and will not be the case with this
> policy/proposal.
>

This is *not* the case and will never be the case for this proposal.  I
don't believe anyone would vote/recommend such a thing if an arch is
capable of being supported.

-- 
Cheers,
Aaron