Hello, Philipp Kern, le lun. 06 janv. 2020 09:21:19 +0100, a ecrit: > On 1/6/2020 1:16 AM, Samuel Thibault wrote: > > Andreas Beckmann, le lun. 06 janv. 2020 00:42:00 +0100, a ecrit: > >> gb bppphyview . ANY > >> gb datovka . ANY > > > > Ran so. > > > >> Please give back all failed binNMU builds of datovka and bppphyview, > >> these have been transient failures. Also include hurd-i386 which is in > >> 'Failed' state and could not be handled by self-served give-backs. > > > > Ah, gb doesn't giveback those indeed. > > > > That's very unfortunate, since I use the Failed state to document what I > > believe is the build issue (I have keyboard shortcuts that makes it easy > > for me to find out quickly). > > I have a hard time parsing what you want the state to be
Sorry, there were some bits I forgot to write above. > (and didn't we have this discussion before?). Yes, we discussed a bit about this: I mean I almost systematically use the Failed state to document the encountered build issue. But what I mean here is that it does not mean that give-backs are not welcome, i.e. the Failed state should not be considered inamovible, just documentation for the failure. > The syntax for gb is to add ". -o" at the > end to override "Failed" - this had always been true. Ok. > Technically a give-back discards some information here, Sure! It's fine here since it was exactly the documented failure which was targetted by the giveback. > One could say "if there's a previous failed reason for the same > version, put it into Failed again", but then it might actually be > inaccurate. Yes. I prefer more giveback anyway, it is quite cheap for me to reprocess the build log. > If you want "Failed" to be a valid state for *self-service* givebacks > to work, let me know. I'd rather see it so, yes. Samuel
