[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Idea: Debian Release Sections

Paul J Thompson <thomppj@okstate.edu> writes:

> Debian-Net: Debian packages involving networking. This does not include
> basic networking packages, as they would fall into one of the core
> sections. However, this would include web servers, ftp servers, etc.
>   Release Freq: 3-6 months
>   Example Packages: apache, wu-ftpd

Ok, I'll bite here. As I understand it, the release cycle of these
mini-dists[1] will happen basically as the whole distro is
handled now. So a frozen Debian-Net will not be declared stable until
the RC bug count is low enough, there are no glaring security holes

But I frankly don't see why the stabilization of apache should be
postponed because wu-ftpd needs more work before it is released. Why
do they have to wait on each other, but not on emacs (I assume emacs
is not in Debian-Core*)? Granted, there are a number of public-access
servers running both wu-ftpd and apache alongside. But there are
probably even more production-level servers having no wu-ftpd, but
both emacs and apache.

These mini-dists also make testing not really easier. You still have
to test for a relase-candidate Debian-Net whether it operates
correctly with ALL other stable-at-the-time mini-dists - not only if
it cooperates with the Core stuff! You'd even have to do this for the
foundation blocks, or else a new "stable" Debian-CoreNet could easily
break an older, stable Debian-Net.

> Whenever a new release of a core distribution was made, other
> sections could then start developing against that release.

What could be done is that one is only allowed to run Debian-Net 3.25
with a limited set of other mini-dist versions (those that have been
tested), perhaps only one version for each mini-dist. But imagine what
would happen on a server that wants to run stable versions of
Debian-Core, Debian-Net, and Debian-Devel. Suppose that the
meta-information says:

Mini-Dist: Debian-Core
Version: 3.4
Released: 2001-10-15
Depends: (nothing)
Tested-With: Debian-Net 3.14, 3.15; Debian-Devel 3.8, 3.9, 3.10

Mini-Dist: Debian-Net
Version: 3.16
Released: 2001-11-20
Depends: Debian-Core (>= 3.4)
Tested-With: Debian-Core 3.4; Debian-Devel 3.10

Mini-Dist: Debian-Devel
Version: 3.11
Released: 2001-12-22
Depends: Debian-Core (>= 3.5)
Tested-With: Debian-Core 3.5; Debian-Net 3.16

To not exeed the tested specifications you'd have to run -Core
3.4 (for -Net) and -Core 3.5 (for -Devel) at the same time. Too bad,
you can't use -Devel 3.11 until -Net is updated to a version tested
with -Core 3.5.

Also note that the Core developers did even more work than is done
today by testing their mini-dist against two to three versions of each

In summary, I think this is just more complication for a very limited
gain. Let's see how the infamous package pools or ajt's "testing"
fares. I think with foundations in place, it will be easy for groups
(comprised of developers or even independent of Debian) to take a
snapshot of package versions, test and tweak this snapshot until
satisfaction, and release it on their own terms. Different groups
could focus on different goals ("stability over everything",
"security", "the newest of everything, as long as it does segfault
less than 5 times a minute", etc.)

[1]  I will use that instead of "sections" for now, since it offers
     less confusion than the already used term.


Attachment: signature.ng
Description: PGP signature

Reply to: