Re: give-back datovka, bppphyview
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
Reply to: