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

Re: Slight change in how cvs notifications work

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:

pkgdb (acl changes)
cvs commits
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


Active Releases: F-8 F-9 devel

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

[view advanced]

= Advanced View =

Package: qa-assistant



    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
[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.


Attachment: signature.asc
Description: OpenPGP digital signature

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