Slight change in how cvs notifications work

[Michael Schwendt]

On Fri, 25 Jul 2008 13:43:19 -0700, Toshio Kuratomi wrote:

> Michael Schwendt wrote:
> > On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote:
> > 
> >> There is one major difference (besides speed) to note in this:  Before, 
> >> the owner and people in the watchcommits acls received notifications 
> >> that a cvs commit was made to a package.  Now the owner and people 
> >> onwatchcommits and watchbugzilla acls are notified.
> > 
> > So, the separate watchbugzilla now implies watchcommits? Why that change?
> > 
> Possibly oversight or possibly removing a wart.  Here was my reasoning:
> 
> We have a lot of things that want to send notification when a change 
> occurs to a package.  This includes:
> 
> bugzilla
> pkgdb (acl changes)
> cvs commits
> bodhi
> koji
> various reports:
>    broken deps, broken upgrade, fails to rebuild, etc
> 
> When the packageDB started I wasn't envisioning all of those uses and 
> the list of notifications is only growing over time.  So what should we 
> do?  We can add more watch* acls to the db and the interface.  Or we can 
> glom onto existing acls -- but if I want to get reports from bodhi, do I 
> need to sign up for watchcommits or watchbugzilla?  Or does it depend on 
> the commit acl?

Comments in bodhi are similar to comments in bugzilla and ought to be
delivered via watchbugzilla. Not everyone who gives negative karma
also opens a ticket in bugzilla.

New update notifications in bodhi are more like a commit [to a repo]
and therefore should be posted to watchcommits. Helpful for collaboration.

Koji notifications tell whether a package built successfully, which
is like a commit to the repo, and ought to be forwarded to watchcommits.

OTOH, if someone requests watchbugzilla access only, receiving all cvs
commits is unexpected. Especially as long as the watchcommits acl is a
separate opt-in. It's not called "watchpkg" unless you plan to take
your consolidation into that direction.

> Looking at this problem I didn't see any difference between bugzilla, 
> cvs, and bodhi, or koji.  So pruning the list of watch* acls with the 
> goal of consolidating on a single acl for notification seems to make sense.

Whether it makes sense depends on the original definition of the
several watch* options.

watchbugzilla as a fine-grained choice appeared helpful, because
bugzilla itself doesn't offer such a feature (monitoring other email
addresses increases the spam). watchbugzilla is different. It's like
"I depend on Foo, so I want to learn about bug reports regarding
Foo". Instead, you want to submit also all cvs commits, which quickly
increases the email traffic an observer has to process (minor updates,
cosmetical spec changes, commits with no immediate build). This gives
reason to worry. Maintainers are said to be flooded with bugzilla spam
already. With a change of the pkgdb watch* acls, co-maintainers could
not opt-out from some of the notifications (only with filtering on
their own).