On 08/07/2009 04:56 PM, Bill Nottingham wrote:
Jesse Keating (jkeating@xxxxxxxxxx) 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
