Re: [gentoo-dev] rfc: stabilization policies

[Doug Goldstein]

On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman <rich0@g.o> wrote:

> On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel
> <dilfridge@g.o> wrote:
> >
> > Stable implies "not so often changing". If you really need newer
> packages on a
> > system that has to be rock-solid, then keyword what you need and nothing
> else.
>
> ++
>
> 30 days is too long?  How can something new be stable?  Stable doesn't
> mean "I don't think this is broken."  Stable means "lots of others
> have already been using this and so far there aren't many reports of
> breakage."
>

Stable also means this is less broken than current stable. In the past I've
gotten push back from arch teams on all sorts of items I consider to be
unrelated to the stabilization request. Yes it'd be great if the world was
black and white and 30 days was a magical cut off but many times its not.
If current stable is causing a crash or some bad user case, I'll ask for a
quick stabilization of a revbump that contains a small scope patch that a
user can confirm it fixes the issue.


>
> According to distrowatch RHEL is at 2.6.32.  I'm sure it has a
> bazillion backports, but that is what I'd call stable.  Running stable
> means starting to use the stuff everybody else is about ready to stop
> using.  When an upstream releases a new stable release, that means
> that it is just now ready for testing, and chances are they'll have
> another stable release before their previous release really is stable.
>

Apples and oranges. Its 2.6.32 for the kabi, which they maintain and
support. They have plenty of things that landed in 3.7 in RHEL 6.4. They
have a solid QA procedure to vet their kernels and they're not afraid to
turn the crank on small targeted fixes and pushing those out to resolve
issues as the release matures.


>
> If you need the release two days after it comes out, you're not really
> looking for a stable release.
>
> At work we typically buy stuff about a year after it comes out, and by
> the time we're done doing integration and testing it is probably two
> years old and we've gotten 27 patches in the meantime.  That's stable.
>

Correlation is not causation. Just because software or hardware sat of the
shelf for a year doesn't mean its any more or less stable when it was
originally shipped. If a vendor has a high level of QA with multi-layed
test processes that product will probably more stable out the door than a
vendor with no QA that kicked the product out the door and let their early
adopters find the bugs over the past year. I say probably because again the
world isn't black and white. Your use case with both products could be
exposing a corner case that no user before you and no QA engineer before
you had tried and both products will go boom.


>
> Gentoo is one of the few distros that really lets you mix and match,
> so run stable on the stuff you don't care about, and if the purpose of
> the box is to serve apps on Rails then by all means use ~arch on Ruby.
>  You can do that and not worry about whether it is going to be broken
> by the latest glibc or coreutils or whatever.
>
> Rich
>
>
Its also precisely that mix and match that might cause instability due to
people not testing things. Case in point QEMU 1.6.0 just came out and it
went through a number of release candidates but no one ever saw that it
depends only on Python 2.4 but actually needs Python 2.6. That's kind of
like Gentoo, a package says it depends on libfoo 1.0 or higher and the dev
that tested stable baz 0.8 confirmed it worked with libfoo 1.0, but baz 0.9
in ~arch still depends on libfoo 1.0 but really needs libfoo 1.1 and libfoo
1.1 is ~arch as well. So the developer running ~arch believed that baz 0.9
works fine since he has ~arch libfoo.

My point is what Gentoo calls "stable" is just something that usually 2 or
more people have compiled and installed vs ~arch which 1 or more people
have compiled and installed.

-- 
Doug Goldstein