Do like Gnome does: Set a release date and release what we have on that date.
Pros:
- We get to pick the ideal time period between releases.
- All the developers can get behind the release and plan for the date.
Cons:
- This necessarily entails releasing with known bugs that we would consider release critical before.
- Developers tend to pile in changes right before release. This can cause problems.
Opinions:
I consider ?DebianInstallerReleasesAreDebianReleases to be a varient of this that may work better in Debian than the above-described "strong" version. -- JoeyHess
- As a user (rather than debian devel.) I would point out that bugs are only really a problem if you don't know about them. If the "serious" bugs that are going to be associated with a fixed release date are well documented, then I can decide whether or not I'm going to upgrade to the new release. If I don't then I can wait for the next release which I know will occur on a particular date and hope they are fixed by then. -- StewartJ
We can alleviate Con #1 by freezing early then ReleaseWhenReady. As for how early, I would say when the goals for the next stable has been achieved (Debian releases has goals right? no?). As for con #2, the best way is to ask the developers not to do it. It takes awhile to adopt a new policy, but hopefully and eventually, everyone will get used to it. --JanAlonzo
- This could work if we allowed for this bugs to be fixed in an already released stable release, as we do now for security fixes. More work, yes, but a plausible model. Also, the people in charge of maintaining the stable release would not have the pressure to roll out point releases, as the release cycle would be much shorter, so they would be able to spend more time working on this. This proposal does, of course, lower Debian's overall QA - But probably to an acceptable level. -- Gunnar Wolf
See ReleaseProposals for alternatives.