Michael Schwendt wrote:
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.)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".
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
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
