Debian Lenny frozen

Hi,

We just edited our hint files, so that all packages now need human
review in order to go to testing. Hmm, that sounds too cryptic. Let's
try again:

  Lenny is now frozen! Wheeeeeee!!!

Thanks are due to everyone who has helped get us to this point.

For those maintainers whose packages were unprepared for a freeze at
this moment (the process has, after all, been a long one), you still
have one last opportunity to get things into shape if there are any
remaining important problems. Read on.


Now to explain what, exactly, we mean by "freeze".  The freeze
upload policy of uploading changes in through unstable if possible will
be continued to apply until the release.

All package versions that are at this moment already in unstable get
an automatic freeze exception (except those that are frozen for
reasons, of course).  This means that packages you've uploaded in the
past week will be able to go to testing (if they aren't hit by
other problems).

Now, so as not to have everyone contact us at once about packages we
know we won't approve, here are the guidelines for changes that will be
accepted into testing during the freeze:

  - fixes for release critical bugs (i.e., bugs of severity critical,
    grave, and serious) in all packages;

  - changes for release goals, if they are not invasive;

  - fixes for severity: important bugs in packages of priority: optional
    or extra, only when this can be done via unstable;

  - translation updates and

  - documentation fixes.

  - pre-approved fixes.

If you have such a change and want to update your package in Lenny, the
rules are as follows:

  - In all cases, when preparing an upload, please do not make changes to
    the package that are not related to fixing the bugs in question.
    Doing so makes it more time consuming for the release team to review
    and approve such requests, delaying the release.  It also delays the
    fix for your package, because you will be asked to reupload. Always
	document every change verbosely in the changelog.

  - If in doubt, first contact debian-release.

  - When contacting the release team, please explain why you are
    requesting an update.  Bug numbers are a must.  Attach the proposed
	(or uploaded patch.  The more we can figure out from your first email
	and your changelog (if any), the more quickly we can get your update
	in.

  - If your package needs to be updated for Lenny, and the version in
    unstable doesn't contain extraneous changes (e.g, the version is the
    same between testing and unstable), please upload your fix to
    unstable and contact debian-release@lists.debian.org.

  - If the version in unstable already includes significant changes not
    related to the bug to be fixed, contact debian-release about
    uploading to testing-proposed-updates.  Changed dependencies, new
    upstream versions, changed library names, and completely rewriting
    the packaging are "significant changes".  So are lots of other
    things.

  - If the version in unstable won't reach testing because of new
    library dependencies, contact debian-release about uploading to
    testing-proposed-updates.

  - If you have a package that needs a freeze exception, *please* don't
    forget to contact us.  *Don't expect us to find out about it on our
	own*.  Putting a comment in the changelog is not contacting the
	release team. :)

  - If your package has been removed recently (i.e. in the last 20 days)
    due to an RC bug, and you have an bugfix-only update uploaded,
    you can contact the release team about letting your package back in.
    Same as above: Do not expect us to find it out ourself. You need to
    push that.


As always, it is the release team's goal to get as much good software
into Lenny as possible.  However, a freeze does not mean that your
package is ensured a spot in the release.  Please continue to stay on
top of release-critical bugs in packages that you maintain; RC bugs in
optional or extra packages that remain unfixed after a week will still
be grounds for removal from testing, just as they have been up to this
point.

Please also note that since many updates (hopefully, the vast majority)
will still be going in through unstable, major changes in unstable right
now can disrupt efforts to get RC bugs fixed.  We don't ask you not to
make changes in unstable, but we do ask that you be aware of the effects
your changes can have -- especially if you maintain a library. Please
continue to keep disruptive changes out of unstable, and continue making
use of experimental where appropriate.  Note once again that you can
stage NEW uploads in experimental to avoid disruption in unstable.

Also, in case you need release team's help to fix RC bugs (e.g. to remove
an old package), please feel free to contact us.

