On Tue, Feb 08, 2011 at 11:43:33AM +0000, Roy Bamford wrote: > On 2011.02.07 20:50, Markos Chandras wrote: > [snip] > > > My suggestion, as I said to fosdem, is to freeze, or take a > > snapshot if you like, of the current tree, stabilize what you need to > > stabilize, test the whole tree ( at least compile wise ) for a couple > > of weeks and then replace the existing stable tree. Of course this > > requires automated script testing, hardware facilities etc etc that > > we don't have so claiming that stable tree is "stable" is quite > > wrong. > > > > Regards, > > -- > > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 > > > > Markos, > > This is exactly what releng used to do for installer CDs. This was > last used for 2008.0 CD/DVD. A snapshot of the stable tree was taken in > February 200.8 and the release hit the mirrors in September. > > The seven month test/fix/retest that it took meant that the CD would > not boot on new hardware as the kernel lacked drivers. > > You will find similar lags when releng used this approach for other > earlier releases. > > We would need to move to a release cycle like the kernel. Calling a > feature freeze at the start of the test cycle. As we can't everything, > we might as well distribute binaries of what was tested - just as > releng used to do. > > To me thats not Gentoo as we would loose the rolling updates. > > There are degrees of stable. I believe most Gentoo users > realise this fairly early on and stick with Gentoo because they like > the balance it strikes between Debian stable and bleeding edge. > There is a price to pay for being more up to date and it a trade off > Gentoo users are aware off. Of course, that does not prevent them > bringing breakages to our attention. > > -- > Regards, > > Roy Bamford > (Neddyseagoon) a member of > gentoo-ops > forum-mods > trustees
Roy, I see what you are saying. However, the 6 months testing is far from what I have in mind. My only intention is to bring a more stable experience to our users. Or, stop claiming that our stable tree rocks and Gentoo is perfect for servers because it is not. Ye ye ye I know that many many of you have Gentoo on servers but do not forget that you are developers and you know your way around during breakages. Yes, stable tree breaks FAR TOO often. I blame myself for my arch testing of course however I can't do much about that. Arch teams cannot afford any slacking (at least the two major arches) because we have 100 new bugs every three days. This is extremely dangers to demotivate people who will burn out sooner or later. You may think that this is an extreme case but I can guarantee you that amd64 stable tree can become really obsolete within one month. . Our stable tree is definitely not suitable for server usage unless you have plenty of free time to deal with stupid upgrades because nobody, for example, cared to write a proper elog or news item. You are probably not aware of that, since 99% of you run testing tree however if you visit forums and stuff you will see many many users complaining about stable tree. If we keep going down this road we will end up sooner or later to be similar to Exherbo where only really power users and developers will know their way around. Either you like it or not, arch teams are understaffed. All of them. Therefore we cannot afford a updated stable tree with high QA around it. We need to find a more efficient way to test packages on testing tree so we can mark them stable with minimal time and cpu cost. We need dedicated build boxes, like Diego's tinderbox, to test the testing tree over and over against critical/common/trivial QA problems. If we manage that, moving packages from testing->stable will be much more time efficient and we can guarantee a high quality stable tree. ps1: Personally I have stopped suggesting gentoo stable for server usage and I always suggest testing to new users. ps2: Roy, this is not a personal attack. Do not misinterpret my tone :) Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
pgp2plyh7a28v.pgp
Description: PGP signature
