Hello,
during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&a...
They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken packages forever?
On Tue, Jan 25, 2022 at 6:43 AM Miro Hrončok mhroncok@redhat.com wrote:
Hello,
during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&a...
They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken packages forever?
Wouldn't this fit under the non-responsive maintainer policy?
On 25. 01. 22 15:48, Stephen Gallagher wrote:
On Tue, Jan 25, 2022 at 6:43 AM Miro Hrončok mhroncok@redhat.com wrote:
Hello,
during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&a...
They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken packages forever?
Wouldn't this fit under the non-responsive maintainer policy?
Well, the obvious problem with that approach is that the packagers are otherwise active (at least the majority of them):
Fabian Affolter (5 bugzillas) Dan Horák (4 bugzillas) Peter Robinson, Rust SIG, Mukundan Ragavan...
And the non-responsive maintainer policy kinda assumes the maintainers are generally not interested / responsive.
Hi Miro,
Miro Hrončok mhroncok@redhat.com writes:
On 25. 01. 22 15:48, Stephen Gallagher wrote:
On Tue, Jan 25, 2022 at 6:43 AM Miro Hrončok mhroncok@redhat.com wrote:
Hello,
during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&a...
They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken packages forever?
Wouldn't this fit under the non-responsive maintainer policy?
Well, the obvious problem with that approach is that the packagers are otherwise active (at least the majority of them):
Fabian Affolter (5 bugzillas) Dan Horák (4 bugzillas) Peter Robinson, Rust SIG, Mukundan Ragavan...
And the non-responsive maintainer policy kinda assumes the maintainers are generally not interested / responsive.
In that case I would suggest that we draft a policy comparable to how we handle FTBFS packages, as non-installable packages are about as useful as those that cannot be build (at least for the end user they might be actually more harmful).
Cheers,
Dan
On Tue, Jan 25, 2022 at 8:00 PM Miro Hrončok mhroncok@redhat.com wrote:
Well, the obvious problem with that approach is that the packagers are otherwise active (at least the majority of them):
Fabian Affolter (5 bugzillas) Dan Horák (4 bugzillas) Peter Robinson, Rust SIG, Mukundan Ragavan...
And the non-responsive maintainer policy kinda assumes the maintainers are generally not interested / responsive.
I have just submitted fixed builds for the three Rust SIG packages on your list, and hope nobody screams at me because I touched "their" package. The fixes were really simple (disabling an unused optional feature with broken dependencies, and rebuilding the package). People other than me set the bugs to "ASSIGNED" but then went on to never touch the packages again. ¯_(ツ)_/¯
Fabio
On 25. 01. 22 12:42, Miro Hrončok wrote:
Hello,
during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&a...
They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken packages forever?
This problem might have solved itself. The bugzillas were recently closed due to Fedora 34 EOL.
Hence, for each package 3 new bugzillas were created (for 35, 36 and 37), and those are now NEW.
I wonder how many of them will be set to ASSIGNED without any action, how many will get fixed, and how many will actually pass unnoticed this time, allowing the packages to be orphaned and hopefully taken by somebody who will fix them.
On Fri, Jun 10, 2022 at 7:33 AM Miro Hrončok mhroncok@redhat.com wrote:
I wonder how many of them will be set to ASSIGNED without any action, how many will get fixed, and how many will actually pass unnoticed this time, allowing the packages to be orphaned and hopefully taken by somebody who will fix them.
Historical data will be hard, but if future FTI (and FTBFS, in case we want that later) bugs are tagged with a specific string in the Whiteboard, it would be easy to add a query for FTI bugs closed EOL. That could be a very interesting stat for us to track over time.
On 10. 06. 22 15:21, Ben Cotton wrote:
On Fri, Jun 10, 2022 at 7:33 AM Miro Hrončok mhroncok@redhat.com wrote:
I wonder how many of them will be set to ASSIGNED without any action, how many will get fixed, and how many will actually pass unnoticed this time, allowing the packages to be orphaned and hopefully taken by somebody who will fix them.
Historical data will be hard, but if future FTI (and FTBFS, in case we want that later) bugs are tagged with a specific string in the Whiteboard, it would be easy to add a query for FTI bugs closed EOL. That could be a very interesting stat for us to track over time.
They all blocked the F34FailsToInstall tracker, if that helps.
On Fri, Jun 10, 2022 at 11:12 AM Miro Hrončok mhroncok@redhat.com wrote:
They all blocked the F34FailsToInstall tracker, if that helps.
It helps for F34, but updating the tracking bug for each release doesn't play well with my Jupyter notebook. But! Now that I've had more coffee I realize that I can just look for the "FailsToInstall" and "FTBFS" string in the bug summary. It's not perfect (someone might edit the summary to remove that string or another bug might include it but not actually be what we're looking for), but the cases where we get a false positive/negative should be small enough to not matter.
As an added bonus, I already have the historical data to do this for past releases. So I think I'll include this in my updated "Exploring our bugs" talk at Nest.
devel@lists.stg.fedoraproject.org
-
Ben Cotton -
Dan Čermák -
Fabio Valentini -
Miro Hrončok -
Stephen Gallagher