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

Attachment: signature.asc
Description: OpenPGP digital signature


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