Re: [gentoo-project] Re: [gentoo-dev-announce] call for agenda items, council meeting 8/13

[Michał Górny]

On czw, 2017-08-03 at 09:21 -0400, Mike Pagano wrote:
> On Thu, Aug 03, 2017 at 02:18:42PM +0200, Michał Górny wrote:
> > Dnia 3 sierpnia 2017 13:18:57 CEST, Mike Pagano <mpagano@g.o> napisał(a):
> > > Hello,
> > >
> > > On 08/03/2017 03:06 AM, Michał Górny wrote:
> > > > On pon, 2017-07-31 at 18:13 -0400, Mike Pagano wrote:
> > > > > On 07/31/2017 10:15 AM, William Hubbs wrote:> All,
> > > > > >
> > > > > > The next Gentoo Council meeting is on Sunday, aug 13 at 18:00 UTC
> > >
> > > in the
> > > > > > #gentoo-council channel on freenode.
> > > > > >
> > > > > > Please reply to this message with any items you would like us to
> > >
> > > discuss
> > > > > > or vote on.
> > > > >
> > > > > <snip>
> > > > >
> > > > > I would like to submit the following for the council to discuss and
> > >
> > > vote
> > > > > upon.
> > > > >
> > > > > At the moment, we have a capacity problem around kernel
> > >
> > > stabilization.
> > > > > Upstream kernels are released at an extremely high rate and the
> > >
> > > Gentoo
> > > > > Kernel Maintainers do their best to release them shortly thereafter.
> > > > >
> > > > > Sometimes, arch teams are not able to respond to stablereqs in a
> > >
> > > timely
> > > > > manner. This is not a complaint on their efforts, just a description
> > >
> > > of
> > > > > what happens often for arch teams that are stressed to capacity.
> > > > >
> > > > > When the motivation for a STABLEREQ is a high severity security bug
> > > > > (e.g. root exploit), this delay in stabilization results in us
> > >
> > > having to
> > > > > keep exploitable kernels in the tree in order not to drop the latest
> > > > > stable for a specific architecture.
> > > > >
> > > > > The procedure outlined below allows for auto-stabilization of minor
> > > > > bumps by the Gentoo kernel team for any previously stabled major
> > >
> > > version
> > > > > kernel.[1]
> > > > >
> > > > > I welcome discussion, better ideas or anything else that makes
> > > > > everyone's lives easier and user's systems more secure.
> > > > >
> > > >
> > > > I'm not sure if this is really something for the Council to discuss.
> > > > Sounds like a regular problem that's best dealt either with arch
> > >
> > > teams
> > > > directly or on gentoo-dev.
> > >
> > > This is really something I would like the Council to discuss and vote
> > > upon.  I've tried to do this through arch teams and the result is root
> > > exploitable kernels sitting in the tree (which is the state right now
> > > as
> > > I write this).  Certain architectures will not perform stabilization no
> > > matter how much I ask. Or how many bugs I submit. Or how many times I
> > > pop into IRC and ask.  And I only do this when I am forced to keep root
> > > exploits in the tree.
> > >
> > >
> > > > <private hat>
> > > >
> > > > I don't mind stabilizing new minor releases automatically but I'd
> > >
> > > prefer
> > > > if they were at least build-tested with the default config once.
> > > > However, I doubt anybody's going to shoot you if you take
> > > > the responsibility for your actions and don't break anything
> > >
> > > important
> > > > in the process.
> > > >
> > > > </private hat>
> > > >
> > >
> > > You're preference would result in the status quo.  Exploitable kernels
> > > sitting in the tree.  I don't have the hardware to build and boot test
> > > on every architecture.
> >
> > Well, I meant making the hardware available to you here. This is sth infra and/or arch testers should be able to do.
>
> Sorry, my misunderstanding.
>
> I would love that. I would need to be able to just install / build and
> boot.  If anyone cares, I have amd64 and x86 at this momment in time.
>

Filed a bug to track this. Let's try the official channels first.

https://bugs.gentoo.org/626982

-- 
Best regards,
Michał Górny