Re: [gentoo-dev] rfc: stabilization policies

[Tom Wijsman]

On Wed, 21 Aug 2013 12:07:16 +0400
Sergey Popov <pinkbyte@g.o> wrote:

> 21.08.2013 00:06, Tom Wijsman пишет:
> > On Tue, 20 Aug 2013 15:41:42 -0400
> > Rich Freeman <rich0@g.o> wrote:
> >
> >>> Let me dig up an example...
> >>>
> >>> Our last sys-kernel/gentoo-sources stabilization was 3 months ago:
> >>
> >> I don't really see a problem with stable package being all of 3
> >> months old.  Contrast that with youtube-dl which pull from ~arch
> >> and rebuild about 3x/week.
> >
> > For something that releases once to twice a week, it is a problem;
> > we're not talking about a package that gets some slow commits here,
> > no, let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233
>
> And you are dead sure that shiny new versions does not need testing in
> Gentoo for a reasonable amount of time(30 days)? If yes, then we have
> a problem in definitions here(thus, i am not talking about security
> stabilizations, they should be done as quickly, as bug reveals)

3.10 is not a shiny new version, it has been in the Portage tree for 7
weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's
almost double the time you are suggesting.

> > That's a lot of commits; now you need to realize that every single
> > commit in this means something, a lot of them are bug fixes
> > (stability, security, reliability, anti corruption, ...) whereas of
> > course a part of it also introduces parts of new features and
> > refactoring.
> >
> > Desktop users might not care for all of these, but sysadmins will;
> > actually, that's what this thread is about, they are switching to ~
> > because of things like this. Who are we stabilizing for then?!
>
> You should undestand that stabilizing new kernel should also imply
> that some important modules, presenting in tree will also work with
> them. I really do not like slow upstreams and situations like with
> nvidia-drivers, but i understand that this is not kernel team matter,
> it is upstream problem.

Why should an external proprietary module that does not fix what is
broken for 7 weeks now block stabilization; it has never blocked
stabilization before, and I do not see a reason it should now...

> And that fact, that you can successfully build and run kernel for a
> couple of hours, does not make it "good, well tested stable candidate"

Having people run it for 7 weeks is not a couple of hours.

> >
> >     Bitrot due to a lack of resources.
> >
>
> Such problem is exists, yeah, i agree. But do not overcomplicate
> things. We should fight with lack of resources, not with turning
> stable into "just more old, but also breakable testing"

Well, my thoughts is that the way we are doing it now we aren't going to
be able to deal with the lack of resources; so, a different approach is
necessary and I don't see how it is "old, but also breakable"...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D