Slight change in how cvs notifications work

[Toshio Kuratomi]

Michael Schwendt wrote:
> 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.
> 
The answer to: "What acl do I need to know what's going on with this 
package's updates" becomes "watchcommits and watchbugzilla" which is 
decidedly confusing.

> 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.
> 
So this is kinda the question I'm asking... do people here think taking 
things in the direction of a single watchpkg makes sense?  If so, that's 
the next step in this... merging watchbugzilla and watchcommits into a 
single watchpkg acl.

OTOH, if there is significant value in having separate notification acls 
then I think we need to have separate acls for most everything.  (A side 
note: I don't think we can control koji, unfortunately.  I think it uses 
its own idea of pkg owners coupled with who submitted a build to send 
out notification)

>> 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).
> 
This makes sense.  Now, how do we make this general?  For instance, if 
we're worried about the level of bugzilla mail, adding bodhi comments to 
the watchbugzilla acl becomes less attractive.  Also the names don't 
imply anything about what other things will be attached to the acl... we 
should either rename the acl to encompass those things or split out 
separate acls for them.

After we solve the criteria issue, we have to solve the UI issue: 
making more acls makes the current UI more and more cluttered.  I've 
been thinking that we want to have a single button for most things.  If 
you're not yet a maintainer of the package you see this:

= Simple view =

Package: qa-assistant

_/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______

Active Releases: F-8 F-9 devel

Role:
(o) Just Watch Package
(_) Help Develop Package
(_) Full Co-Maintainership

[view advanced]

= Advanced View =

Package: qa-assistant

_/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______

_/*F-8*\_F-9_\_devel_\_________

Acls:
     Req  Apprv
     [X]  [X] watch commits
     [X]  [_] watch bugzilla
     [X]  [X] watch updates
     [_]  [_] Commit
     [_]  [_] Update
     [_]  [_] Approve Acl Requests

[simple view]

Maintainers would see something similar to the current view but they 
will also have a simple approval queue (from the /users/ space) (Note, 
this needs more work):

Approval Queue:

abadger requests
qa-assistant
[X] watch bugzilla
[X] commit
[X] update
[ ] approve acl requests

[Approve Request]
[Deny Request]
[...]

[Approve all Requests]

I've got to get together with a UI designer to work out whether I'm on 
the right track but something like this will definitely be needed if we 
keep adding acls.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080726/bac42d15/attachment.sig>