On Tue, Dec 06, 2005 at 02:56:28PM +0100, Goswin von Brederlow wrote: > Steve Langasek <vorlon@debian.org> writes: > > On Tue, Nov 29, 2005 at 07:46:42PM -0800, Thomas Bushnell BSG wrote: > >> The initial upload of libcapplet 1:1.5.11-12 failed to build on alpha, > >> arm, i386, and mipsel because of a temporarily absent build > >> dependency. This upload occurred over three weeks ago. > >> On November 17 I requested that the buildds requeue this build, but > >> nothing has happened. Can the release team please schedule a binNMU > >> or do whatever is supposed to happen? > ... > > My preference would be that such requests be sent first to the porters > > (either the mailing lists specified on http://www.debian.org/ports/, or the > > individual porters mentioned on the wiki pages linked from > > http://release.debian.org/etch_arch_qualify.html). While most of these > > porters are not themselves buildd admins, they *are* the people responsible > > for the overall health of a given port, and they should definitely be taking > > an active role in sorting out build failures for their architecture; so if > > they aren't already in a position to batch-proxy such requests to the buildd > > maintainers, they darn well ought to get there. > Please don't. That is just wrong. > All packages should be buildd build and the porters can do nothing if > the buildd (admin) screws up. It realy is the admins job to fix the > buildd and handle missing Build-Depends. [Note to Thomas: porters who refer to transient build failures as buildd admin "screw-ups" are not the porters you're looking for.] So are you arguing that all 1000+ maintainers should be bombarding buildd maintainers directly with requeue requests of unknown validity, with the current duplicate requests, general port ignorance, and spam ensuring that the mail address has a sufficiently low S:N ratio that it's hardly worth paying attention to? Or are you saying that no one, porters included, should work with buildd maintainers and bring it to their attention when a transient failure has been overlooked or resolved? I don't see either approach as being particularly helpful. > If the port is suddenly responcible for fixing buildd problems then > more people need access to wanna-build and buildds so they can actualy > do something about it. Or binary NMUs must be un-deprecated again. No, buildd admins are responsible for fixing buildd problems. *Porters* are responsible for *ensuring their port is a viable release candidate*. Given that one of the release criteria is "keeping up with unstable", porters most definitely *are* expected to help make sure packages are getting built. From a "too many cooks" standpoint, this doesn't mean constantly looking over the buildd admin's shoulder and telling them every time a package needs requeued; see the other thread on -devel for my take on better ways for porters to spend their time. But if a package that failed earlier gets un-stuck, and the buildd admin hasn't noticed, shouldn't it be the porters who bring it to their attention? Oh, and for the record: the score today is that of 10 existing Debian ports that are required to have designated porters to be qualified as release candidates for etch (that's excluding i386, which has... um... "virtual porters", and amd64 which isn't hooked to the official w-b yet), 7 of them have at least one porter with w-b access for the port. So if the porters aren't working with the buildd admins, chances are good they're not working with their fellow porters either... -- 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