octave-maintainers
[Top][All Lists]
Advanced

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

Re: Giving all OF members ability to manipulate bugs in Savannah


From: Olaf Till
Subject: Re: Giving all OF members ability to manipulate bugs in Savannah
Date: Wed, 31 Jul 2013 19:06:01 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jul 31, 2013 at 11:35:44AM -0400, Jordi Gutiérrez Hermoso wrote:
> I'd like to give everyone who is actively maintaining an OF package
> the ability to manipulate bugs in Savannah. jwe's argument against it
> is that we can't enforce permission boundaries and let them manipulate
> bugs but not push to the hg repo. To this I counter two things: should
> someone actually start pushing to core things that we don't like,
> well, (1) it's easy to undo and take away that access and (2) why
> would we trust someone to manipulate bugs but not our code?

Wasn't the original intent to give OF developers access to manipulate
bugs only of OF-package category, not the other bugs?

And regarding the implied access to the hg repo, where will it be
noted who has "real" access and who has only "formal" access to the
repo? What if a person should be switched from formal to real access
--- will this done by an informal note to that person only? I'd guess
in this case this is more unlikely to happen since the responsibles
might not see the need --- what they see is that the person has access
and maybe not whether it is only formal.

> It might be "nice" to actually patch Savannah so that it can enforce
> fine-tuned permissions, but really, locks are kind of anti-GNU to
> begin with, and we should all just behave like a doorless and lockless
> hippie commune. :-)

It is against reason to want the access to be restricted but to not
implement it. The argumentation with the "doorless commune" or similar
is not applicable here, since you do want the access to be restricted,
you only don't want to enforce it by the implementation but by kind of
reviewing the pushes afterwards.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]