Bugzilla – Bug 1113638
Request: A Bugzilla workflow to report out of date packages
Last modified: 2021-10-25 12:29:10 UTC
Hello, I've been transitioning my infrastructure to openSUSE over the past few months and have been particularly attracted to the development model of Factory/TW -> LEAP -> SLE. openSUSE provides options and choice for users regardless of what end of the innovation timeline they want to jump in on. I'm primarily using TW and have identified a good amount of packages that were out of date. I've updated a lot of these on my own and submitted requests, I really enjoy the scrappy 'make the project how you want it to be' atmosphere. For others, I've filed bug reports to give the maintainers a chance to Rev the package; this could be a more complicated package or something that's more critical to the core functionality of the distribution. I'd like to request feedback on a potential new workflow in Bugzilla. Tumbleweed -> Component = "Out of date package". This would allow users to file out of date package submissions without needing to go to the catch-all 'Other' bucket like I've been using today. I'd also like to volunteer to create a wiki page detailing how users can file these reports (along with a quick tutorial on how they can rev the package on their own, if possible). I've received feedback from a few project members that "out of date packages are not a bug" conflicting with "you should file a bug report if you see something out of date"; this could help set consistent guidelines for the community on this topic, help keep TW fresh and new packages flowing into the rest of the distribution and identify packages where the maintainers are absent or have abandoned the package so we can identify a new project owner. I'd appreciate any feedback on this idea, thanks. Sean
Any thoughts on this? It would be great to have a project-wide mechanism to help with this that packagers, maintainers and users could be on the same page with. Thank you.
I like the "wait (at least) 2 weeks before reporting outdated packages" rule that Wolfgang Bauer suggested. For security/critical updates there are already other communication channels, so putting pressure for regular updates is unnecessary. Could this be automated? I am thinking about repology or distrowatch lists, with some script checking version updates, and automatically filing a bug report in case Factory/Tumbleweed didn't get the update 4 weeks later.
I agree there should be some sort of parameter around using the workflow; I'm more in favor of 1 week versus 2 weeks as it takes time to Stage/QA the update, then roll it into TW to get user feedback on it. If someone will create the workflow in Bugzilla I'll be glad to write a wiki article and we can tweak the suggestion on etiquette/delay time later. On the automation topic, agreed there are a number of sources. Distrowatch provides RSS feeds, Arch Packages is also a good source to track.
Hi, I have no idea why I was assigned to this ticket. I cannot do anything with BugZilla. However, take a look at https://release-monitoring.org/
Marcus, we loosely discussed this type of tracking a (long) while back. Do you think it would be useful from the maintenance perspective at all?
i am doing some tracking already (gem feed, python pi feed, freshcode.club feed), but have not yet integrated release-monitoring.org My scripts set the openSUSE:UpstreamVersion in the packages and send emails to maintainers. <attribute name="UpstreamVersion" namespace="openSUSE"> <value>0.6.21</value> </attribute>