Sane.- the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages- the value of N above must not be > 2Testing related. I do not really understand why this is a problem but somebody may be able to tell.
Uh, no, it's not testing related at all. By the time packages are considered for testing, it's completely irrelevant how or where they were built.
The reason for the N = {1,2} requirement is so that the buildds can be maintained by Debian, which means that they can be promptly fixed for system-wide problems, and which means access to them can be controlled, rather than opening up users of that architecture to exploits should a random disgruntled non-developer have access to the machine and decide to abuse it, eg.
I assume people can help with this too, or?- the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture
Doing DSA work involves more than having root on a random box on the internet. It's a specific task, not something that every developer is already doing under a different title.
We project that applying these rules for etch will reduce the set of candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 and amd64 -- which will be added after sarge's release when mirror space is freed up by moving the other architectures to scc.debian.org).I'm missing sparc here, but that is only me... But even if that one is included the drop will probably help some.
Personally, I'd like to see sparc, alpha and/or potentially arm and s390 stick around as release architectures too; mostly that would require them to be actively maintaining their architecture and trying to compete with i386 for being better supported, which isn't something I've seen happen for years now. Which is disappointing, because sparc at least was beating the pants off everyone else (though still behind i386) a while ago.
I haven't seen much evidence of hppa, mips, mipsel or m68k coming anywhere near balancing the cost/benefit tradeoff for sticking around in the release; but there are listed criteria now, if they're the architectures are that valuable, I don't see any reasons for porters to be complaining instead of demonstrating they can meet or surpass all of them, or mitigate any concerns anyone might have for the others.
- there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrorsThis as stated before, probably a too tight limit. I think 10% of the downloads if i386 is excluded is a better metric. :)
10% of downloads if i386 is excluded is about 0.5% of downloads. So, uh, no. powerpc's pretty consistently around 2%, ia64 and others are at 1% or below.
This is a bit vauge. Is porting uploads possible?- binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance)
I don't understand why people are confused on this. If you want to upload a binary to the archive, you upload the source you used to build it as well. If you needed to modify the upstream source, your patch is included in the .diff.gz. If the package was already in the archive, you mail the patch to the maintainer, and if it's urgent, do an NMU.
It's not anything subtle.
With these comments I will happily second this proposal.
IMO, intelligent comments are far more useful than seconds.
Cheers, aj
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
