Differences between revisions 6 and 15 (spanning 9 versions)
Revision 6 as of 2004-12-27 21:43:12
Size: 1892
Editor: anonymous
Comment:
Revision 15 as of 2009-03-16 03:31:04
Size: 3913
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Pick a subset of Debian that is the core. Release the core only when it's ready, which should be more frequently than when all of Debian is ready. For the other stuff, users would have to [FIXME: do what?] Pick a subset of Debian that is the core. Release the core only when it's ready, which should be more frequently than when all of Debian is ready.
Line 6: Line 6:
 * Shorter release cycles - don't have to wait for Gnome/KDE/insert-big-and-not-essential-package-of-choice-here.  * Shorter release cycles - we don't have to wait for Gnome/KDE/insert-big-and-not-essential-package-of-choice-here.
Line 28: Line 28:

----

This seems to me much like the Openbsd model - They have a core system that should be usable (by some definition of usable, of course) for most (by some definition of most, of course) purposes, and they have the ports. I was quite an enthusiast of OBSD for many years, until I realized that their main selling point -security above all- was completely thrown away when using their ports system.

Debian currently provides far better security support than OBSD. The reason that this model works for Ubuntu is that they have us all to back them. We cannot afford to lose our quality control in this way.

-- Gunnar Wolf

----

I don't see why releasing the core separately from other parts of the system means loss of quality control. My version of this idea involves releasing the core every 2 years or so, and releasing packages tested on that core every 6 months. The non-core releases would not have to be divided up into subsystems, though that is an option. They would simply be a blessed collection of backports, made up of any newer packages that passed quality control testing.

In other words, each non-core release would contain new versions of applications (many backported to current core libraries) so that users don't have to run out of date Apache, Gnome, [[MySQL]], etc. It would be like running stable with backports only the backports would be official and of higher quality.

If Debian was to set a precedent like this, it may cause some developers to base their applications on library versions in the current Debian Core, making the job even easier.

-- Calvin Priest

----
One thing pointed out in LookingAtHistory is that there are key problems that hold us up each time: the installer, toolchain changes, and security infrastructure setup. A two year release cycle on core is simply too long. The whole goal of having a core release is that the cycle would be shorter to reflect changes in ABI/API in the toolchain and hardware support in the debian-installer and kernel.

-- ChadWalstrom

Pick a subset of Debian that is the core. Release the core only when it's ready, which should be more frequently than when all of Debian is ready.

Pros:

  • Shorter release cycles - we don't have to wait for Gnome/KDE/insert-big-and-not-essential-package-of-choice-here.
  • Package pool could theoretically be reduced to a few megabytes.

Cons:

  • Users are on their own with most of the applications, since Debian's archive is de-facto reduced to just another pool with almost no QA (3rd party pools can do the same).
  • Security updates only for core packages, or the need for another security infrastructure (when and where to release security updates for non-core packages?).

Other thoughts: This could be combined with the ReleasePerSubsystem model, core would simply be a subsystem in this model.

This is basically what Ubuntu is doing. Ubuntu's main is a subset of Debian main. In addition, universe exists, which is the rest of Debian main. Universe does not receive security support or fixes. This works fairly well, but probably due to Debian fixing most serious problems in those packages.

See ReleaseProposals for alternatives.


As a user, I'd like to point out that one of the best things about Debian is that 99+% of the software I want is installable from the archive. Because of this, I can rely on it to play well with all the other software on my computer. Contrast the experience on distributions (e.g. Red Hat) where there is far less software in the official archive: one has to resort to 3rd-party package repositories all the time, and packages from those repositories frequently do not play well with each other or even the official packages.

I'd hate to see Debian develop such problems.

-- Zack Weinberg (happily tracking unstable since 1998)


This seems to me much like the Openbsd model - They have a core system that should be usable (by some definition of usable, of course) for most (by some definition of most, of course) purposes, and they have the ports. I was quite an enthusiast of OBSD for many years, until I realized that their main selling point -security above all- was completely thrown away when using their ports system.

Debian currently provides far better security support than OBSD. The reason that this model works for Ubuntu is that they have us all to back them. We cannot afford to lose our quality control in this way.

-- Gunnar Wolf


I don't see why releasing the core separately from other parts of the system means loss of quality control. My version of this idea involves releasing the core every 2 years or so, and releasing packages tested on that core every 6 months. The non-core releases would not have to be divided up into subsystems, though that is an option. They would simply be a blessed collection of backports, made up of any newer packages that passed quality control testing.

In other words, each non-core release would contain new versions of applications (many backported to current core libraries) so that users don't have to run out of date Apache, Gnome, ?MySQL, etc. It would be like running stable with backports only the backports would be official and of higher quality.

If Debian was to set a precedent like this, it may cause some developers to base their applications on library versions in the current Debian Core, making the job even easier.

-- Calvin Priest


One thing pointed out in LookingAtHistory is that there are key problems that hold us up each time: the installer, toolchain changes, and security infrastructure setup. A two year release cycle on core is simply too long. The whole goal of having a core release is that the cycle would be shorter to reflect changes in ABI/API in the toolchain and hardware support in the debian-installer and kernel.

-- ChadWalstrom