Michael Schwendt wrote:
On Wed, 30 Jul 2008 15:28:56 -0700, Toshio Kuratomi wrote:Till Maas wrote:On Wed July 30 2008, Toshio Kuratomi wrote:Watchbugzilla is imho also interesting for people who only want to triage bugs that belong to one package, but are not interested in maintaining them. For testers watchbugzilla and -updates /-builds would be useful, but they may not be interested in the scm commits. For maintainers that maintain a pacakge that depends on another, the watch(updates,builds) can be enough that they need to know, because they may not care about bug reports for the package and cvs commits. Also upstream of a package might be interested to use watchbugzilla for the package in Fedora, but not in the other watch possibilities.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?So let me phrase this again:"Hi Toshio, I'd like to have a watch*acl for people to sign up to receive notices when their package doesn't have complete deps satisfied from within the repository."What criteria do I apply to this request to determine if I should create an acl for this request or tell them to use an existing acl?Hmmm? What "existing acl" would that be? Somebody asks you for a way to monitor broken deps reports. What communication "channel" are those reports posted through? Let's say, for Rawhide. To "package owners"? Is that equal to the list of e-mail addresses in bugzilla assigned to and Cc fields? Surely, when somebody wants to subscribe to a specific channel only, it must be an entirely new watch* acl. Or else you would want the person to subscribe to watchbugzilla in order to receive broken deps reports *and* lots of bugzilla mail. Broken deps can only be fixed by somebody with scm commit access. Mailing those people is one option. Is that possible already? I mean, not just with the new %{name}-owner addresses, but also for EPEL? Can the "commit" acl per pkg name be retrieved? But if such reports are sent to commits acl, it cannot be subscribed to. :) OTOH, it might be that the report is python-bugzilla'ed automatically, and in that case only the watchbugzilla people learn about the broken dep. It could also be that they are flooded with bugzilla spam, however, or that those with commit permission don't watchbugzilla. ;) Or it's a report about a broken dep because of a test update. In that case, a special QA monkey might want to stop the test update and give it -1 karma in bodhi and possibly take further action. A week later you're asked for a way to monitor "broken upgrade path" notifications and "bad pkg urls" reports. *Conclusively*, it sounds like a a new watch* acl is needed in such cases. It can be "on" by default for all package maintainers and be opt-in for other people.
To summarize, if I'm asked for a new watch* acl I should create it <period>. Is that correct? -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
