Re: Faster Release Cycle = More Up to date Packages...
Johnny Ernst Nielsen wrote:
> Debian's current problem with old packages can be seen by the fact
> that a number of vendors have reportedly dumped the current Stable
> release in favor of the Testing distribution some time ago.
> That can only mean that currentness of content has become more
> important than bugs, security and stability.
> It means that Debian is not in balance with currentness of contents.
> Debian can not continue down that path without compromising Debians
> own policy of supporting its users.
So someone was more interesed in currency than in stability, and they
swiched from the debian tree that emphases the later to the tree that
emphasises the former. And what was the problem again?
> The package currentness issue is controlled by an other issue:
> - How long the period of a freeze lasts before all RC bugs are fixed.
Wrong. You would do well to make sure you're fully up-to-date on how
debian's release process is currently handled before posting half-baked
critisism of it. A casual persusual of the last 10 months or so of
postings to debian-devel-announce might be a useful first step.
> The main proposal is to introduce a fixed short Testing development
> period into the development cycle like this:
>
> 1. Feed Unstable packages to Testing for a fixed short period of time.
So you think that dumping a large number of upstream updates of packages
into testing in a very short period of time will result in a better
integrated and less buggy debian. I see.
> For the sake of examples, I could imagine the Testing development
> period being defined to last for 3 months.
As, for example, it was planned to be in between the releases of hamm
and potato, IIRC. And we know how well that worked.
> Introducing a fixed short development period for Testing
> automatically reduces the time between Stable releases.
> Limiting the time during which Testing is able to recieve RC bugs
> from Unstable (the Testing development period), should reduce the
> number of RC bugs in Testing, and thus shorten the freeze time.
Here's something to think about. Base has been frozen for 8 months,
tasks + standard have been quasi-frozen for several months, and yet we
are still getting new release critical bugs filed on those sections of
the distribution, on a daily basis. Why do you think that might be?
> a lot of time for RC bugs to get from Unstable to Testing, thus
> prolonging the resulting Woody Testing freeze, thus adding to the age
> of the packages in Stable 3.0. They will be about 6 months old at the
> time of release (half a year).
The versions of mozilla and X in testing are not 6 months old.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: