[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 ?



Steve Langasek <vorlon@debian.org> writes:

> On Thu, Dec 16, 2004 at 11:10:15PM -0500, Joey Hess wrote:
>> Jay Berkenbilt wrote:
>> > I've sent messages to various arch@buildd.debian.org addresses many
>> > times for various reasons, and they have all always been ignored.
>
>> Me too, for values of ignored that include "may have resulted in some
>> action, but never got a reply email".
>
>> I think that we need BTS pseudo-packages for the autobuilders.
>
> 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.

What would help would be an email address where any DD can send a
signed mail to request a rebuild or to set a dep-wait or a build
failure.

There could be a webpage where one selects the package(s) and
architecture and it generates a mail template that just needs to be
signed and send in case you fear the syntax is to complex.

> In the case of mails sent to <arch>@buildd.debian.org about issues that
> go unfixed for long periods, it would be nice to know what the story is.
> And personally, since I send a lot of these mails about packages with RC
> issues, I think more feedback from the buildd maintainers would help me
> to know better when these emails are helpful and when they're a
> distraction; but in the absence of feedback, I'll continue to assume my
> current approach is ok...
>
> -- 
> Steve Langasek
> postmodern programmer

MfG
        Goswin



Reply to: