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

Re: Are mails sent to xxxx <at> buildd.debian.org sent to /dev/null ?

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

Reply to: