ReleaseProposals - Debian Wiki

The goal of this suite of pages is to gather the collective wisdom of Debian developers on new release methodologies for Debian, with an aim toward reversing the current trend of it taking longer and longer for us to make a release.

This set of pages is being developed because while plenty of people have made various suggestions on debian-devel, this has only resulted in threads with hundreds of messages, with debate being more rational in some places than others.

Feel free to add new pages, or add new arguments pro or con to a page, but do respect the opinions of others and bear in mind that the idea is to arrive at a set of well specified proposals for how Debian can release, and not to promote your idea over all others. If your opinion does not represent the consensus of a pro or con for a release method, add it as a comment with your name on it.

Current:

ReleaseWhenReady

Do what we were doing:

UnstableFreezeUntilStable

Proposals for releasing less:

Proposals for splitting up the release:

Proposals multiple release teams:

Proposals to do more of what we have been doing:

AddAnotherRepositoryBetweenUnstableAndTesting
["MakeItMoreLikelyToFindRCBugsInUnstable"]
RunDinstallHourly
DropProblemPackages
LookingAtHistory

Proposals to increase maintenance of packages:

Proposals for making additional kinds of releases of the full archive:

?DebianInstallerReleasesAreDebianReleases
TwoReleases
PartialReleasesFullRelease
["ReleaseCDDs"]
["PermitFixingRCBugsInStableAndReleaseReallyStableAfterSometime"]
FormaliseBackports
FixedReleaseDate
PackageRefinement

Besides a new release process, it is also very interesting to figure out why the current process scales so badly. What are the obstacles?

TranslationTeamsOverloaded
?InstallerNotReady
Debian Government:
Developers:
- DevelopersTooLame
- DevelopersIgnorant
Package Migration:
Keep more broken packages out of unstable
- ExperimentalHardToUse
- ToolChainOrLibrariesFrequentlyBroken

This is an evolving document -- refer to RecentChanges to find newly updated pages.

And while we are at it here is a list of solutions what to do with the ideas and proposals above:

?JustIgnoreAndContinueAsAlways
["LetTheDPLDecide"]
["MakeGR"]

I would like to also propose a goal based release: To have an actual goal for that round of Debian development. This current release, for the end user, appears to be a software update. Not a very big change in policy. It might be worthwhile to set goals for what people would like to see changed, or advanced, then decide on a good time frame so everyone is on the same page, working toward the same goal, and knowing where they stand. This appears to work pretty well for kde.

- Christain (Debian user)

We should also be looking heavily at how a release (or lack thereof) affects Debian users. After all, the purpose of Debian is not to release - it's to meet the needs of its users, and releases are just one way of doing that. Personally, I understand the logic and reasoning behind the long release intervals, and not releasing until it's ready, and I really appreciate the stability of Debian which is the result of some hard work by its developers. I don't really want to sacrifice or compromise that stability in any way. By the same token, I occasionally have the need for a package or set of packages that is updated beyond what is available in stable. This leaves me with the option of manually downloading/compiling/installing and somewhat messing with the beauty of the Debian package system in the process, or simply upgrading to and running unstable/testing/whatever. I've always maintained that Debian's unstable is just as stable as everyone else's stable, so when I make the choice to go with something other than stable, I realize there may be some slight problems I'll need to work around, but my main concern is the lack of security patches. With everything I do, I just don't have enough time to stay on top of every single package out there I happen to need on a particular install - that's where I really depend on the Debian security team. What would help me as a Debian user is if we could use the above proposals to speed up the release process where we can without cutting corners on the quality of releases while at the same time finding a way in part or in whole to offer some security support for future versions (unstable, testing, etc.) so that those of us who do decide to make the move away from stable on a particular install aren't completely left out in the cold (from a security perspective).

-- Gene (Debian User)

Just to add my 0.02ukp here, I personally use (and partially administer) a cluster of machines running Debian in a university research group. While I think that using testing as an everyday distribution is fine for personal machines, in this context having a rapidly changing distribution isn't an option - users are more interested in getting work done rather than playing with cutting edge versions of the software, and generally object to large chunks of the system changing on a day to day basis, and it generates administrative hastle. Having said this, the current model is too slow (for example, the stable GSL packages are missing a lot of functionality that I need, and the X11 server doesn't support the graphics hardware on newer machines). I personally very much dislike the monolithic approach to managing the distribution - I find it hard to see why Joe's random applet should be considered a core part of the operating system, so I'd prefer to see a more distributed release process (i.e. the per subsystem release proposal). Sure, there are technical issues, but they can be overcome, and I would hope it would lead to a release schedule that could release a 'core' every year and more application based subsystems (e.g. GNOME) maybe every six months or so.

-- Phil (Debian user and sysadmin)

There are lots of misconceptions about why the Debian releases are delayed and lots of proposals attempt to fix non-existent problems. This cause lots of flamewars on non-issues. A monthly evaluation of our position toward the release all along the release cycle could help. That could give us a better anticipation and maybe help us release sooner. For example, I participated in a BSP in July 2003 on the assumption sarge would be out in 2003. Had I better anticipated, I would have learnt about debian-installer design instead to be able to help the d-i team in February 2004.