Re: Canonical and Debian
On Mon, Jun 06, 2005 at 07:22:08PM +0200, Peter 'p2' De Schrijver wrote:
> > * Split the architectures over two sets of mirror networks, so that
> > mirror administrators don't need 100G just to mirror Debian anymore.
>
> That sounds retarded in an age where a 200GB HD cost less then 100 Euro...
> Anyway you can always decide to mirror only part of the archive if you
> want to, even today.
Oh, come on! That's not a serious argument, is it?
First, to run a reliable mirror, one hard disk isn't going to get you
there -- you need several in some sort of a RAID setup.
Second, I have yet to see the first mirror that mirrors Debian
exclusively. Most mirror Debian and some other sites.
Third, the 100G isn't a constant number. It will most likely jump up
high in a few weeks, as we split a new testing off of unstable and leave
woody to become oldstable.
Fourth, adding the architectures that are waiting around the corner
(amd64, kFreeBSD, ...) will the disk space requirements even more.
Fifth, many of our mirror admins want this -- the proof is easy, just
look at the number of mirrors that does already drop a few from the list
of mirrorred architectures even today. That even includes at least one
primary mirror.
> Downloading 5GiB takes about 1 and 12 minutes on a 2Mbit/s link...
> 2Mbit/s is hardly state of the art in IP networks... (state of the art
> is more like 40GBit/s). And you can still mirror only part of the
> archive if you want to save bandwidth, even today.
Indeed, and some of our mirrors are already doing so. It would, thus, be
interesting if we could formalize that somehow, which is what the first
bit of the proposal is all about.
> > * Create a set of rules that an architecture has to abide by in order to
> > be allowed to release. This set of rules would be there to make sure
> > that a port's porters, rather than the set of release managers, ftp
> > masters and the like, do all the work in making the port work.
> > Provided that set of rules is sensible (which I'm not entirely sure of
> > right now, but that can be fixed), there's nothing wrong with such a
> > suggestion.
> >
>
> The current list doesn't make much sense at all.
Some elements in the current list don't, indeed. Some do.
> Some points just don't make any sense (like limiting the number of
> buildds, or just outright refusing the arch for no reason,...)
Those are indeed two elements that I personally would like to see
removed. But the idea of requiring that an architecture fulfills some
basic quality criteria isn't too silly.
> > While it is indeed very likely that only amd64, i386, and (perhaps)
> > powerpc fall in the first thread, the same is very much not true for the
> > second set.
>
> The second set is also not debian. It's not based on the same source
> packages, it has different release cycles, it has a different testing
> repository and we will have 6 or more of those variants
> (mips,sparc,alpha,hppa,m68k,arm) all called 'etch'.
>
> So effectively this proposal kills 82% of debian, causes more work and
> more confusion.
There are certainly some bugs in the current proposal; I'm not contesting
that. However, they're not unfixable.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: