Slight change in how cvs notifications work

[Michael Schwendt]

On Wed, 30 Jul 2008 08:04:36 -0700, Toshio Kuratomi wrote:

> > Simple co-maintenance

> I notice that you only have the active privileges listed here. 

Because it only described the much simplified model, which recent
consolidation seems to have as a goal.

> The 
> passive privileges (being notified of changes in an area) need to be 
> available as well so that upstreams, users, and other people who are not 
> Fedora packagers can be aware of what's going on with packages.

That's the less simple design with fine-grained options for the various
types of notifications, so e.g. "watchbugzilla" and "watchcommits"
are distinct from eachother.

> I would love a better designed UI and better designed acls.  So please, 
> give me a design to implement instead of merely criticising what's 
> there.  Don't take me wrong, I love that you're criticising it because 
> it's horrible.  But without a notion of what the better system looks 
> like we're never going to replace what we have.
> 
> -Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi

I'm not talking UI design yet, as that can only follow backend feature
design.

Whether the user may need to mark checkboxes or move items from one
listbox to another and vice versa, is still unimportant. Imagine users in
bodhi could click a "monitor this package" icon and confirm subscription
with their credentials. Only if that's possible in the backend software,
you can start worrying about the UI. I can't either comment on UI
proposals like

> Acls:
>      Req  Apprv
>      [X]  [X] watch commits
>      [X]  [_] watch bugzilla
>      [X]  [X] watch updates

> Approval Queue:
> 
> abadger requests
> qa-assistant
> [X] watch bugzilla

without any background on why pkg maintainers must approve such monitoring
requests at all. Bugzilla is world-readable except for tickets with
special flags (e.g. only visible to Fedora Contributors). Same for cvs,
unless mechanisms are in place which hide branches in embargo
situations. Approval of requests for access to non-public data (or
write-privileges) is something else, of course.

Jesse mentioned work on a "common message bus" and a "messaging server",
which is something in the area of the notification queueing server
proposed long ago, but more versatile.