[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Autoapprove watch* acls in the pkgdb



Bastien Nocera wrote:
Hey Toshio,

On Fri, 2007-10-26 at 09:51 -0700, Toshio Kuratomi wrote:
References: <200710261045 l9QAj8nt022071 bastion fedora phx redhat com> <1193395741 25047 3 camel cookie hadess net>
In-Reply-To: <1193395741 25047 3 camel 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]