[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 08/07/2009 04:56 PM, Bill Nottingham wrote:
Jesse Keating (jkeating 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





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