Re: git dangerous operations on alioth
-----BEGIN PGP SIGNED MESSAGE-----
On 28/02/13 20:20, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2013-02-28 19:20:09)
>> On 28/02/13 13:15, Simon McVittie wrote:
>>> On 28/02/13 09:39, Daniel Pocock wrote:
>>>> Has anybody had experience controlling access to git
>>>> repositories, for example, to give users access but prevent
>>>> some of the following dangerous operations?
>>> If you look at it from the appropriate angle, the combination
>>> of ftp.d.o and snapshot.d.o (particularly source packages) is a
>>> big, inefficient VCS, with a rather wider user-base than Alioth
>>> - what the maintainer says the git history of package "foo" is
>>> seems relatively unimportant when compared with what its upload
>>> history looks like. All DDs have the ability to "commit"
>>> wide-ranging changes to that "VCS", and we mostly regulate that
>>> by social conventions for what can and can't be in an NMU or a
>>> "team upload", discouraging hostile NMUs and hijacking, etc.,
>>> rather than by applying chmod.
>> DD access is also an `all or nothing' scenario, and it is tightly
>> controlled in other ways.
>> What I was anticipating is how we can provide more access for
>> upstreams and other non-DDs using the guest account mechanism or
>> potentially some kind of non-UNIX level access
>> To give one example, one of my packages fails to build with clang
>> due to some other header file in package foo. Somebody actually
>> uploaded a fix for foo onto mentors long before the freeze, but
>> it got no further. It leaves me feeling that the DD community
>> could benefit from more automated ways to ramp up new members and
>> accept their contributions, but that would also mean taking the
>> sharp edges off some things.
> Well, to me a contribution "left at our doorstep", e.g. by
> uploading to mentors.debian.net, haven't really reached Debian yet:
> Someone (called a mentor) needs to take it the rest of the way.
> Concretely a mentor might have shown the contributor how to get in
> touch with you - either through the BTS or maybe (if your package
> permits that) by injecting the suggested code changes directly into
> the VCS of your package maintenance.
> I am in favor of making it easier to contribute, but maintainer
> teams may have sane reasons for e.g. wanting to talk to new
> contributors before letting them mess directly with their local
I wasn't suggesting that there would be some kind of shortcut or
bypassing all human contact with new contributors, just that there may
be opportunities to streamline the process
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----