Differences between revisions 12 and 13
Revision 12 as of 2007-04-26 13:49:03
Size: 3266
Editor: SimonHuggins
Comment: Add Martin's video
Revision 13 as of 2009-03-16 03:32:13
Size: 3268
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
See [http://video.google.com/videoplay?docid=-5503858974016723264 Martin Michlmayr's Release Management in Large Free Software Projects] for some good analysis of this approach in Debian and other free software projects. See [[http://video.google.com/videoplay?docid=-5503858974016723264|Martin Michlmayr's Release Management in Large Free Software Projects]] for some good analysis of this approach in Debian and other free software projects.
Line 36: Line 36:
A full release is a very large undertaking, and I think has different goals. I think releases should attempt to provide particular "large" functionality achievements that involve architectural change (e.g. implementing a new installer, or a ["SELinux"] environment), and because of the complexity, ReleaseWhenReady is appropriate. But I think making '''updates''' on a fixed schedule could work, and solve many of the niggly problems people have. We have the basic process in place already, it just needs a bit more structure (and more helpers) so that it happens regularly. A full release is a very large undertaking, and I think has different goals. I think releases should attempt to provide particular "large" functionality achievements that involve architectural change (e.g. implementing a new installer, or a [[SELinux]] environment), and because of the complexity, ReleaseWhenReady is appropriate. But I think making '''updates''' on a fixed schedule could work, and solve many of the niggly problems people have. We have the basic process in place already, it just needs a bit more structure (and more helpers) so that it happens regularly.

Do as GNOME does:

1. Set a release date

2. On that date, release

See Martin Michlmayr's Release Management in Large Free Software Projects for some good analysis of this approach in Debian and other free software projects.

(Differs from DropProblemPackages in that packages which do not meet QA goals are released anyway.)

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 have considered Release Critical before.
  • Developers tend to pile in changes right before release, introducing instabilities at just the wrong moment.

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 these 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
  • As a user who has been running testing ever since it was created, I can attest that there are some horrid packages in woody -- especially some of the gui packages like gaim. Also seeing a few pages on compiling from source on a debian stable system to work around bugs in pam-ldap just looks bad. -- MikeFedyk

A full release is a very large undertaking, and I think has different goals. I think releases should attempt to provide particular "large" functionality achievements that involve architectural change (e.g. implementing a new installer, or a SELinux environment), and because of the complexity, ReleaseWhenReady is appropriate. But I think making updates on a fixed schedule could work, and solve many of the niggly problems people have. We have the basic process in place already, it just needs a bit more structure (and more helpers) so that it happens regularly.

See ReleaseProposals for alternatives.