[Kde-scm-interest] the permissions confusion

[Jeff Mitchell]

On 12/12/2009 3:04 PM, Oswald Buddenhagen wrote:
> On Sat, Dec 12, 2009 at 02:46:46PM -0500, Jeff Mitchell wrote:
>> On 12/12/2009 1:48 PM, Oswald Buddenhagen wrote:
>>> On Sat, Dec 12, 2009 at 07:12:13PM +0100, Thomas Zander wrote:
>>>> On Saturday 12. December 2009 19.02.14 Oswald Buddenhagen wrote:
>>>>> Whoopsie! Looks like this project has chosen to restrict commit
>>>>> access.
>>>>>
>>>> Then it would not be a kde-developers project.
>>>>
>>> well, actually, most likely it would. the hook would allow
>>> foo-developers through without a question, while kde-developers
>>> would get the blurb. after all, the restricted group still needs the
>>> ability to force a push, and kde-developers is just perfect for
>>> that.
>>
>> But why? I honestly don't understand it. Why, if the fix needs to go
>> in, couldn't the kde-developer person simply submit a merge request to
>> foo-developers? Isn't that kind of the point?
>>
> the concept simply has to have a "backdoor", otherwise there is no way
> it would be accepted by the kde community.

Heh, it's not often you see people that are describing backdoors as good
things.

> heck, i myself would refuse
> it otherwise. after all, the ability to quickly fix compilation (and not
> have everyone do the same until a maintainer does it) is one of the "key
> features" of the "kde way" of handling the repository.

But but but...which repositories are these that you're talking about
which are both restricted *and* essential to compilation?

We're talking about keeping things the "kde way" which means
+kde-developers has access to everything. Only a few things are
currently restricted, like www -- but that's not essential to
compilation, and indeed I'm sure it's a matter of normal policy that you
check the site after you commit to it.

So exactly where does one need these backdoors, how is it a "key
feature" to have such a backdoor, what are real use-case examples where
we might hit something super time-critical if there are no such
backdoors, and why isn't it enough to have a responsive kde-sysadmin
team (which could be a larger team than those that have access to e.g.
our servers) that can grant temporary exemptions to these normally
restricted repositories?

> we have that problem only for acl-protected areas, which are a few.
> i'm proposing a "soft acl" to be able to have more acls without
> disturbing legitimate exceptional workflows too much.

Where is this needed?

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091212/a0dfb5a7/attachment-0001.sig