Slight change in how cvs notifications work

[Toshio Kuratomi]

Michael Schwendt wrote:
> On Wed, 30 Jul 2008 10:12:53 -0700, Toshio Kuratomi wrote:
> 
>> This doesn't answer my question of whether you and others want 
>> consolidation or not, though.
> 
> I did answer that in my 2nd reply in this thread. I can only speak for
> myself, though, but I have doubts that others prefer a single "watchpkg"
> option to receive *all* sorts of notifications. Client-side filtering as
> the only way to opt-out from some of the messages always bears a risk.
> 
> In addition to "watchcommits" and "watchbugzilla", the following two would
> make sense: "watchbuilds" and "watchupdates". So far, co-maintainers need
> to create/forward such messages manually.
> 
> I understand that someone may like to subscribe to "watchcommits" and
> unsubscribe from "watchbugzilla", and vice versa.
> 
>> backend feature design is driven by what the user wants in 
>> the front end.
> 
> Make that  "backend feature design is driven by what features
> the user wants"  and I agree. ;)
> 
> Talking about the actual look'n'feel of a web UI is something
> entirely different.
> 
>>  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.
> 
> ?? They are available in the front-end, but you've chosen to
> redefine "watchbugzilla" as it now implies "watchcommits".
> 
I'm talking about whether to get rid of the distinction throughout the 
code or not.  I have had requests to streamline the UI for just having 
two roles: Package Watcher and Package Maintainer.  So I need input on 
whether that's the end-all-be-all.  Is this the only real use case (in 
which case, why should I implement more acls in the backend; they're 
always going to be hidden in the front end) or just the optimized use 
case (For which I posted a straw man with multiple acls available for 
those that want them.)

>> 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.
> 
> Well, sure, you need to find such a feature useful before you want to work
> on it. Or you implement what your manager tells you or if you see the
> demand. You could add a clickable button or icon to bodhi and koji and even
> bugzilla, and it could point the user to the central place (e.g. the
> pgkdb) where to maintain settings related to notifications. Or it would be
> a shortcut to subscribe to a specific type of notification, e.g. "Monitor
> updates to this package" in bodhi, "Monitor builds of this package" in
> koji, "Monitor comments about this package" in bugzilla, and so on.
> 
Exactly.

>> Well, I can't work on the backend without knowing what people actually 
>> want to be able to do. 
> 
> If you want to foster co-maintainership, it should become possible for
> co-maintainers to monitor every detail related to maintaining and
> publishing a package. I would consider a fine-grained choice of what
> messages to receive superior than a single "get everything" option.
> 
So do you like my straw man or not?  If so, I still need to know:

What is the criteria for having a watch* acl?  Should everything that 
can send a notification have a separate acl?  Should automated reports 
like broken deps and fails to rebuild from source?  If there's a line, 
what are the criteria for determining which things fall to one side of 
the line or the other?  Phrased more specifically, why do you want to 
have watchbugzilla, watchupdates, watchcommits, watchbuilds?  What makes 
those four different from other watch* 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/20080730/dcfaf99a/attachment.sig>