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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
