Make upstream release monitoring (the service formerly known as FEVer) opt-out?

[Ralf Corsepius]

On 08/07/2009 04:56 PM, Bill Nottingham wrote:
> Jesse Keating (jkeating at 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.
Well, I doubt this.

My concerns are about
* getting flooded and swamped with false "update alerts" and the 
administrational overhead related to "fix them".

* the technology being applied. I am having doubts Till's approach 
(regex's) is sufficient.

* I am also "burnt" by negative experiences when other comparable 
systems had been introduced to Fedora, such as bodhi, koji and the 
packagedb - They all cause additional overhead and so far all have seen 
close to zero effort to improve the situation.

Conversely, the situation is gradually worsening.

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

ACK, for these folks such Till's service is not of much use.

>    - who maintain a lot of packages (woo, 100 perl modules)
>    These people are more likely to need it.
Being one of these, I can't avoid telling you Till's service also
is not of much use, because esp. Perl has other communication channels 
to notify people about updates (CPAN) -- Otherwise it would not have 
been possible to maintain them.

That said, Till's system has few benefits - It's essentially "just yet 
another" system.

>    Which of these groups do we want to optimize for by default?
IMO, Till's service is suitable for "occasional packagers" who package 
few "non-essential/minor" packages with infrequent releases (Packages 
with "zero traffic" mailing lists; packages, maintainers forget about to 
check for updates).

However, it's exactly this family of packages, who suffer from the 
technical issues Till's system is likely not able to cope with.


Ralf