Re: Release update: minor delay; no non-RC fixes; upgrade reports
> 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.
Reply to: