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

Re: Results of the meeting in Helsinki about the Vancouver proposal


Thank you for your work in preparing this; I think this summary is a
good beginning for revisiting the questions the Vancouver meeting poses
for etch.

On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:

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

As I reiterated several times in the discussion earlier this year, the
Vancouver proposal was motivated in part by a concern that the absolute
count of release architectures in Debian is too high to be sustainable
even if all architectures met the proposed criteria.  It may be the
decision of the Project that this is the release team's problem, but
people should recognize that this is not a decision that comes for free.
Even well-maintained ports will occasionally introduce their share of
architecture-specific problems, and we certainly have ports that are not
well-maintained right now, including in ways not addressed by any of the
proposed criteria that came out of Vancouver.

In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable.  Some may
remember that the new glibc/gcc blocked non-toolchain progress for
months during the beginning of the sarge release cycle, and that the
aftermath took months more to be sorted out.  So far, etch threatens to
be more of the same; in the past month we've had:

- miscellaneous, but far-reaching, internal compiler errors with gcc-4.0
  on at least arm and m68k, though at least m68k seems to be getting
  dealt with in response to a disclaimer from the gcc maintainer that he
  was unable to support m68k
- a binutils bug on hppa that caused a glibc miscompilation, leading to
  /usr/bin/make segfaulting consistently and bringing the hppa buildd to
  a halt for about a week
- a change in glibc resulted in certain libraries built with an old
  version of binutils on powerpc to blow up the linker; binNMUs all around,
  moderatedelays  for building other packages but not a big deal since
  everything waits on glibc anyway; nevertheless, definitely a time sink
- an undocumented ABI change in glibc on alpha that results in fakeroot
  reporting files as zero bytes in size at inopportune times (like when
  trying to compile the file containing the declaration of main()...);
  this one has just been identified, and we can probably count on
  another week to get it firmly resolved, followed by another glibc
  upload and another week of waiting...

There was discussion in Vancouver about requiring ports to have an
"upstream" kernel maintainer, FSO "upstream"; perhaps we should be
considering requiring there to be a glibc/gcc/binutils upstream for each
port, so that we don't get the first sign of these bugs when the
packages hit unstable.

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

FWIW, though I don't think anyone has any intention of checking up on
ports to make sure they're still meeting these requirements, several of
the "initial" requirements you list look to me like things that should
self-evidently be required on an ongoing basis, namely:

> - 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
> - must demonstrate to have at least 50 users
> - [...] must have one redundant buildd machine

IOW, I don't think it's ok for an architecture to lose "basic UNIX 
functionality" once it's been approved as a release candidate. ;)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: