Slight change in how cvs notifications work

[Michael Schwendt]

On Wed, 30 Jul 2008 15:28:56 -0700, Toshio Kuratomi wrote:

> Till Maas wrote:
> > On Wed July 30 2008, Toshio Kuratomi wrote:
> > 
> >> What is the criteria for having a watch* acl?  Should everything that
> >> can send a notification have a separate acl?  Should automated reports
> >> like broken deps and fails to rebuild from source?  If there's a line,
> >> what are the criteria for determining which things fall to one side of
> >> the line or the other?  Phrased more specifically, why do you want to
> >> have watchbugzilla, watchupdates, watchcommits, watchbuilds?  What makes
> >> those four different from other watch* acls?
> > 
> > Watchbugzilla is imho also interesting for people who only want to triage bugs 
> > that belong to one package, but are not interested in maintaining them. For 
> > testers watchbugzilla and -updates /-builds would be useful, but they may not 
> > be interested in the scm commits. For maintainers that maintain a pacakge 
> > that depends on another, the watch(updates,builds) can be enough that they 
> > need to know, because they may not care about bug reports for the package and 
> > cvs commits. Also upstream of a package might be interested to use 
> > watchbugzilla for the package in Fedora, but not in the other watch 
> > possibilities.
> > 
> So let me phrase this again:
> 
> "Hi Toshio, I'd like to have a watch*acl for people to sign up to 
> receive notices when their package doesn't have complete deps satisfied 
> from within the repository."
> 
> What criteria do I apply to this request to determine if I should create 
> an acl for this request or tell them to use an existing acl?

Hmmm? What "existing acl" would that be? Somebody asks you for a way to
monitor broken deps reports. What communication "channel" are those
reports posted through? Let's say, for Rawhide. To "package owners"? Is
that equal to the list of e-mail addresses in bugzilla assigned to and Cc
fields?

Surely, when somebody wants to subscribe to a specific channel only,
it must be an entirely new watch* acl. Or else you would want the
person to subscribe to watchbugzilla in order to receive broken deps
reports *and* lots of bugzilla mail.

Broken deps can only be fixed by somebody with scm commit access.
Mailing those people is one option. Is that possible already?
I mean, not just with the new %{name}-owner addresses, but also for
EPEL? Can the "commit" acl per pkg name be retrieved?
But if such reports are sent to commits acl, it cannot be
subscribed to. :)

OTOH, it might be that the report is python-bugzilla'ed automatically, and
in that case only the watchbugzilla people learn about the broken dep.
It could also be that they are flooded with bugzilla spam, however,
or that those with commit permission don't watchbugzilla. ;)

Or it's a report about a broken dep because of a test update. In that
case, a special QA monkey might want to stop the test update and give
it -1 karma in bodhi and possibly take further action.

A week later you're asked for a way to monitor "broken upgrade path"
notifications and "bad pkg urls" reports.

*Conclusively*, it sounds like a a new watch* acl is needed in such
cases. It can be "on" by default for all package maintainers and
be opt-in for other people.