> I remember times when there where two weeks test cycles where the whole > thing was frozen with zero changes for at about a week, and if any > serious problems were found they were fixed and then there was the next > test cycle. > > Why is there now always such a hurry to get everything out within a > week? > > Why are there always extremely aggressive timelines (with at least three > publically announced release dates for sarge already passed) instead of > making everything more relaxed for being able to improve sarge without > being in a big hurry?
My general feeling about all this is that things have changed.....a lot. In these "good old days", Debian was kinda small both in term of packages and number of maintainers (yep, even when the woody release happened) and the process you describe has proven to work. Probably a lot of things changed since thenand it seems that the relaxed timelines you're talking about do not really fit. Indeed, we are in a relaxed timeline since nearly one year, when the base system was frozen in August 2004. All package maintainers should have then started to "mentally freeze" their packages and track down unsolved RC issues in sarge....and be sure that RC issues fixed in experimental/unstable would indeed go to sarge. It worked for most of the packages...and seems to fail for some. IMHO, this only proves that some packages are poorly maintained, or more precisely, that their current maintainer has problems to handle the workload. Many many packages are currently switching to team maintenance because of that. I think that etch will show this tendency even more....with teams structuring themselves in specialised activities, one of them being the handling of RC bugs when releases are close..:-) About 9000 source packages....about 1000 active developers. That mostly makes the point..:-) Among the tons of problems we are facing for etch, the size problem will be one : I'm wondering whether it is good to see ITP's flooding around -devel for tons of anecdotic things while some of our "key" packages are poorly maintained because their only maintainer cannot handle the workload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
