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.
> 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.
Further, you need to ask yourself about the power of the backend and its
options. What does it need to do with regard to embargoes and private
tickets? Who can aquire the "watchbugzilla" privilege? Is it available
only to Fedora Contributors? Does it take precedence over the "Only
visible to Fedora Project Contributors" flag in bugzilla? Is a different
mechanism used to decide who is permitted to see private data? Perhaps you
want multiple watchbugzilla options. One for Fedora Contributors, another
one for arbitrary users.
Also, if you worry about UI design. Consider somebody who maintains the
notification acls for a dozen [or more] packages. It sounds plausible that
such a person would like a UI where to display a complete list of all
approved privileges for all packages the person is in charge of. Else
you would need to query each pkg individually to find out whether maybe
you approved somebody as "observer" for one of your pkgs two years ago.
> (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.)
That's a matter of definition. You say watchbugzilla already overrides
bugzilla's group permissions ("Security Sensitive Bug" and "Fedora Project
Contributors"). Perhaps in the future embargoed scm commits become
possible. Then you don't want watchcommits to send them to arbitrary
subscribers.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
