Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
Ola Lundqvist wrote:
- the release architecture must have N+1 buildds where N is the number
required to keep up with the volume of uploaded packages
Sane.
- the value of N above must not be > 2
Testing 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.
- the Debian System Administrators (DSA) must be willing to support
debian.org machine(s) of that architecture
I assume people can help with this too, or?
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 mirrors
This 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.
- binary packages must be built from the unmodified Debian source
(required, among other reasons, for license compliance)
This is a bit vauge. Is porting uploads possible?
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
Reply to: