Re: FREEZE RESCHEDULED
Florian Lohoff wrote:
> > I agree, with the reservation that I believe that there should be both
> > a frozen and unstable distribution until we're ready to go to release.
>
> *Oergs* No thanks - We should keep the freeze time as SHORT AS POSSIBLE
> otherwise we are releasing an out of date distribution like Slink. So i
> would like to force developers to stabilize the current unstable/frozen
> to be release ready instead of "Same-procedure-as-everyday" and uploading
> to unstable.
Well, a short freeze is important, but I think less important than a more
frequent freeze/release schedule. If Debian cannot manage to release more than
once a year, we are always six months out of date on average. Both of us, I
think, want Debian stable to be more up to date, the question is the best way
to accomplish this. Given the high penalty to developers of the current
practice, we do not tend to freeze until we are close enough to stable to
ENSURE a short freeze, but the purpose of freezing is to stabilize, thus the
cart goes before the horse and therefore it takes much longer to achieve an
adequate stability because we haven't yet frozen.
> > I realize that the primary difficulty of this approach has been and
> > remains the lack of space on Debian mirrors, and an inability to rsync
> > only a portion of the distribution -- i.e., stable and frozen but not
> > unstable and experimental. I recognize that some effort has already
>
> I dont think this is the MAIN problem. The main problem is that
> most Debian developers dont care on the "stable" distribution which
> is in my eyes a primary goal. Everybody is working on unstable for
> years and dosnt want to stay with something called "frozen".
This is a fair point, and one solution might be to prevent developers from
uploading to unstable if they have release-critical bugs in frozen. I think we
just need to emphasize the importance of getting frozen stable, and encourage
people to work on it, rather than forcing them by denying them the ability to
maintain unstable packages during the interval.
My analogy is the public radio station, which periodically has to raise money
for its operations by soliciting donations. During the fund raising drive,
they do not stop all regular programming, but intersperse it with frequent
appeals. When Debian freezes and disables unstable altogether, it's like the
regular programming has been canceled until stability is reached, but this
approach penalizes people who have ALREADY stabilized their packages for
release and have updates they want to submit.
> > is why it is called unstable). But the alternative of running software
> > which is more than a year out of date is often unacceptable. If we could
> > freeze a snapshot, and stabilize that snapshot, without disrupting work on
> > the unstable branch, it would be far less difficult to freeze in general,
> > thus we could do it sooner and more frequently.
>
> Most of the maintainers would even dare to think about frozen snapshot.
Why not? I didn't say the snapshot should be completely arbitrary, we could
say that we have specific release goals (such as an update to a new version of
X, a new kernel release, new perl, etc.) and announce the freeze when we meet
those milestones. Once the freeze has been announced, everybody will know what
date it will happen and can begin stabilizing their packages for release
immediately in order to preserve their right to upload to unstable after it
happens. When the freeze date comes, we stick to it, the current state of the
system, with whatever release critical bugs still exist, is frozen, and we
spend the next interval working to remove those bugs and ready the frozen
distribution for stable release.
Reply to: