Debian is big. First categorize packages out to subsystems. A subsystem should contain packages more or less related. There should be only few inter-dependencies between subsystems. For example there could be like:

• Base (GNU)
• X11
• GNOME
• KDE
• webserver
• ...

The subsystems should be released independently, based on good QA practices (e.g ReleaseWhenReady DropProblemPackages).

Pros:

• A somewhat more distributed development style
• With smaller chunks of packages the release cycle can be shorter
• No need to lower quality standards
• Subsystems higher in the food chain can base themselves on stable dependencies.
• A problem package ruins only one subsystem, not the whole release schedule (Remember problems related to basic GNOME and KDE packages)
• Users might be able to choose when they upgrade a particular subsystem
• This release model is closer to the reality of release cycles for programs shipped in Debian (GNOME releases, KDE releases, ...)

Cons:

• A somewhat more distributed development style
• Choosing subsystems with minimal interdependencies might not be easy
• The subsystems would work well with things like GNOME or KDE, but would be a pain for the random packages that Debian ships
• The difficulties of classification in sections has already been seen in the past

Other thoughts: A subsystem could declare which stable version of other subsystems it is based on. If there are one or two problem packages in the underlying subsystem (e.g. newer version is needed), it could be reissued.

Major changes to the build system would be needed. Would the GNOME subsystem be compiled against the latest stable Base subsystem, the development Base subsystem or both? What about packages needed by both KDE and GNOME - do they have to go in Base? Or a new Desktop-Base? This could lead to far too many subsystems. When GNOME needs the latest version of this shared package, but KDE isn't ready for it, what happens? Do we maintain two versions of it?

This could be combined with the ReleaseOnlyCore model, core would simply be a subsystem in this model.

See ReleaseProposals for alternatives.

This is the development model that ?ProgenyLinux is experimenting with.

"Would the GNOME subsystem be compiled against the latest stable Base subsystem, the development Base subsystem or both? What about packages needed by both KDE and GNOME - do they have to go in Base? Or a new Desktop-Base? This could lead to far too many subsystems."

Packages needed by GNOME or KDE (ie, X11, QT, GTK): Tough decisions here. Here is my proposal on a hierarchy of the subsystems (just IMO):

• Debian BASE (BASE distribution packages)
  • Debian Services (SYSTEM: for web,SQL,server scripting,FTP,Samba,etc packages)
  • Debian Misc (SYSTEM: umbrella container for new and un-categorized packages)
  • Debian Desktop (SYSTEM: for X11,3D, and graphics libs: QT,GTK, TK, Motif,CUPS printing, etc packages)

    • KDE (SUBSYSTEM: Container for all KDE&Apps + KDE frontend packages)

    • GNOME(SUBSYSTEM: Container for all: GNOME&Apps + GNOME frontend packages)

    • MISC(SUBSYSTEM: other desktop packages and frontend packages)

My opinion: Stable SYSTEMS (Services, Desktop, Misc) should be compiled against the latest stable BASE. When the development BASE is frozen, then start thinking about releasing other systemsagainst it. But don't bother compiling systems against a non-frozen unstable BASE. Once the unstable base eventually is frozen, then stabalized, then released,send the old BASE + systems into maintenance mode.

Repositories:

• Unstable:
  • Unstable BASE
  • DESKTOP (compiled against stable BASE)
  • SERVICES(compiled against stable BASE)
  • MISC (Compiled against stable BASE)
• Testing:
  • Testing BASE
  • DESKTOP (compiled against stable BASE)
  • SERVICES(compiled against stable BASE)
  • MISC (Compiled against stable BASE)
• Stable:
  • Stable BASE
  • DESKTOP (compiled against stable BASE)
  • SERVICES(compiled against stable BASE)
  • MISC (Compiled against stable BASE)

Eventual freezing of unstable/testing BASE:

• COPY Stable DESKTOP repository to newly created Unstable DESKTOP (against the new BASE)
• COPY Stable SERVICES repository to newly created Unstable SERVICES(against the new BASE)
• COPY Stable MISC repository to newly created Unstable MISC (against the new BASE)
• Work on the above systems until ready to be released as stable against new base (basically directly porting them over to the new base)
• Put stable repositories under previous stable BASE into maintenance mode.
• Release this new BASE when it is done being frozen, with a reasonable subset of each system at v4.0 ready. Most likely the SYSTEMS for this new base will just be direct ported copies of the previous stable SYSTEMS.

• Don't worry if you don't release the BASE with EVERYTHING complete from each system. You have a long time to come out with newer versions of each system. Concentrate on making BASE as good as it can be and with a reasonable subset of stable packages released for each system.

Releasing:

• Each time a new BASE is released, bump up the debian major version number (ex: 4.0)
• Each time a new SYSTEM is released, bump the debian minor version number (EX: 4.1)
• Each time a new SUBSYSTEM is released, bump the parents minor version number (EX: 4.0.1)
• When a new BASE is released, it would be released with all the curent stable SYSTEMS and SUBSYSTEMS it has been "stabalized" with.
• Likewise for SYSTEMS
• Needs further discussion

Known problems but are likely to be easilly solved (needs discussion):

• what if a KDE frontend for apache breaks when apache is upgraded
• what if KDE is upgraded and apache is not yet and the frontend changes and drops backward compatability for older apaches?
• what if ..?

User's perspective:

• BASE is much smaller, thus shorter release cycle more dependant on external community factors (such as new kernel,new installer, new package manager, new LSB specs, etc.) rather than itchyness (because it took 2 years to get here and its still not ready and your losing all your support)
• SYSTEMS are much smaller, thus shorter release cycles. Release cycles based on major changes to core libraries and support packages which are needed for individual applications (GTK, QT, X11, etc)
• SUBSYSTEMS are much smaller, thus shorter release cycles (as often as new applications have major changes such as KDE 3.2,3.3,3.4)
• If a new KDE/GNOME comes out and the current state of Debian is v4.3, the user will upgrade to 4.3.1
• if a new QT+KDE major update comes out and the current state of Debian is v4.3, the Desktop SYSTEM will need updating along with KDE so the user will upgrade to 4.4
• if a new Linux kernel comes out or a new compiler to port apps to is required and the current state of Debian is 4.4, then the user must upgrade the BASE and would upgrade to v5.0

Some thoughts:

• If it is popular to not have sub-systems (KDE/GNOME/MISC) split apart from DESKTOP then you could just combine it all into a system and not split it up.

• or if this idea is popular then you could consider doing the same sub-system splitup for the SERVICES system (Apache, PHP, ?MySQL,etc) Though there is so much in there it may or may not be practicle

• The nice thing about this idea is that you potentially could recursively go as deep as you wanted in sub-systems and it would all be treated about the same and would keep their parents organization automatically. So you can go as deep as needed to properly maintain subsystems without a lot of difficulty.
• Another nice thing is that you could just stick with "2 deep" approach and have BASE and then the SYSTEMS and no subsystems. Even that simple split up would dramatically improve release cycles and Debian popularity.
• A nice benefit to all of this is that it would be significantly easier for 3rd party distributers to track Debian (such as ubuntu) and so 3rd party support would be closer to the standard Debian and wolud not diverge so far as to break compatibility.

More thoughts:

• Ian Murdock blogged some extensive roadmap and questioning about pros and cons to be solved regarding this approach. http://ianmurdock.com/archives/000252.html . He calls it componetized linux (http://componentizedlinux.org/ )More. Very interesting reading for evaluting this proposition.

• For managing release of large amounts of packages, and Sarge now is around 14000, and complex systems, this could be the way to go. Divide and conquer.