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

Re: Changing the ACL policy for alioth projects (Was: Unable to push debian-jr changes)

On Tue, Mar 31, 2015 at 08:07:36AM +0100, Neil Williams wrote:
> On Tue, 31 Mar 2015 08:30:34 +0200
> Andreas Tille <andreas@an3as.eu> wrote:
> > Hi,
> > 
> > since I have cared for ACLs set on all projects I have admin
> > permissions I always (obviously wrongly - see[1]) assume that people
> > do so as well in their projects.  I experienced the same issue
> > yesterday in pkg-openstack: The fact that there is a way to grant
> > commit permissions to any DD to VCSs on alioth is widely unknown even
> > if it is mentioned in the Alioth FAQ[2].
> > 
> > I hereby like to propose that the default on Alioth will be that ACLs
> > are set to grant write permissions for DDs *by default* and project
> Isn't that exactly why we have collab-maint?

To my understanding not.

> If a repository is not
> part of collab-maint, that is because only the relevant team should
> have write permissions on that repo.

That means you question the sense of ACLs for DDs in general?

> > admins need to ask admins to revert this if they have good reasons to
> > prevent any DD from writing to their VCS.
> > 
> > Any opinions?
> I don't want have write permissions on every project on Alioths

If you do not want it feel free to ignore the option.

> and I
> don't see that others need write permissions to repos not in
> collab-maint. Submit a bug and a patch, just like everyone else.

I have no idea what everyone else is doing.  I simply know that it
happens from time to time that a quick commit to a repository is way
less effort than a detour via BTS and that it is common practice in some
teams I know.  It definitely helps if a DD did an NMU and commits the
changes to the relevant VCS.  This is not only kind for the maintaining
team this sometimes even helps a lot for inactive teams.

It also offered the option of some mass changes when debian/upstream
files in Debian Med and Debian Science where renamed into
debian/upstream/metadata files.  There was no need to add a new team
member who only wanted to do this change without doing some 200+x mass
bug filing which would have created *lots* of work for everybody.

If you need more examples for use cases of an option you are free
to ignore I can happily provide them.

Thanks for considering



Reply to: