Re: The stable/testing/unstable branches not a solution ?
Stephane Bortzmeyer wrote:
On Sun, Jan 18, 2004 at 09:53:16AM -0600,
Joel Konkle-Parker <firstname.lastname@example.org> wrote
a message of 58 lines which said:
I would do it differently. What about the following:
unstable base unstable add-ons
Just a reminder: Debian is not the only free OS. Every proposal for
Debian should be, IMHO, backed by a serious analysis of the free OS
that already implemented this proposal and the issues it raised.
For instance, FreeBSD has a small base and many "add-ons" (called
"ports") and it makes a lot of interesting problems too (such as the
religious and never-ending debate, "Should Perl be in base?").
Well, I guess first, the "problems" with the existing system should be
From a desktop point of view, the main problem is that the current
release schedule is too slow, leaving the stable release filled with
outdated software. Is this intentional, or not? If so, then an
alternative architecture wouldn't do anything.
I'll assume that the problem of outdated desktop software is not
Is it because there are too many packages in Debian itself, so it takes
years to get everything working together to an acceptible degree? The
solution in this case would be to reduce the number of packages that
constitute a release. A "base system" - "add-ons" architecture would
work for this scenario, since the base would include many fewer packages
than the full Debian system now. Another solution to this problem is if
the number of packages was simply reduced altogether, to one or two
"best-of-breed" packages per genre, like the main commercial distros out
there now. Since Debian is renouned for its large package repository,
this latter solution probably wouldn't be the best.
Another possibility is that there are many "mission-critical" packages
out there that should change slowly, so as not to break production
machines out there using Debian. The other, non-mission-critical
packages like Gaim and X-CD-Roast are along for the ride, since
everything must be released at once. Again, this problem can be fixed by
going to a "base system" - "add-ons" approach. The add-ons would consist
of non-mission-critical productivity and misc. apps that are compiled to
support the current stable base system.