Wouter, 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. ;) Cheers, -- 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