[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
- 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.


Reply to: