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 [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There doesn't exist a [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]