Quoting Paolo Greppi (2017-01-05 15:40:16)
> On 05/01/2017 14:00, Pirate Praveen wrote:
> > On വ്യാഴം 05 ജനുവരി 2017 06:09 വൈകു, Ximin Luo wrote:
> >> This has nothing to do with tools, as Jonas mentioned it is about a
> >> continual time dedication to a FOSS project. Please try to understand this.
> > Yes, it has a lot to do with our tools. If we were using a git hosting
> > tool like gitlab or pagure, we could have reviewed pull requests before
> > we grant access to a new contributor.
> > You can't demand such dedication from a new contributor. Did you sign
> > What did you mean when you said they can use github.com? Isn't that
> > evidence of our lack of tools to bring new people to debian? Why should
> > I tell anyone to use a proprietary service to contribute to debian? This
> > is something we got to fix.
> When I read this, I became curious about who creates and contributes to repos
> shell access to git.d.o.
> guest accounts and 37 non-guest accounts. A recursive search on all contained
> files & subdirs yields a grand total of 33 guest accounts and 46 non-guest
> (apparently not many people push to repositories someone else had created).
> For those git repos we are using a setup that the git docs  advise for "a
> small outfit", but 79 seems more than "few developers" ... For larger teams
> they advise gitosis or gitolite; only the latter seems to be an active
> project and is packaged as gitolite3.
> My comments:
> - the tools we have are in line with rest of the debian tools (WOT, BTS ...):
> CLI, raw and based on trust
> - granting shell access to guests is consistent with that culture
> shot is a lot (+30%); also mass requests to join the team sound like
> spamming (but that's clearly not the case here !)
> - when I was a student at the uni a long time ago I remember we were
> willing to go a long way to please the professors **before** the exam
> - if gitolite were installed and configured on moszumanska (git.d.o.), it
> would probably be possible to set up access control on select repos for
> external "contributors"; "contributor" here is meant in a sense similar to
> "debian contributor" idea .
> In conclusion, Debian Contributor is a suitable status for a student
> who wants to give it a try during a seminar. If they pass the exam and
> **afterwards** out of their free will submit a request to join
Yes, statistics may show how many in this team currently collaborate how
much. And yes, Alioth provide us tools to separate our team in multiple
classes of members.
Do we want to maintain our current level of (lack of) collaboration?
Do we want multiple classes of users?
I want this team to be equal peers - one class with equal access rights.
I want this team to be for maintainers helping each other as time and
skills permit. If we should ever reject anyone, then only those who have
demonstrated *not* collaborating or *not* maintaining - we should never
refuse people based on fear that they will not do so in the future.
That's why I ask (but do not demand proof) if these concrete newcomers
are able and interested in not only releasing packages but also in
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private