Learn more about these different git repos.
Other Git URLs
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)
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.
It was actually not adopted but wrongly orphaned.
Yeah, should it be owned by @pjones or you?
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...
Either, we both maintain this package.
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.
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 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.