Differences between revisions 5 and 6
Revision 5 as of 2005-02-02 15:23:20
Size: 2052
Editor: anonymous
Comment:
Revision 6 as of 2009-03-16 03:31:01
Size: 2072
Editor: anonymous
Comment: converted to 1.6 markup
No differences found!

Currently the packages migrate from unstable to testing automaticaly after some testing period if the dependencies are satisfying. The idea of this proposal is to use manual migration from unstable to testing. Even when the package has enough days of testing in unstable and there are no dependency-blocks a manual permision is necessary to migrate to testing.

Who gives this manual permision? Subsystems with tightly connected packages such as GNOME and KDE will have release coordinators that will decide when the subsystem is ready and the packages can go from unstable to testing. For the most important core packages the release manager will decide this. And for packages that have little relationships with the rest of the system their package maintainer will decide.

The subsystems in this proposal exist more informally than in ReleasePerSubsystem. A subsystem in this proposal is simply a group of packages whose maintenance is coordinated by a mailing list such as Apache, Installer, Gtk-GNOME, Qt-KDE, Perl, Python, X, the spell-check packages, etc. The release manager chooses release coordinators for each of these subsystems after a discussion in their mailing lists.

Any attempts should be made to maintain testing always in a releasable state. Debian releases when it is ready unless this event happens too often.

Pros:

  • The release process is similar to what we do now.
  • No big changes in the existing infrastructure are required. We can try how this works immediately after the release of sarge.
  • More people are involved in the release process of Debian
  • Some of the subsystems will be maintained in a less chaotic manner than now because there will be developers responsible for them as a whole.

Cons:

  • Testing will become more outdated than it is usualy now.
  • The quality of testing will raise but how much? Will that be enough to release more often?
  • The maintainers of packages belonging to some subsystem will become less independent in taking their decisions.