I would like to know whether making upstream release monitoring bug filing opt-out is ok with Fesco, given there are no objections on [https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00359.html fedora-devel-list].
Currently [https://fedoraproject.org/wiki/Upstream_Release_Monitoring upstream release monitoring] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list.
It might possible in the future to easily monitor a bunch more packages and create bugs in case there are newer versions available at upstream.
Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website.
I have a slight objection to this. I am concerned it will encourage the "ooh, shiny release must update" style of behaviour we already seem to have for some packages. I am well aware that the tool and proposal is targeted at rawhide, so I have no problems at all with the actual service. I think opt-in is the right approach for maintainers that want it automated so they don't have to check manually. However, there is a tendency from less diligent maintainers to push new releases to all branches regardless.
I'm not convinced reminding people there is a new release of a package they are supposedly maintaining, and should therefore already know about, is a great idea by default.
Replying to [comment:1 jwboyer]:
I have a slight objection to this. I am concerned it will encourage the "ooh, shiny release must update" style of behaviour we already seem to have for some packages.
I can add some text to the update notification to remind people to not update the released branches unreflected like:
| This is not a request to update the stable branches of this package. Please evaluate the risk of updating to this package in a stable branch before doing so.
I am not sure, if we have a document that helps maintainers to decide whether or not to update a package. But if there is one, a link could also be included.
If they know about the update, they will probably update anyway. If they don't for some reason, this can be documented in the created bug report.
Uh, are you expecting us to run through the web pages of every single package we're maintaining and check for new releases weekly? Upstream release monitoring is a very useful service.
It doesn't make much sense for some packages (e.g. for KDE, it doesn't make sense to file a bug for every single KDE component because they all release at the same time; the packages which are part of KDE releases should definitely be opted out, we track those anyway), but for all those small packages, it's extremely helpful.
However, there is a tendency from less diligent maintainers to push new releases to all branches regardless.
I wouldn't call it "less diligent" to do that unless they do it with blank update notes (or useless boilerplate like "new upstream version") or they push updates which are clearly useless on Fedora (e.g. "fix compilation bug on OS X").
Replying to [comment:3 kkofler]:
I'm not convinced reminding people there is a new release of a package they are supposedly maintaining, and should therefore already know about, is a great idea by default. Uh, are you expecting us to run through the web pages of every single package we're maintaining and check for new releases weekly? Upstream release monitoring is a very useful service.
And indeed I said it was a useful service. So we agree. Awesome. That has no bearing on the crux of my argument though, which is that opt-in is preferable and that opt-out could promote behaviour we'd rather not have.
However, there is a tendency from less diligent maintainers to push new releases to all branches regardless. I wouldn't call it "less diligent" to do that unless they do it with blank update notes (or useless boilerplate like "new upstream version") or they push updates which are clearly useless on Fedora (e.g. "fix compilation bug on OS X").
So I'm not pulling this concern out of my ass just to block things or make them harder. I have seen numerous updates to stable releases that do exactly that already. My primary concern is that these kind of questionable updates will increase as a result of a not opt-in service.
Replying to [comment:2 till]:
Replying to [comment:1 jwboyer]: I have a slight objection to this. I am concerned it will encourage the "ooh, shiny release must update" style of behaviour we already seem to have for some packages. I can add some text to the update notification to remind people to not update the released branches unreflected like: | This is not a request to update the stable branches of this package. Please evaluate the risk of updating to this package in a stable branch before doing so.
I think that is a good idea regardless of the opt-in/opt-out status of the service. If you agree, then we can just add it now :)
https://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines
I will note that there is no update policy for Fedora and that page is simple a recommendation. I don't believe it is your responsibility or within the scope of this request to debate the current recommendations or create an overall update policy. That isn't fair to you at all, so I will NOT ask you to do any of that.
Replying to [comment:4 jwboyer]:
Replying to [comment:3 kkofler]: I wouldn't call it "less diligent" to do that unless they do it with blank update notes (or useless boilerplate like "new upstream version") or they push updates which are clearly useless on Fedora (e.g. "fix compilation bug on OS X"). So I'm not pulling this concern out of my ass just to block things or make them harder. I have seen numerous updates to stable releases that do exactly that already. My primary concern is that these kind of questionable updates will increase as a result of a not opt-in service.
Since I'm bored this morning, I thought I would look through the currently pending updates queued for pushing to stable. This set is exactly what you said: boilerplate "new version" with no information:
https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7754 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7870 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7825 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7842 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7856 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7881 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7838 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7836 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7808 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7916 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7842 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7918 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-7813 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-7919 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3025
Replying to [comment:5 jwboyer]:
Replying to [comment:2 till]: Replying to [comment:1 jwboyer]: I have a slight objection to this. I am concerned it will encourage the "ooh, shiny release must update" style of behaviour we already seem to have for some packages. I can add some text to the update notification to remind people to not update the released branches unreflected like: | This is not a request to update the stable branches of this package. Please evaluate the risk of updating to this package in a stable branch before doing so. I think that is a good idea regardless of the opt-in/opt-out status of the service. If you agree, then we can just add it now :)
I want to improve the wording a little more and afterwards I'll add this.
The request has been declined: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.log.html#l-357
Here are some final comments for reference: 1. Off course the service does not recreate a new bug if an old bug was closed for the same reported version 1. It will even reuse existing open bugs that are still in state ASSIGNED 1. The next data source I wanted to use for this is http://oswatershed.org/ it will probably be an inter-distro project to keep the data accurate. The current coverage is 2469 upstream packages, but I do not know yet, how many of these are included in Fedora. 1. I agree that eventually this service can also be used to find possible unresponsive maintainers, e.g. if bugs are not touched for 6 months/one release cycle, it would not be bad if someone checks what is the problem 1. There is now a reference to the Package update guidelines included in the bug reports:
| Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines
Thx for the feedback.
The next data source I wanted to use for this is http://oswatershed.org/
NO! Just no!
Their data is highly inaccurate and useless. For example, they do not understand the difference between a stable and an unstable release, they claimed things like KDE 4.2.90 (4.3 Beta 2) as the "latest KDE release" for a while, they even list pre-alpha development snapshots like 4.3.60svn992161 as "releases". They also miss some releases of smaller projects. It seems their data is exclusively based on what distros package, so if a distro packages a snapshot, even in something like Rawhide, it'll think it's a stable release, and if a release is made, but not packaged by any distro, it won't notice it at all.
The data they claim for the distros is also wrong, e.g. the latest kdelibs in stable Fedora is definitely NOT 4.2.90. I think their data for F11 is actually what was in F12 Rawhide on the day F11 was released. Their system is also unable to figure out that our kdelibs is the same as openSUSE's kdelibs4.
Please DO NOT use OSWatershed data for anything!
There is no way around manually-maintained regexes to determine the latest version, and until OSWatershed understands that, their data will remain entirely useless.
Replying to [comment:10 kkofler]:
The next data source I wanted to use for this is http://oswatershed.org/ NO! Just no! Their data is highly inaccurate and useless. For example, they do not understand the difference between a stable and an unstable release, they claimed things like KDE 4.2.90 (4.3 Beta 2) as the "latest KDE release" for a while, they even list pre-alpha development snapshots like 4.3.60svn992161 as "releases". They also miss some releases of smaller projects. It seems their data is exclusively based on what distros package, so if a distro packages a snapshot, even in something like Rawhide, it'll think it's a stable release, and if a release is made, but not packaged by any distro, it won't notice it at all. The data they claim for the distros is also wrong, e.g. the latest kdelibs in stable Fedora is definitely NOT 4.2.90. I think their data for F11 is actually what was in F12 Rawhide on the day F11 was released. Their system is also unable to figure out that our kdelibs is the same as openSUSE's kdelibs4.
Thanks, this is good to know. I can assure you, that I would never simply pipe their data right into bugzilla, but perform some sanity checks first. The author is currently working on modifying the API so I can easily query the database. Once this is done, I will perform further investigation.
Please DO NOT use OSWatershed data for anything! There is no way around manually-maintained regexes to determine the latest version, and until OSWatershed understands that, their data will remain entirely useless.
Another option is just to use their mappings from Fedora packages to debian packages and use regexes from debian watch files also for Fedora. If you know any possible pittraps for this, please let me know. Also the author was very cooperative, so it may also happen that OSWatershed will become a inter distro database for regexes. Or did you already discuss these problems with OSWatershed?
Login to comment on this ticket.