Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/07/2009 01:03 AM, Till Maas wrote: 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 would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. I would also like to have a webpage where I can go to check the Fedora vs upstream release status across all maintained branches including Rawhide. So the information needs to be gathered for all upstream releases. There are some cases where the website moves or fall off the face of the earth or where upstream is completely confused about proper versioning but that is the exception and not the norm. Can be dealt with on a case by case basis. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 6, 2009 at 10:11 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: I would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. Err, uhm...I'd rather not see bugzilla overloaded with this sort of notification. But I would LOVE to see this integrated as notification information into the Fedora Community portal concept. I know a lot of us rely on bugzilla as the mainstay to a lot of our workflow...everything is a nail when all you have is a hammer. Everything is a bug when all you have is a bug tracker...But I think the maintainer portal concept introduced with the debut of Community is something we should start driving enhanced functionality at. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] 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. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. If you have some ideas, which versions may cause problems, please provide some examples. I will then add them to the unittests and see, how well they are handled. For this I need at least one upstream version, one rpm version/release pair and an expected result (which should be newer or are both the same). c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? The options are to ignore the package or to update the URL when they change. 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. alarm bell ring/ Website? == yet more bureaucracy I don't get how you might even expect more bureaucracy from some status website. What do you think this website might be? It will not require anybody to look at it, but provide the information to interested people. Regards Till pgpK7apk6pFgO.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 11:27:23PM -0500, Eric Sandeen wrote: Speaking just for myself, I'd be happy to have it automatic for my packages. But wow, who's going to key in all those regexps and keep it up to date? On source of normalized data is Oswatershed[0]. My long time vision would be to manage this data in a central place like there and to coordinate the management of the data also with other distributions. Regards Till [0]http://oswatershed.org/ pgpPyKFWKRLu2.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, 2009-08-07 at 10:48 +0200, Till Maas wrote: 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. alarm bell ring/ Website? == yet more bureaucracy I don't get how you might even expect more bureaucracy from some status website. What do you think this website might be? It will not require anybody to look at it, but provide the information to interested people. It remembers me a website made by Remi[1] which list for all the package available, for all the branch what version are in the repo. It also provides comparison between upstream and repo for some packages such as the PECL, PEAR and R packages. [1] http://rpms.famillecollet.com/rpmphp/ Regards, Pierre -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 10:56:03AM +0200, Pierre-Yves wrote: It remembers me a website made by Remi[1] which list for all the package available, for all the branch what version are in the repo. It also provides comparison between upstream and repo for some packages such as the PECL, PEAR and R packages. [1] http://rpms.famillecollet.com/rpmphp/ Thx, I added it to the list of these kind of projects: https://fedoraproject.org/wiki/Upstream_Release_Monitoring#Related_Projects Regards Till pgpD31DcmBk4k.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Friday 07 August 2009 09:56:03 Pierre-Yves wrote: It remembers me a website made by Remi[1] which list for all the package available, for all the branch what version are in the repo. It also provides comparison between upstream and repo for some packages such as the PECL, PEAR and R packages. We should warn Remi about the numbering in R packages where . and - are equivalent in releases. The practical consequence of this is that most of our packages are up to date instead of the brown warning shown in the table. :-) [1] http://rpms.famillecollet.com/rpmphp/ Regards, Pierre -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 10:21:20PM -0800, Jeff Spaleta wrote: On Thu, Aug 6, 2009 at 10:11 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: I would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. Err, uhm...I'd rather not see bugzilla overloaded with this sort of notification. But I would LOVE to see this integrated as notification information into the Fedora Community portal concept. Fedora Community portal integration would be a good thing, but bugs may still be needed, e.g. if a package update depends on something else: Recently there was some latex breakage iirc that prevented a an update of some package to happen. Nowadays this is solved with blocking on the other bug report. For this to work with the portal, it probably also needs advanced bugzilla skills and it would be nice to have portal support in bugzilla. Is there something like python-fedora to create notifications within the portal? Regards Till pgptGzw3717WJ.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/07/2009 10:48 AM, Till Maas wrote: On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] 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. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? Correct. Such a system may be useful for some people and applicable to some cases, therefore I don't see many reasons why people in such situations shouldn't be using it (== opt-in). a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Package maintainers (e.g. me) are not interested in more Fedora bureaucracy nor in having to cope with yet another system (besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering organs (FPB, FESCO, FPC, Fedora committee de jour etc.). Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? I sense a miscommunication. As I understood your mail and [0], you are offering a service, maintainers can opt-in to use. Now you would like to make your service the default (== opt-out) and are asking for opinions. Did I misunderstand? b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. I am not sure if this can ever be achieved, because there exist many varients of versioning schemes and because it's not uncommon for upstreams switch between several. If you have some ideas, which versions may cause problems, please provide some examples. Some classic cases: * 1.2pre .. pre release , 1.2 release, 1.2a bugfix a. * 1.2a .. 1.2a release, 1.2b 1.2b release. * 1.2pre .. pre release, 1.2. release, 1.2.1 successor of 1.2 * 1.2 ... latest release, 1.3 successor of 1.2 (GNU versioning) * 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning, releases are using numerical versions, versions with suffix a,b,c... are prereleases) * 1.18, 1.1901, 1.1902, 1.20 (Perl versioning ... X.20 X.1900 !) * Frequent builds using the same version (replacing the same tarball), e.g. daily snapshots. ... Now imagine upstreams switching between these .. No idea, how you would want to handle this. I will then add them to the unittests and see, how well they are handled. For this I need at least one upstream version, one rpm version/release pair and an expected result (which should be newer or are both the same). c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? The options are to ignore the package or to update the URL when they change. How? For your service to be helpful, you would have to do this automatically. I don't see, how this could be achieved. 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. alarm bell ring/ Website? == yet more bureaucracy I don't get how you might even expect more bureaucracy from some status website. What do you think this website might be? It will not require anybody to look at it, but provide the information to interested people. [0] says write a regex, opt-out would mean forced interaction with your website, opt-in would mean registration. All in all, I read this as bureaucracy. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 12:28:50PM +0200, Ralf Corsepius wrote: On 08/07/2009 10:48 AM, Till Maas wrote: On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] 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. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? Correct. Such a system may be useful for some people and applicable to some cases, therefore I don't see many reasons why people in such situations shouldn't be using it (== opt-in). The question is, wether there are more people benefiting from it than are are being disturbed by it. If more people are benefiting, then imho opt-out is ok, if not, then it should be opt-in. But I am mainly interested in whether people are disturbed by such bug reportes, even if the bug report is valid, i.e. if the package really has a newer upstream version available. a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Package maintainers (e.g. me) are not interested in more Fedora bureaucracy nor in having to cope with yet another system (besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering organs (FPB, FESCO, FPC, Fedora committee de jour etc.). Nobody will be forced to use it and opting-out would be less work then writing this mail btw. But don't worry. In case there will be a consesus to make this opt-out, I will add you myself to the blacklist, so you won't be bothered. Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? I sense a miscommunication. As I understood your mail and [0], you are offering a service, maintainers can opt-in to use. Now you would like to make your service the default (== opt-out) and are asking for opinions. Did I misunderstand? No, but I did not understand A system _can_ only be made opt-out, if... Do you maybe mean should instead of can there? But there is also the restriction that the service will only be provided in cases where I do not expect bogus bug reports, so there may be still be packages that are not yet monitored. The opt-in/out mainly addresses of whether or not accurate bug reports should filed automatically. b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. I am not sure if this can ever be achieved, because there exist many varients of versioning schemes and because it's not uncommon for upstreams switch between several. If you have some ideas, which versions may cause problems, please provide some examples. Some classic cases: * 1.2pre .. pre release , 1.2 release, 1.2a bugfix a. * 1.2a .. 1.2a release, 1.2b 1.2b release. * 1.2pre .. pre release, 1.2. release, 1.2.1 successor of 1.2 * 1.2 ... latest release, 1.3 successor of 1.2 (GNU versioning) Above are all handled correctly now, it did not yet handle 1.2pre correctly, but this could be fixed with adding a questionmark to the regex, because I expected a number after the pre. * 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning, releases are using numerical versions, versions with suffix a,b,c... are prereleases) These are not handled correctly, i.e. from this list of versions it is not possible to determine the latest version. But since there won't be any new pre-releases after 1.2 was released, it would currently result in 1.2 being silently ignored if the system would have reported all other releases. If there is a way to only get the latest release using the regex, e.g. because upstream publishes something like the latest release
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, 2009-08-07 at 11:29 +0200, Till Maas wrote: Is there something like python-fedora to create notifications within the portal? I don't have an answer to the above question, but I do have an answer about the future. The eventual goal is to use a AMQP message bus to pass this kind of information around. We'd be able to run your service in the infrastructure, and it would just announce on the bus what info it finds. Consumers of the bus would do various things like A) file bugs in bugzilla, B) update information in fedora-hosted, C) whatever else somebody comes up with. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Jesse Keating (jkeat...@redhat.com) said: Ralf, this entire service is informational only. Maintainers don't need to do anything with this information, particularly if it isn't being filed as bugs and only provided on a webpage. They can simply ignore the information or even pretend that the website doesn't exist. The opt-out that Till is talking about is that by default, his service would manage every package it is capable of. A maintainer would have to opt-out of having their package monitored. But again, even if the package /is/ monitored, they don't have to do anything with that information. There is no bureaucracy here, just potentially useful information a maintainer can choose to look at or not. My concerns are twofold: - BZ seems the wrong place. It's the only push mechanism we have other than raw e-mail, though. - Not to generalize too much, but we have maintainers: - who maintain only a few packages Likely, these people are already plugged into their upstreams and don't need the extra notification. - who maintain a lot of packages (woo, 100 perl modules) These people are more likely to need it. Which of these groups do we want to optimize for by default? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 09:33:06PM +0200, Till Maas wrote: 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. It was decided on todays FeSCO meeting, that the service will stay to be opt-in. The full discussion is available at: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.log.html#l-296 Eventually, it will become possible to opt-in as a packager and not only with some package. Then for every package that the service can monitor, you will receive notifications. Regards Till pgp0K7NOYN5YE.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 10:56:10AM -0400, Bill Nottingham wrote: - BZ seems the wrong place. It's the only push mechanism we have other than raw e-mail, though. Pushing messages to maintainers is not the only necessary feature. The maintainers also need to be able to easily coordinate who will work on this or comment why this update won't take place or is delayed, e.g. because of bugs in other packages or missing dependencies. - Not to generalize too much, but we have maintainers: - who maintain only a few packages Likely, these people are already plugged into their upstreams and don't need the extra notification. Or they are not that well organised, that they may not notice upstream features. If the request was not declined, I was about to gather some statistics for the currently monitored packages, but this is moot now. - who maintain a lot of packages (woo, 100 perl modules) These people are more likely to need it. Or they have already their procedures to do this. Who knows? Nevertheless, both do not provide a public interace that can be consumed by other people than the package maintainers. Regards Till pgp9ldJmwDPv8.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Hiyas, currently upstream release monitoring[0] 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 be easily possible in the future to 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. Regards Till [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring pgpbOvtHTy8yY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
2009/8/7 Till Maas wrote: [..] 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. IMO, ideally it would be best to get new version information for all packages, but file bugs only against those maintainers who opt for it and keep the information available some place. Information about current_version - new_version_available will be helpful to package maintainers. [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Regards, Rakesh Pandit -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Till Maas wrote: Hiyas, currently upstream release monitoring[0] 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 be easily possible in the future to 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. Speaking just for myself, I'd be happy to have it automatic for my packages. But wow, who's going to key in all those regexps and keep it up to date? -eric Regards Till [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/06/2009 09:33 PM, Till Maas wrote: Hiyas, currently upstream release monitoring[0] 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. I'd prefer this system to be kept opt-in, because I think a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? 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. alarm bell ring/ Website? == yet more bureaucracy [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