For packages which missed the freeze only for reasons outside of the
control of the maintainers, we might be generous, but you need to contact
us on your own, and you need to contact us soon.


What needs to happen before release
===================================
There is a short list of things that need to happen, though.

Fixing of release critical bugs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For the release, we need to get rid of all release critical bugs. Please
don't hesitate, pick any bug from
http://bts.turmzimmer.net/details.php?bydist=lenny and fix it. Or send in a
patch in case there is none yet. And of course, follow our permanent BSP
policy for your NMUs. Uploading works as you are used to -- just remember to
send an e-mail to debian-release@lists.debian.org to get your fix through.
              

Security support
~~~~~~~~~~~~~~~~
Final preparations for security support will be done during the general
freeze, that is now. We hope being able to announce start of security
support soon, but obviously, it is a pre-condition for release.

Cheers,
Marc

Just a question here, no criticism implied:  What does the freeze mean for packages that have
major upcoming releases (e.g., Python 2.6 and 3.0, OpenOffice.org 3.0)?  Since Debian has a
relatively long release cycle, will it be another couple years before these packages become
full citizens of Debian?

I'm just asking this because it might be on a lot of people's minds.  It may have a simple
answer, but if someone who knows the facts would post them, I would be most grateful.

I'm not much of a Debian user but I believe they'll do what they have done in the past...
maintain multiple repos for various stages... so if you want the stable stuff, you stick with
stable, but if you want newer stuff, there are some additional repos you can use.

You cannot have "constantly changing" and "stable" in one Debian release.

For selective packages there is volatile and backports.org, if you always need newest latest
testing might help you.

Waiting a little bit for a major release isn't a good idea because there are lots of major
releases all the time for lots of different projects.

Each major release is almost always delayed. Each major release isn't going to work perfectly
when it hits the public so will need some maturing time.


For example:
> Does anything seriously depend on OpenOffice.org, for example?

_I_do_. 

Lets assume for a second that I have to deal with a office that depends on OO.org as part of
it's workflow.

This means I have documentation I have to maintain. This means that scripts and macros and
databases and all sorts of little things that I and dozens of other people have built up
around OO.org. Something like MS Office or OO.org isn't just for making spreadsheets or
editing word documents. They are programming environments in their own rights and are used for
all sorts of important office tasks and form the basis for important applications.

This, our personal time and effort, is more important then, say, improved Word compatibility.
If I need word compatibility it's not difficult to have a machine somewhere running Windows
with the latest version of OO.org so that I can test document conversions with MS Office.

As you can imagine delaying a release of a OS in order to shove some new version of OO.org
with a whole new sets of bugs and invalidating at least a portion of the documentation I've
made up as well as macros and other things that people have made is not a attractive concept.

------------------------------


If you want a newer version of OO.org stuck in Lenny it's not a big deal to do yourself.

I don't like apt-pinning because if you do that for something that lots of dependencies it's
easy to pull in a bunch of files from a newer release basically ruining the point of having a
stable release in the first place.

I like things like Backports.org and I like using deb-src and recompiling packages from newer
systems for older systems. 

This way the stability of the entire OS can be maintained by Debian while I can have my little
niggling task-specific 'must have' without disrupting it for everybody else.

--------------------


Of course it would be nice when the average Linux distribution person or programmer realizes
the significant advantages of binary distribution from upstream and put effort into making it
work better.

What I really mean is, they should freeze libraries and other packages that many other
packages depend on much earlier than they freeze packages which are just applications that
almost nothing depends on.

Does anything seriously depend on OpenOffice.org, for example?

Also, if there is some doubt about whether a major new release of some application is stable
enough, could they include both the old and the new versions in the release?

I'm sure these suggestions have been made before, but I'd be grateful for the standard
response.

They do that already, libraries were frozen earlier.

The point of stable release is that all the software have been successfully tested together to
be working in a rather fluent way. That's why it's also risky to provide newer versions of
applications into a released stable release.

