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. 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. -- see shy jo
Attachment:
signature.asc
Description: Digital signature