Michael Schwendt wrote:
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.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, etcWhen 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.
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.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.
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)
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.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).
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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
