On Tue, Mar 31, 2015 at 08:07:36AM +0100, Neil Williams wrote:
> On Tue, 31 Mar 2015 08:30:34 +0200
> Andreas Tille <andr...@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
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150331131717.ga16...@an3as.eu
