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

Results of the meeting in Helsinki about the Vancouver proposal

Hi all,

"Vancouver" has gotten a very specific meaning in the Debian community:
one of a visionary proposal[1] that received quite its share of flames from
many Debian contributors, including myself. Since it appeared to many of us
that the intentional result of this proposal would have been to essentially
kill off many of our architectures, many of us weren't too happy with the

In subsequent communication with some of the people present at the
Vancouver meeting, however, it became apparent to me that this was not
the idea; rather, the proposal tried to create a set of quality
requirements for all of our ports, so that our users would be guaranteed
to get, for example, a Debian/SPARC of the same quality as

This in itself is a laudable goal; but as I felt that the requirements,
as proposed, did not meet that goal, I called for a meeting at DebConf5
with all parties involved and present at the conference.

This meeting has taken place on 2005-07-11[2], with the following people

* Bdale Garbee, DPL team member, has been involved with the startup of 5
* Branden Robinson, DPL;
* Wouter Verhelst, m68k porter;
* Gerfried Fuchs, local admin to buildd machines;
* Joey Hess, core d-i developer, present at the Vancouver meeting;
* Kurt Roeckx, non-DD amd64 porter;
* Anthony Towns, FTP-master, present at the Vancouver meeting;
* Jeroen van Wolffelaar, DPL team member, FTP team member, present at
  the Vancouver meeting;
* James Troup, arm and sparc buildd admin, DSA team member, FTP-master,
  present at the Vancouver meeting;
* Florian Lohoff, mips/mipsel porter, local admin to buildd machines;
* Andreas Barth, Release Assistant, present at the Vancouver meeting;
* Guido Günther, mips/mipsel porter;
* Robert Jordens, DD;
* Steinar Gunderson, DD

In addition, I have, beforehand, exchanged mail with Joey Schulze of the
Debian Security team about this meeting, and he's provided me with his
opinion on the matter.

While I did my best to get a wide range of people to attend, two notable
absentees are both our Release Managers. Since they couldn't be in
Helsinki, they obviously couldn't be at this meeting either (although
they've had the opportunity to review this text before it was sent out);
therefore, while we've come up with all sorts of things, they're not to
be seen as any sort of official release policy statement -- unless, of
course, it is officially added to our release policy by the release


The problematic items we discussed at this meeting included the
following four points:

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

   With this explanation and rationale, nobody at the meeting no longer
   had any opposition to the requirement, and it was retained.

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

   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.

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

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

   It should be mentioned that this requirement was meant to be
   implicitely part of the original proposal, but it is good to mention
   it none the less.

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.

   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.

   With this explanation and rationale, nobody at the meeting no longer
   had any opposition to the requirement, and it was retained.

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.

We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements -- requirements that
a port would need to fulfill in order to be allowed on the mirror
network -- but not necessarily as an 'overall' requirement -- a
requirement that a port will always need to fulfill if it wants to be
part of a stable release, even if it's already on the mirror network.
Those would look like this:

- 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
  have one redundant buildd machine

- must have successfully compiled 98% of the archive's source (excluding
  arch-specific packages)
- must have a working, tested installer
- security team, DSA, and release team must not veto inclusion
- must be a developer-accessible debian.org machine for the
- binary packages must be built from unmodified Debian source
- binaries must have been built and signed by official Debian

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

And that about sums it up. We think the last word most certainly has not
been said about this proposal (yet), but are happy that it could be
discussed in an open, civilized manner. Hopefully this will lead to an
even better-quality Debian in the future.


[1] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
[2] The fact that it took over a month to produce this announcement has
    everything to do with some post-meeting confusion and me slacking
    while producing this text. Sorry about that.

The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Attachment: signature.asc
Description: Digital signature

Reply to: