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

Re: git dangerous operations on alioth

Hash: SHA256

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
> infrastructure.

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
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: