On Wed, Feb 14, 2007 at 12:17:56PM -0500, Michael S. Peek wrote: > Andy Hawkins wrote: > >That would be just fine. As I understand it, stuff doesn't make it from > >unstable to testing until it's been working in unstable for a while, so > >the > >chances of testing breaking horribly are reduced. > > > >It can still happen though, so there's a possibility that in the early > >stages of development for the next release, testing could well break > >your > >system. > > > Okay, so, just to make sure that I understand completely. Once Etch > becomes the new stable release, does the unstable release replace the > testing release? I.e. if I leave my systems at "testing", will I come > in one day and find that all of my computers want to upgrade a billion > packages to become what was Sid the day before, or does the testing > release stay the same and continue to evolve at it's regular pace? > you are essentially right except that it won't become a clone of sid because packages have to be in sid for x number of days (I think its 10) before they are allowed to move into testing. So it will probably be pretty close to sid, but lag behind by a few days. I'm going to say what I always say to folks thinking of running "testing". Because of the lag in package migration from sid to testing, when things break in testing they tend to stay broken for a while (like at least x days from above). AIUI testing is for people who want to really test stuff and see what's broken and submit bug reports etc. I personally think that if you want the latest greatest stuff one should run sid instead of testing. If something breaks in sid, it tends to fix itself pretty quickly. sometimes within just a day or so. Consider this example. Lets say that a part of X breaks with a certain combination of hardware and drivers. But imagine that by chance this breakage doesn't show up or get reported when this particular combination is in sid so that combination filters into testing. in testing someone hits that problem and has a borked X system. They spend a day or two on this list trying to solve the problem and determine that it is in fact a bug. The bug gets filed. The maintainer happens to be really diligent and submits a bug fix to sid within just a day or so. Now, at this point there has been breakage in testing of 3 or 4 days. The supposed bug fix has to sit in sid for x days before it comes down into testing. So you as a testing install are looking at x + 3 or 4 days of breakage. What happens if the bug fix doesn't actually solve your bug? process repeats. Another option. you, knowing that this bug fix is in sid move one machine up to sid to see if that bug fix works for you, sparing you the x days wait. It doesn't work, so you update the bug report. Maintainer grinds out another fix in a day or so. Still doesn't work. You and maintainer go back and forth trying to solve the problem. Finally days and days later the bug is fixed and will migrate into testing in x days. Anyone else in testing with the same bug as you is now looking at x + 3 or 4 + days and days of waiting for the fix to come down. Obviously the hope is that most of these sorts of bugs never make it out of sid. A package that is getting lots of bug fixes will stay in sid because it never hits x days of stability to make the migration. Testing is just that... where lots of testing takes place. Packages in testing have made it through the sid wringer and will now settle down for some serious long-haul testing. And that's great. BUt when they break it can be a problem. I think a lot of people view testing as "a little more up-to-date" than stable but "not as scary" as sid. I personally think its more like testing is "more up-to-date than stable and getting more so day by day, but very scary if you need/want your system to be up and running reliably." I personally think that testing, at least right after a new relase, requires more skill than sid. Sid just fixes itself up right away. I also think this changes as the release approaches. Further down the release cycle, testing gets naturally more and more stable and easier and easier to administer and less likely to break as the new versions get massaged into their final release condition. sorry for the ramble. its all my .02, those are worst case scenarios above and ymmv A
Attachment:
signature.asc
Description: Digital signature