On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel > <dilfri...@gentoo.org> 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
