[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 is: 1.2b" and the tarball contains the version as a verbatim
string, then the CVS lookup will prevent the system to file bogus
reports afaics. E.g. rpm NVR is foo-1.2-0.1.b.fc12 and upstream tarball
is foo-1.2b.tar.gz, there is no problem currenlty.

> * 1.18, 1.1901, 1.1902, 1.20 (Perl versioning ... X.20 > X.1900 !)

This causes problems, too. How are these mapped to rpm NVRs? Here the
script will currently report 1.20 as beeing the latest. If it was
already reported once, it won't be reported, but for the remaining
actions I need to know how the rpm would look like.

> * Frequent builds using the same version (replacing the same tarball),  

This will currently result in silent ignorance, so no bogus bug reports.

> e.g. daily snapshots.

This depends on how the snapshot is created. If it is done by upstream
and included in the reported upstream version, there should be no
problem.

> Now imagine upstreams switching between these .. No idea, how you would  
> want to handle this.

If the system ran long enough, the main problem will be ignored upstream
releases, because it won't report the same upstream version twice. But
the question is also how often this will happen in reality.

>>> 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.

Imho it is already helpful if only a subset of packages are checked.
It would be enough for the service to notice that something is wrong and
require manual intervention. But this is a problem that also a package
maintainer has, that wants to check manually whether or not there are
new releases.

>>>> 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".

Up until now I felt like I undertood you, because as I understand you
here, you are agains anything being opt-out, even if the majority of
package maintainers would use the service?

Regards
Till

Attachment: pgplXtz2wYgLy.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]