Bug#935365: buildd.debian.org: allowing self-service givebacks for Failed packages?
Hey Samuel, thanks for your feedback! On 8/22/2019 12:17 AM, Samuel Thibault wrote: > The self-service giveback is currently not available for packages in the > Failed state. I wonder if such a restriction is really useful. > > The thing is: apparently only I do this, but I always set hurd-i386 > package build failures in the Failed state with the appropriate failure > log lines, which are very helpful for sorting out the porting work > (see https://people.debian.org/~sthibault/graph-top.txt), and packages > maintainers have already told me they appreciate this, because I know > well the hurd-i386 failures and can thus easily point out the actual > problems to maintainers. > > But if people can not giveback due to this even in cases where it's a > transient failure or lagging dependency version, I'am afraid they will > now not send a mail for giving back on hurd-i386, thinking that I have > set the Failed state for a stronger reason than I actually meant. > > Put another way, this restriction on the Failed state leads me to think > I should rather stop setting packages in the Failed state, but then it's > detrimental to the porting work triaging. I think I came from the point where Failed is a manually set state that conveyed a meaning that we should not just erase, especially if we face opportunistic give-backs. At the same time that sort of depends on the frequency of the use of this feature. Traditionally `Failed' was supposed to be for failure states that were known to require another package upload. I guess what you are saying here is that you'd also set Failed if another package is at fault. I can relate to that, as expressive documented failure reasons are always better than just log tails - if you have the time to add those annotations. I also don't know if we have a good way of gauging consensus among porters here. I added buildd-maintainers@ to bcc. Please chime in if you have an opinion here. In the end it's easy to do. I'm sympathetic to just allow it and see if it actually causes trouble. AFAIK we also preserve the last failure reason in the database and do not immediately wipe it out (TBC). > Actually, even when the Fail state has been set manually on archs (e.g. > a know bug affecting all archs), it would still make sense to allow > maintainers to trigger the giveback when the bug is known to be fixed by > another package upload. I really do not want to check if someone is a package's maintainer if I can avoid it. But then again this is also something that could legitimately be done by the uploader of the other package anyway. Kind regards and thanks Philipp Kern
Bug#935365: buildd.debian.org: allowing self-service givebacks for Failed packages?
Package: buildd.debian.org Severity: normal Hello, The self-service giveback is currently not available for packages in the Failed state. I wonder if such a restriction is really useful. The thing is: apparently only I do this, but I always set hurd-i386 package build failures in the Failed state with the appropriate failure log lines, which are very helpful for sorting out the porting work (see https://people.debian.org/~sthibault/graph-top.txt), and packages maintainers have already told me they appreciate this, because I know well the hurd-i386 failures and can thus easily point out the actual problems to maintainers. But if people can not giveback due to this even in cases where it's a transient failure or lagging dependency version, I'am afraid they will now not send a mail for giving back on hurd-i386, thinking that I have set the Failed state for a stronger reason than I actually meant. Put another way, this restriction on the Failed state leads me to think I should rather stop setting packages in the Failed state, but then it's detrimental to the porting work triaging. Actually, even when the Fail state has been set manually on archs (e.g. a know bug affecting all archs), it would still make sense to allow maintainers to trigger the giveback when the bug is known to be fixed by another package upload. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
