#10105 Oprhan packages with stalled F34FTBFS bugzillas
Closed: Fixed 2 years ago by churchyard. Opened 2 years ago by churchyard.

I'm doing this.

rpms/biber
rpms/python-pyriemann
rpms/rubygem-xml-simple
rpms/sugar-measure
rpms/Inventor
rpms/kjots
rpms/plasma-pass
rpms/paris-traceroute
rpms/python-aiomqtt
rpms/python-holidays
rpms/subfinder
rpms/rtags
rpms/xorg-x11-drv-nouveau
rpms/libclc
rpms/python-sshtunnel
rpms/emacs-auctex
rpms/aespipe
rpms/manifest-tool
rpms/papaki
rpms/koules
rpms/php-opencloud-openstack
rpms/xwota
rpms/icebreaker
rpms/rubygem-haml
rpms/rubygem-maruku
rpms/vagrant-lxc
rpms/python-sphinxcontrib-issuetracker
rpms/erlang-eper
rpms/htmldoc
rpms/emacs-haskell-mode
rpms/llvm10
rpms/php-composer-installers
rpms/php-guzzlehttp-psr7
rpms/php-typo3-phar-stream-wrapper
rpms/geronimo-osgi-support
rpms/puppet
rpms/oci-kvm-hook
rpms/opam
rpms/lmms
rpms/emacs-lookup
rpms/flannel
rpms/coffee-script
rpms/libgta
rpms/openvas-gsa
rpms/openvas-libraries
rpms/openvas-manager
rpms/openvas-scanner
rpms/grub2
rpms/python-transitions

https://bugzilla.redhat.com/buglist.cgi?bug_id=1905190,1917401,1923284,1923292,1923296,1923316,1923317,1923329,1923330,1923332,1923334,1923338,1923340,1923345,1923365,1923372,1923373,1923400,1923418,1923424,1923427,1923428,1923432,1923437,1923449,1923450,1923475,1923477,1923506,1923520,1923557,1923588,1923606,1923617,1923618,1923619,1923631,1923634,1923637,1923645,1923652,1923676,1923682,1923684,1923686,1923687,1923702,1923703,1923704,1923705,1924713,1926826


Metadata Update from @churchyard:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

rpms/xorg-x11-drv-nouveau
and
rpms/grub2

seem pretty concerning...

They are orphaned, not retired. Hopefully somebody will adopt them.

grub2 was actually already adopted and the bug closed.

grub2 was actually already adopted and the bug closed.

It was actually not adopted but wrongly orphaned.

Yeah, should it be owned by @pjones or you?

grub2 was actually already adopted and the bug closed.

Why was it ever FTBFS for F-34, there was like 14 builds in the F34 cycle on a semi regular cadence

grub2 was actually already adopted and the bug closed.

Why was it ever FTBFS for F-34, there was like 14 builds in the F34 cycle on a semi regular cadence

Also the bug filed for F-34 that lead to this referenced a ELN build, not a Fedora build...

Yeah, should it be owned by @pjones or you?

Either, we both maintain this package.

Why was it ever FTBFS for F-34, there was like 14 builds in the F34 cycle on a semi regular cadence

It failed during the mass rebuild (at least that's what the bugzilla says) and the bugzilla was ignored since, despite multiple reminders and needinfos.

It failed during the mass rebuild (at least that's what the bugzilla says) and the bugzilla was ignored since, despite multiple reminders and needinfos.

Yet on the FTI bugs you auto close them, why can't the same be done for FTB?

Why was it ever FTBFS for F-34, there was like 14 builds in the F34 cycle on a semi regular cadence

It failed during the mass rebuild (at least that's what the bugzilla says) and the bugzilla was ignored since, despite multiple reminders and needinfos.

As mentioned the BZ referenced a ELN koji build. Anyways, All I ask is to avoid orphaning critical packages unnecessarily, otherwise it just adds more work for maintainers who are already overloaded.

Yet on the FTI bugs you auto close them, why can't the same be done for FTB?

Because nobody got it working reliably. The motivation there is not that big, because the action that happens if the bugzilla was incorrect is easily revertible and most of the bugzillas are actually closed by the maintainers when fixed.

As mentioned the BZ referenced a ELN koji build.

I've opened https://pagure.io/releng/issue/10109 about this.

Anyways, All I ask is to avoid orphaning critical packages unnecessarily, otherwise it just adds more work for maintainers who are already overloaded.

I think that critical packages especially should follow the policies we have, otherwise how do we know sure they are properly taken care of, they issues triaged, and dealt with in timely manner? All that was required here to avoid the orphaning was to respond withing the 3 months window between the mass rebuild and this ticket. All that was required to correct the orphaning was to click a button in Pagure.

The idea of the policy is quite simple: If packagers don't have time to respond to reported problems, give opportunity for others in the community to take over. Even if sometimes the automation produces a weird incorrect report, such as this one, correcting the error (e.g. closing the bugzilla as NOTABUG) seems like a natural thing to do. However, If you disagree with the policy, I suggest to open a discussion about it on the devel mailing list, we are unlikely to change the policy in this ticket. Alternatively, you could ask for an exception from the policy for grub2, see this example.

Yes, in this case, the bugzillas was incorrectly opened and I am sorry for the unnecessary orphaning. But I don't think that requires a change in the policy.

The idea of the policy is quite simple: If packagers don't have time to respond to reported problems, give opportunity for others in the community to take over. Even if sometimes the automation produces a weird incorrect report, such as this one, correcting the error (e.g. closing the bugzilla as NOTABUG) seems like a natural thing to do. However, If you disagree with the policy, I suggest to open a discussion about it on the devel mailing list, we are unlikely to change the policy in this ticket. Alternatively, you could ask for an exception from the policy for grub2, see this example.

The major problem with the policy is you've taken it to the extreme spamming people too much so people with already high levels of RHBZ email have it multiplied to high levels with regular reminders and spam so they literally filter them out to stop the deluge. The FTB/FTI are useful but they're also excessive.

As, always, I invite you to discuss the policy on the devel list, instead of expressing your opinion in tickets like this one. Last time a major discussion happened, the current form of policy emerged. It might not be perfect, but it's the compromise the majority agreed upon.

Login to comment on this ticket.

Metadata