Re: buildd maintainers stuck?
Steve Langasek <vorlon@debian.org> writes:
> 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
There should not be any need to request anything as it is the normal
buildd admins job to care for the buildd. Only on the rare occasions
that something slips through the cracks should there be any mail. You
can hardly call that bombarding.
> 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.
I'm saing that the email addresses should be used for what they were
created for in the first place. To contact the people that can do
something about the buildds for that arch and get a overlooked
transient failure underway again.
>> 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?
And how should they (be it porters or the maintainer him/herself)
bring it to their attention if not by mailing <arch>@buildd.d.o? You
just deterred from that in your mail. What other way is there?
And note that maintainers usualy have way more knowledge about their
package and package dependencies to know what they need. For the build
failures due to missing Build-Depends no arch specific knowledge is
required. Just the availability of packages.
> 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...
So for our "doorstopper" arch with so few porters you want to mail
~200 subscribers that xyz needs to be rescheduled on the buildd
because it slipped through the cracks so that the one person with w-b
access can do it? That one person should be subscribed to
<arch>@buildd.d.o which should be the direct route.
MfG
Goswin
Reply to: