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
Attachment:
pgpnGTABYVRk6.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
