Slight change in how cvs notifications work

Toshio Kuratomi a.badger at gmail.com
Wed Jul 30 17:12:53 UTC 2008


Michael Schwendt wrote:
> 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.
> 
This doesn't answer my question of whether you and others want 
consolidation or not, though.  And it doesn't tell me what to do with 
the notification acls which are more problematic than the acls for 
things that actually allow you to do things.

>> 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.
> 
Not entirely.  There must always be at least one notification acl.  If 
you like consolidation, then you have to list at least that one acl.  If 
you dislike notification, then you should propose something with an 
expanded list of notification acls.

>> 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.
> 
Sure.  But backend feature design is driven by what the user wants in 
the front end.  I can implement either a single backend acl or multiple. 
  But it makes little sense for me to continue adding backend 
notification acls if you don't want to see them in the front-end.  And 
it makes it impossible for us to have multiple front-end acls if I code 
a single backend acl.  If you give me UI, then I can code the backend to 
enable it.  If you give me criteria for when to add new notification 
acls, I can code the backend to have acls that meet those criteria.

> 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
> 
Your example is too simple.  Whether there's one notification acl or 
five, it is still possible to have a "monitor this package" icon in 
bodhi.  The question is what you want such an icon to do.  Monitor all 
notifications to the package?  Monitor only changes in bodhi?  Monitor 
only comments on that particular build?  this is what I need to know in 
order to build a backend that supports it.

>> 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.
> 
Well, I can't work on the backend without knowing what people actually 
want to be able to do.  Tell me that and I can change the pkgdb to 
accommodate it or put it on the wishlist for when we have a message bus 
and notification service.

(Re: approving watchbugzilla: I asked a while ago to make watchbugzilla 
and watchcommits auto-approved but hadess objected because bugzilla can 
be used to file tickets that are under embargo, for instance, security 
related.  Therefore, the desire was to manually approve who was able to 
join this.  watchcommits,  OTOH, goes to a public mailing list already 
so I don't see any point in continuing to manually approve that.)


> 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.
> 
Yep.  I was excited whe Jesse first mentioned this at FUDCon and then 
asked for a server to work up a proof of concept on as it addresses that 
need very well.  It still needs to have a way to associate the user with 
the notifications they're interested in, though, so there still needs to 
be a backend store somewhere.

-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/20080730/d080546c/attachment.sig>


More information about the fedora-devel-list mailing list