On Fri, Dec 17, 2004 at 11:43:35PM -0500, Joey Hess wrote: > Steve Langasek wrote: > > I'm not sure that would help much; indeed, in the common case (package > > needs a simple requeue, buildd admin would have taken care of it in due > > course anyway, sender isn't worried about a lack of reply as long as > > things are fixed), it would seem to impose a lamentable amount of > > overhead -- time that could otherwise be spent on the never-ending task > > of buildd/port maintenance. The BTS overhead is justified for packages, > > since any developer can NMU a package; as long as the buildds for most > > ports are one-maintainer-per-arch, I don't see that having a list in the > > BTS of packages to be requeued gives us anything over the present > > situation. > Can't most of these arguments be applied to the ftp.debian.org and > www.debian.org pseudo-packages too? Substitute in packages that need to be > removed due to broken deps, priority problems, and broken web page links. Those pseudo-packages have team maintainers, so the BTS serves as a tool for coordinating work within the teams even though they're not subject to "NMUs". With one exception, the buildds today have only a single responsible per architecture. I don't particularly think this is a good design, but so long as this is what we have, I think the benefit of buildd pseudopackages is limited. > If the buildd admins didn't want requeue requests in the bts, they could > make that a matter of policy, much like the way ftp-master deals with > most priority changes. > Having a bts would still be useful for serious buildd breakage (both for > letting the admins know and for letting other developers know), and for > some of the other less usual stuff like not-for-us updates. Yes, being able to record buildd breakages in the BTS would seem to cut down on the highest-density source of duplicate questions. That could make it a worthwhile exercise. Inasmuch as not-for-us refers to P-a-s, one must also take into account that the list is maintained centrally for all ports, and not all buildd maintainers have access to it (AFAIK). -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature