4 ms·
Freeze date and Freeze Policy for Debian Jessie
- shmerl 13y agoWhat happened to the proposal for always releasable Debian by the way? (https://lwn.net/Articles/550032/ https://lwn.net/Articles/550032/) Was there anything done to implement it? Months long (or even more than a half a year long) freezes are really annoying in Debian.
- ISL 13y agoPerhaps the plan of keeping testing "releasable" would drive away the users who are interested in fairly stable packages from upstream? Debian may now have enough users (and use-cases) that it could sustain five branches: stable, release-candidate, testing, unstable, and experimental . I don't know enough about the difficulties with stable to know whether it's possible to maintain a nigh-releasable "release-candidate" with only a few RC bugs.
- shmerl 13y ago> Perhaps the plan of keeping testing "releasable" would drive away the users who are interested in fairly stable packages from upstream? I'm not sure how exactly, can you elaborate please? The way I understood that proposal, was pushing package maintainers not to postpone some work until very close to the release (which keeps Debian testing messy most of the time), but rather update packages regularly, keeping them always close to "releasable" state. This could reduce potential freeze period significantly and only improve the quality of Debian testing in general.
- ISL 13y agoSometimes, packages can arrive from upstream with desireable features and the occasional nasty bug. Back in ~Woody or so, I switched to testing in order to gain necessary functionality in a number of packages. If testing hadn't had the features I needed, I would have gone to another distro (perhaps Gentoo, at the time). If some RC-bugs are fixed by the original developers upstream given enough time, then maintaining a continuously "releasable" distro will be more work than the periodic-freeze paradigm, as package maintainers will be forced to clean up upstream's code as it arrives. I don't know if Debian has enough people-power to make that happen. The alternative is simply rejecting upstream's changes until the RC-bugs are fixed. Once upstream packages become interdependent, I imagine things get thorny fast. If it's possible to spread the work out over time, without generating significant extra quantities of work, and simultaneously yield more-timely releases, then it'd be better to do that! :).
- pekk 13y agoPerhaps Ubuntu has already demonstrated for years that many people are interested in packages which aren't extremely old but are pretty stable? It would be great if Debian took away Ubuntu's reason for existing. But that hasn't happened yet.
- mrud 13y agoYes, one important part (auto-removal of buggy packages) was implemented, see http://lists.debian.org/debian-devel-announce/2013/09/msg00006.html http://lists.debian.org/debian-devel-announce/2013/09/msg000... for the announcement. http://udd.debian.org/cgi-bin/autoremovals.cgi http://udd.debian.org/cgi-bin/autoremovals.cgi is the list of packages targeted for auto-removal.
- X-Istence 13y agoWe are happy to announce that we will freeze Jessie at 23:59 UTC on the 5th of November 2014. Is this a typo and it is actually meant for the 5th of November 2013, or is Debian really another year away from "freezing" for their next release?
- 0x0 13y agoNot a typo: http://lists.debian.org/debian-devel/2013/10/msg00234.html http://lists.debian.org/debian-devel/2013/10/msg00234.html
- Scramblejams 13y agoI really, really hope the Jessie freeze is shorter than Wheezy's. That went on so long it became a problem.