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.
The list of release proposals:
?DebianInstallerReleasesAreDebianReleases
- ["NMUMore"]
- ["PermitFixingRCBugsInStableAndReleaseReallyStableAfterSometime"]
- ["ReleaseCDDs"]
Besides a new release process, it is also very interesting to figure out why the current process scales so badly. Where are the bottlenecks and what can we do about them?
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)