Till Maas wrote:
On Wed July 30 2008, Toshio Kuratomi wrote: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?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.
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?
Description: OpenPGP digital signature