-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRL8DGAAoJEOm1uwJp1aqDOkoP/iZZY1YczvllO8pzcNFsaeAy 7GjbS/MK9/Vm9rEOjaiaBdwa3fO9TCTYvWkeXIfwoQAw5mLd32kh0gbg+E3rqQah NMkK+7N3h5FIUEF4+KeP8uyhcjuZBe4ig4TYdwlgaxsS8L0f8Rdd1vrtBNvCrWMD 0E8VqXq7VTQeOhXiGPHK97qUVbuGGXc+b8a6Yjah7yzQtHfC/Va3PHEJg2zgtb7L 74m9Tec0oCJxa6EdCPS2u/Rws7kHhizf+j3/HcxeOGVzHYXBZO9cj3lnd9vdrquP bUarFFj/EomOwnbHwu42XA83r8CKHD1FnCYvsuNQphz1N7koZSI2P7vgd0xy9imS tPQevbwsSppYUH6zS52mINFbBmNFh7bJqIl3tK9PlwBBLIXJjgdZH8/8tSrR0fRL DiXDlzb1sNEQz0LRtuh9h1Mp4ZlSkp7NdmJ7zc7ZF8OfDvrdZzO4aHRFsSZc0j0B xoqDViC2WgpX9qjL2i0c63RXSLT4Fd7FWRY1+EsedW/Zg8CJ27W+T/Wsd9Y3pHX0 mj7yV9R1quTaIIhp6VWxo8pmKCEkW+0Qx7216IL4gMV6z3Em0F5p6c/yVrh9acop 4GXKuDexYO0ah42mg/rFLkmmGdFF9FMMVx7Rq4jAfApUmLp9jXxckr1lzD0LVGxI N5uG4v+YCzkM32Mny1jB =oHiH -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512fc0c6.50...@pocock.com.au
