> > Then how did these people end up choosing to support the same set of > > architectures as Ubuntu? > > I know I've been screaming murder and hell about this, but in hindsight, > after having read the proposers' explanations (and the proposal itself > for a few more times), this certainly is not what they're proposing. > It's just a 'coincidence...' > The whole thing is confusing, because the one nybbles mail talks about > multiple things, and it's easy to mix those up. But in reality, the > nybbles proposal suggests that we do the following: > > * 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. > This has nothing to do with what architectures can release a "stable" > and what architectures cannot; only with mirror bandwidth and disk > space usage. The popularity of an architecture will be a deciding > factor in the decision of what archive mirror network will be used, > but there's of course nothing wrong with that; architectures would be > allowed to create a stable release on that "second-class" mirror > network, and that's what counts. 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. > * 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 points just don't make any sense (like limiting the number of buildds, or just outright refusing the arch for no reason,...) > 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. Happy hacking, Peter (p2).
Description: Digital signature