Maintaining both old and new version of some software has been done before, like with Octave,
but of course it requires a _lot_ of maintenance. There's eg. hardly enough resources to do
single OpenOffice.org version maintaining/testing at the moment, so it would definitely
require several committed volunteers to even think of eg. OOo 3.0 kind of cases provided as an
alternative version.

http://backports.org/ is there to provide some packages a bit more unofficially, ie. they do
not come with the usual kind of guarantee of quality.

> So, for a time period possibly measured in years, we will have to switch
> wholesale to the unstable repository to have "newer stuff" that, at that 
> point, will be just about as old as the stable release itself?

Not necessarily. You can use a feature of APT called pinning to let one package install from a
different repository from your other packages.  Here is a page that explains how it's done:
http://wiki.debian.org/AptPinning

Using this technique, you could pin OpenOffice 3.0 from the testing or unstable repositories
while still running Debian stable for the rest of your system.

What I often do is backport myself.  Add a deb-src line from testing or unstable to the stable

machine then do

apt-get build-dep package-foo
(any libraries or other tools complained about in this step need to be backported as well.
This 
process can get a bit recursive.  If it turns out I'm going to be building 4 or 5 support
libraries or 
worse then I won't bother.)

mkdir package-foo
cd package-foo
apt-get source package-foo
cd package-foo-<version #>
dpkg -rfakeroot -b
dpkg -i ../package-foo-<ver#).deb

may i also recommend pbuilder which makes backporting easier by providing an easy-to-manage
pristine chroot environment for building packages.

using pbuilder on my testing/"lenny" desktop, i backport applications for servers running
stable/"etch" and even desktops running ubuntu hardy/8.04.

i also use apt-proxy for caching packages for both pbuilder and other machines, but it's not
that specific to backporting or pbuilder.

Shouldn't building LSB compliant packages eliminate the need for pulling in other
dependencies?

Well, if OO.o made debs available that were LSb compliant, then they would work on any LSB
compliant distro. Then there wouldn't be a need for each distro to create backports, or to
even have to package the software for their particular distribution.  The OO.o repository
could be added to the sources list and updated directly from the ISV.  This means you could
have whatever version you wanted on your system with little effort.

Yes, this Debian release is not going to be significantly different from any  past Debian
release in that regard. In fact, the point of having a stable release is that the various
packages have been tested together to a significant extent. If new version of a bunch of major
packages came out shortly before a stable release, it would violate the purpose of the release
to include them.

Etch was 22 months after sarge. The target for Lenny is September, only 17 months after Etch.
I *think* the release folks are aiming for 18 month releases in future.

Yes, it will take a year or two until the packages are shipped in a Debian stable release,
since we usually do not change a stable release except for fixing security issues and release
critical bugs (or now even new hardware support, as in 3.0r4). Of course they will be
available a lot sooner than that in testing and unstable.

Looking at the Bug chart, it would appear that there are more bugs in the stable release then
currently in testing!

Number of bugs reported so far != number of bugs in software

Software that's been in wide use will have been eyeballed more, and will have had more bugs
filed as a result, in most cases.

and hopefully the bugs will stay open and not be closed when the bug is fixed in unstable.

before debian allowed/implemented adding release-specific tags ("sarge", "etch", etc) to a bug
report in the bug tracking system (bts), it really frustrated me to debug a newly installed
package for an hour or two only to find that the bug was known and previously filed against,
but was closed once the fix was introduced in an upload to unstable, removing all visibility
that the bug existed in stable.

maintainers didn't like open bugs because it made it appear as if they weren't maintaining
their packages, so they would close them and refuse to leave them open while the bug existed
in stable.  but now with release-specific tagging, i haven't met a maintainer that required
that all fixed bugs be closed (regardless of the release).

This is how version tracking works. The bug *is* fixed. I am not sure how, but in principle
you can now more easily determine which bugs still apply to Testing than previously, where you
manually had to add the "sarge" and friends tags (and, btw., they previously also changed
their meaning).