Rant (was Re: Distribution)
Bill Mitchell writes ("Re: Distribution"):
> Wait a sec. I think we have a definition or a perception problem here.
>
> What is debian 0.93R6?
> 1. Just the install disk set?
> 2. The install disk set plus a frozen set of base packages?
> 3. The install disk set plus a frozen complete distribution?
>
> I think it's #1, or maybe (I don't think so) #2, but not #3.
It doesn't have to be any of those. I keep banging away at this. Our
choices are not `complete chaos and instant update of everything'
vs. `completely frozen distribution'.
How about `Debian 0.93R6 is the current stable distribution, including
the disks, and also including any later bugfixes'.
> "bugfixes and urgent releases only" (?!?!?!?!?!)
> Where's the value of incremental upgradeability in this?
>
> If a spiffy new upstream release of some package comes down the pipe,
> and is packaged up by the maintainer, it should be made available to
> debian users now, IMHO, not six months or so from now.
If that's what you want you ought to be using the `development' tree.
That will have the latest spiffy version of everything. It'll have
more bugs, of course, and change much more rapidly.
The value of incremental upgradeability is that we can support
everyone - we can support *all of*:
- people who want to install once and then do a quarterly or
half-yearly download of an `updates' directory.
- people who get a CD-ROM every quarter or so.
- people with good connectivity who want to be on the bleeding
edge.
- people with good connectivity who want to be using a nice stable
release and upgrade it in one major shift every few months
- people who want the latest stable and well-working version of
everything.
- people who want a mixture of any of the above.
My proposal supports this better than any of the other proposals I've
seen. It certainly supports it better than any proposal involving
frozen snapshots.
> On reflection, if my opinion about just what is debian 0.93 is correct,
> the current directory structure with its implication that the package set
> on the ftp site belongs with the version-numbered release is unfortunate.
> Something like this:
>
> debian-0.93/binary/
> INDEX
> README
> docs/
> disks/
> Packages->../a.out-packages (or perhaps not)
>
> a.out-packages/
> INDEX
> README
> source/
> binary/
> ms-dos/
>
> might have been better. However, it looks like such changes cause more
> trouble on the mirrors than it is reasonable to put them through.
We need both a stable and a development tree. It doesn't make sense
to name these after a.out vs. ELF, because at some point we'll have an
all-ELF stable tree.
Martin Schulze writes ("Re: Distribution"):
> Hallo Ian Jackson!
> }So, what we're left with, if you agree with my release strategy, is:
> }
> } released -> debian-0.93
> } debian-0.93/binary [ bugfixes and urgent releases only ]
> } source
> } ms-dos
> } Packages -> binary/Packages
> } disks
>
> So bugfixes et cetera still go into a released release (eh published
> release). So we run into the great slackware problem that there are
> tons of version 2.2 (as an example).
>
> I don't agree to that.
I think you have a problem with language here. "I don't agree to
that" implies in English that you are the person making the decision
and have decided to veto what I was proposing.
This list has not always been noted for its even temper (see also
debian-private recently), and I'm currently having great difficulty
preventing my blood boiling over.
I feel *very* strongly that we *must not* have a frozen-in-stone
release. There are little or no benefits and a lot of disbenefits.
The fact that not everybody's 0.93R6 is the same doesn't matter: after
all, after people have configured their systems no two systems are
alike.
> [...]
> Then it's a static Debian GNU/Linux 0.93R6 for say half a year. Only
> some updates will go into the updates directory. Users who download
> 0.93R6 once won't have to check for everything if they want to have a
> problemless release. They can look at the updates dir.
My proposal provides an updates directory that can be used in exactly
this way. There is NO NEED to freeze the released distribution's main
tree just to provide incremental update directories too.
> And cdrom
> vendors don't have the problem that their just pressed cd is outdated
> just by publishing it.
Sod them ! I'm sorry, but why on earth should we freeze our release
on the FTP site when we don't have to, just because then we'd be
providing a better product than the CD-ROM vendors ? The fact is that
for many people an FTP'able or NFS'able distribution *is* better than
a CD-ROM, in part *because* it is more easily updated for those
people.
Ian.
Reply to: