Re: Results of the meeting in Helsinki about the Vancouver proposal
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
> 1. The requirement that 'an architecture must be publically available to
> buy new'.
>
> It was explained that this requirement was not made to be applied
> retroactively to already existing ports; rather, it was designed to
> avoid new hardware which, as of yet, is only available under NDA, or
> to avoid things such as a Vax port of Debian. Older ports, such as
> m68k and arm, are expected to reach a natural end-of-life to a point
> where it no longer is possible for Debian and the port's porters to
> support it, at which point the port would then, of course, be
> dropped.
Where's the definition of "natural end of life"? Who defines when this state
is reached? The porters (how many of them then?)? What is meant with "no
longer possible ... to support it"?
> 2. The requirement that any architecture needs to be able to keep up
> with unstable by using only two buildd machines.
>
> The rationale for this requirement was that there is a nontrivial
> cost to each buildd, which increases super-linearly; apparently,
> there have been cases in the past where this resulted in ports with
> many autobuilders slacking when updates were necessary (such as with
> the recent security autobuilder problems).
According to Joeys blog (http://www.infodrom.org/~joey/log/?200508201755):
"I also have the impression that there is no buildd for m68k and s390 for
sarge-proposed updates - or there's another reason the updated vim is not
available on these architectures."
There still seems to be an incomplete buildd infrastructure. Why is that and
why is that not communicated properly? All I see is a vaque assumption that
the infrastructure is in place or it isn't, but nobody seems to know that
for sure. And even more there seems to be a security team and infrastructure
for stable and testing and both seem to have nothing to do with eachother,
i.e. are the machines for both are identical or what?
> On the flip side, it was argued that more autobuilders results in
> more redundancy; with a little overcapacity, there is a gain here
> over an architecture which has just one autobuilder, where then that
> single autobuilder goes down.
I don't see the problem with having as much autobuilders as the porters can
handle? ("can handle" = handle the buildd logs, keep them running, supply
them with hardware, etc.)
> This item was much debated, and we didn't reach an agreement; in the
> end, we decided to move on. We hope that after more debate, we will
> reach a solution that is acceptable to everyone, but in the mean
> time, the requirement remains (but see below).
Well, it seems nice to debate the need of autobuilder redundancy, but how
about buildd admin redundancy? There has been problems with that for several
archs in the past. How should this been addressed?
> 3. The veto powers given to the DSA team, the Security team, and the
> Release team, on a release of any given port.
>
> Some of us feared for abuse of this veto power. All understood the
> problems that exist if any port is of such low quality that it would
> suck up the time of any of the three given teams; however, we felt
> that a nonspecific veto power as proposed would be too far-reaching.
>
> At first, a counter-proposal was made which would require the three
> teams to discuss a pending removal of a port together with the
> porters team, and require them to come to an agreement. This was
> dismissed, since a) this would move the problems to somewhere else,
> rather than fix them (by refusing to drop a port, a porters team
> could essentially kill the security team), and b) the three
> beforementioned teams could already refuse to support a port anyhow,
> simply by not doing the work.
In that case, when there might be a package with an unsolvable security
issue for a port (perhaps because it needs a newer gcc or toolchain, because
the released one has an issue like ICE or so), that package could be dropped
from the release for that arch. Why dropping the whole arch then?
> In that light, we agreed on a procedure for dropping a port which is
> designed to avoid abuse, by making it as open as possible: if any of
> the aforementioned teams wants to use their veto power, they have to
> post a full rationale to the debian-devel-announce mailinglist, with
> an explanation of the problems and reasons for their decision.
I would like to see a detailed rationale under what circumstances such as
veto might be raised *beforehand* anyone can veto something. It should be
clear what requirements must be fulfilled so that a team can veto something.
Otherwise you'll end always with discussions where the vetoing team says
this and the other team (like porters) say that. And what if someone has
objections against that veto? What procedure will handle this situation
then?
> 4. The requirement that any port has to have 5 developers support it,
> and be able to demonstrate that there are (at least) 50 users.
How should this demonstration should be achieved? What is the procedure for
this? When I grep my /etc/passwd I have 28 users for m68k on my own, but
that machine just counts as one user on popcon.d.o.
> Some people feared that this could kill off a port such as s390,
> which typically has little installations, but many users on a single
> installation. It was confirmed that the important number here is the
> number of users, rather than the number of installations; so any port
> should be able to reach that number.
... and this paragraph makes clear, that you just can't use popcon for that
issue. So, how shall those users be counted?
> None of the participants had a problem with any of the other
> requirements. Note that the separate mirror network is fully distinct of
> the rest of the original proposal (although there was a significant
> amount of confusion over that fact). The ability to be part of a
> stable release (or not) would be fully distinct of the separate mirror
> network; indeed, the implementation of both items will now be discussed
> and implemented fully separate, to avoid further confusion.
During the original vancouver proposal discussion the mirror network problem
was said to be the reason for the vancouver proposal. So, I expected a more
detailed info about this issue and how it would be solved (and when).
When the reason for the vancouver proposal is "just" mirror space on "some"
mirrors, why should this be addressed by a potential drop of archs anyway?
Why don't let the mirrors just mirror what they want? Nobody forces a mirror
admin that he *has* to be a primary mirror, right?
I have absolutely no problems with mirrors that don't carry all archs as
long as there are several mirrors that do.
> Initial:
> - must be publically available to buy new
> - must be freely usable (without NDA)
> - must be able to run a buildd 24/7 without crashing
> - must have an actual, working buildd
> - must include basic UNIX functionality
> - 5 developers must send in a signed request for the addition
> - must demonstrate to have at least 50 users
> - must be able to keep up with unstable with 2 buildd machines, and must
Again, I don't see the point in limiting the numbers of buildd machines as
long as the porters can handle them.
> have one redundant buildd machine
Why just one? Or should this have been "at least one"?
> Overall:
> - must have successfully compiled 98% of the archive's source (excluding
> arch-specific packages)
I believe 98% is way too high.
When I do a grep "up-to-date" unstable/listdir/*_stats I get:
unstable/listdir/alpha_stats: 93.17% (5578) up-to-date, 93.17% (5578) including uploaded
unstable/listdir/amd64_stats: 95.52% (5924) up-to-date, 95.52% (5924) including uploaded
unstable/listdir/arm_stats: 94.18% (5616) up-to-date, 94.21% (5618) including uploaded
unstable/listdir/hppa_stats: 90.70% (5385) up-to-date, 90.70% (5385) including uploaded
unstable/listdir/i386_stats: 99.87% (6258) up-to-date, 99.87% (6258) including uploaded
unstable/listdir/ia64_stats: 96.16% (5728) up-to-date, 96.16% (5728) including uploaded
unstable/listdir/m32r_stats: 0.00% up-to-date, 0.00% including uploaded
unstable/listdir/m68k_stats: 91.13% (5415) up-to-date, 91.13% (5415) including uploaded
unstable/listdir/mips_stats: 96.47% (5758) up-to-date, 96.47% (5758) including uploaded
unstable/listdir/mipsel_stats: 96.00% (5688) up-to-date, 96.00% (5688) including uploaded
unstable/listdir/powerpc_stats: 96.90% (5855) up-to-date, 96.90% (5855) including uploaded
unstable/listdir/s390_stats: 95.39% (5692) up-to-date, 95.39% (5692) including uploaded
unstable/listdir/sparc_stats: 96.61% (5787) up-to-date, 96.61% (5787) including uploaded
As you can see only i386 would satisfy this requirement.
For m68k it's quite sure that it never reaches the 98% mark, just because of
the high number of buildds.
There is currently a total of 5942 packages, but 132 are marked as building
and 143 as needs-build. 2% of 5942 packages would be 119 packages (118.84
exactly). So, with 132 packages marked as building, you already exceed the
allowed maximum of 2% missing packages.
This 98% mark is just arbitrary...
> - must have a working, tested installer
What is meant by "working, tested installer"? What are the requirements to
qualify as "working, tested"? Will any kind of installer be ok or is d-i
mandatory for that?
> - security team, DSA, and release team must not veto inclusion
What are possible reasons for a veto? Be define beforehand.
> - must be a developer-accessible debian.org machine for the
> architecture
A single machine is sufficient? Should this be a public available d.o
machine or is limited access sufficient?
> - binary packages must be built from unmodified Debian source
Uhm? When there is a new arch upcoming, they need to modifiy the Debian
source, at least sometimes, right? This counts especially for the inclusion
of there arch tag in the arch: line of the package. And I think, a new port
needs to patch the packages anyway, as well as already establised ports.
Or do you mean by "overall requirements" just the already established ports?
My interpretation of "overall" is that this counts for both (new and old
ports).
> - binaries must have been built and signed by official Debian
> Developers
This has been always the case, right?
> In addition to those points, we also agreed on the following:
> * The m68k porters (i.e., myself) would test out a buildd running with
> distcc so that a cost/benefit analysis of such a setup could be made.
> A full explanation of why such an analysis is required would take us
> too far; suffice to say that it isn't entirely guaranteed that there
> would be a noticeable performance increase, while the cost to maintain
> such a setup (as opposed to a regular buildd setup) is nontrivial.
Oh well, the current distcc on m68k simply doesn't work. Been there, done
that...
> * All ports must 'requalify'; that is, they must also comply with the
> set of initial requirements once, probably before etch releases.
> However, if one of the already existing ports satisfies most of the
> requirements from this list of initial requirements but there are a
> few that they cannot comply with for technical reasons, they can
> request exceptions.
The above contradicts to:
> 1. The requirement that 'an architecture must be publically available to
> buy new'.
>
> It was explained that this requirement was not made to be applied
> retroactively to already existing ports;
Either all existing ports won't need to requalify or they do. Otherwise you
get a point that is not exactly defined and thus a potential point where
opinions might collide. What are the requirements for those exceptions? Who
are about to grant them? Won't the teams veto?
Overall, I thing this new vancouver proposal (or whatever you name it) is a
little bit unprecise (or as I would say in German: "wischiwaschi" :). I miss
exact definitions of procedures and such. Of course I know it's difficult to
give those definitions in such a proposal, but it would have been nice when
those definitions would be worked out and voted about *before* the proposal
is implemented. This is valid especially for the veto thing. A vague veto
right is not a good thing and might be abused (or give the impression to
others of being abused).
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: 2744150@sipgate.de
Reply to: