Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote:
> On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> > FAILED
>
> But FAILED is an advisory state anyway; it doesn't directly benefit the
> port, at all, to have the package listed as "Failed", this is just a
> convenience for folks sifting through the build failures (like the rarely
> used "confirmed" BTS tag is for maintainers). In the long-term, one of two
> things needs to happen with each of these build failures: the package needs
> to be added to P-a-s so the arch no longer tries to build it, or the package
> needs to be fixed -- via porter NMU if necessary.
>
> So as you have the list of these packages, as a porter you can proceed with
> figuring out which of the two categories each falls into, and take the
> necessary action without worrying about the "Failed" state, yes?
Indeed, for practical buildd maintainance purposes, the distinction is
not that important -- though 'Failed' is known to not benefit of a
requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
most archs should have enough surplus buildd power that retrying
everything once in a while doesn't hurt.
The major benefit is though to make it apparant for porters what to look
into, without all the 'noise' in between of maybe-transient failures.
One could also make sure that the FTBFS bugs are tagged (user-tagged)
with debian-sparc@l.d.o (etc) for example (or $arch@buildd.d.o? There
doesn't exist a d-mipsel@l.d.o for example...), so that one can get a
nice overview of all the porting bugs. It'd make sense to synchronise
this across all architectures, so that it is consistent.
If that is done, and there would be some way for porters to easily tag
the build failures themselves on what bug they correspond with, or not,
and especially, what failures are new and are yet to be tagged, there'd
be an easy and clear workflow for porters to work on failures. I don't
think there has really been such a defined porter workflow for build
failures, and nobody so far has built/defined one to the best of my
knowledge. And this touches one of the core points Vancouver is intended
to solve: *porters* need to work on *porting*, and help actively and
actually fixing porting issues in the archive. If creating a better
interface for people to work on this is a part of achieving it, so be
it. I'll see whether I can hack up something together for this,
extending buildd.d.o/~jeroen/status.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: