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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature