Autoapprove watch* acls in the pkgdb

[Toshio Kuratomi]

Bastien Nocera wrote:
> Hey Toshio,
> 
> On Fri, 2007-10-26 at 09:51 -0700, Toshio Kuratomi wrote:
>> References: <200710261045.l9QAj8nt022071 at bastion.fedora.phx.redhat.com> <1193395741.25047.3.camel at cookie.hadess.net>
>> In-Reply-To: <1193395741.25047.3.camel at cookie.hadess.net>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> Bastien Nocera wrote:
>>> Heya,
>>>
>>> On Fri, 2007-10-26 at 03:45 -0700, Fedora PackageDB wrote:
>>>> Bastien Nocera (hadess) has requested the watchbugzilla acl on bluez-libs (Fedora devel)
>>>>
>>>> To make changes to this package see:
>>>>   https://admin.fedoraproject.org/pkgdb/packages/name/bluez-libs
>>> I'm sure this has been asked before. But why do I need to ask permission
>>> to watch a component in bugzilla?
>>>
>> It hasn't been asked before on the list but that's a piece of 
>> code/policy that I have on my list to fix[1]_.  No time like the present 
>> to get some feedback :-)
>>
>> Proposal:
>>
>> I'd like to have watchbugzilla and watchcommits (and any other watch* 
>> acls in the future) auto-approve.  By example:
>>
>> 1) Bastien goes to the bluez-libs webpage.
>> 2) Clicks the checkbox for watchbugzilla.
>> 3) Request is sent to the packagedb which immediately sets the acl.
>> 4) Bastien will immediately start being CC'd on all future bluez-libs bugs.
>>
>> Does anyone have problems with this piece?
> 
> The only problem I could see, is if the bugs filed are security
> bugs/sensitive bugs, people adding themselves on the CC: would basically
> get access to all those. Probably more a problem on the bugzilla-end
> though.
> 
> You'd have the same problem if you wanted to enable commits watch
> without approval.
> 
Hmm... So it sounds like autoapproval is a no-go until we can easily 
create embargoed branches.  Then the workflow would look like:

1) Maintainer is informed of a security issue.
2) Maintainer creates an embargoed branch for F-7, F-8, and devel
3) Maintainer adds necessary people to the acls of the embargoed branch(es).
4) Maintainer opens a bug for the issue against the embargoed branch.
5) Maintainer and others on the embargoed branch's acl commit fixes to 
the embargoed branch in the vcs.
6) When the release can be made, changes are merged from the embargoed 
vcs branch back to the release branches in the vcs, bug gets closed. 
Embargoed branch in the pkgdb and bugzilla component can remain but is 
inactive until the next issue.

-Toshio