

Freeze date and Freeze Policy for Debian Jessie - slashdotaccount
http://lists.debian.org/20131013150131.BBDEB2000C2F8@thykier.net

======
shmerl
What 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
Perhaps 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
_> 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
Sometimes, 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! :).

------
X-Istence

      We 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
Not a typo:

[http://lists.debian.org/debian-
devel/2013/10/msg00234.html](http://lists.debian.org/debian-
devel/2013/10/msg00234.html)

------
Scramblejams
I really, really hope the Jessie freeze is shorter than Wheezy's. That went on
so long it became a problem.

