[Members] git access

Matthew Wild mwild1 at gmail.com
Tue Jul 30 14:51:53 UTC 2013

On 30 July 2013 14:07, Kevin Smith <kevin at kismith.co.uk> wrote:
> On Tue, Jul 30, 2013 at 2:00 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> Currently most of our key information (XEPs, schemas, registries) is
>> under source in a git repository that lives on one of the XSF's
>> machines. (Ideally, our full website would be under source control.)
>> The question arises: what is the best policy for granting access to
>> the source control repository?
>> I would be comfortable with giving access to all XSF members, so that
>> more people could help with improving / fixing things.
>> I could understand if XSF members would prefer some other policy
>> (e.g., only XMPP Council members have commit access).
>> Please note that there is a difference between committing to the
>> source control repository and pushing changes to the website. For
>> example, even if we give XEP authors check-in privileges we still
>> wouldn't push Draft or Final specs to the website unless the Council
>> approves. Similarly, the XEP Editor role (which might be a team) might
>> need to review changes that have been submitted before updating an
>> Experimental XEP.
>> Your thoughts are welcome.
> How about we run Gerrit (a tool for managing Git repos), give all
> members (or other authors) the ability to make branches and submit
> reviews for trunk, and give Council and Editor(s) the ability to
> approve reviews?
> Then we get a list of outstanding reviews that any of the approvers
> can approve. Roughly speaking, a bit like GitHub without giving up
> control to a third-party (Let's not have that discussion again).

Call me old-fashioned, but I don't like tangling up our standards
process with (semi-)arbitrary third-party tools and methodologies.

I know we're all technical folk, and generally take delight in
answering all problems with technical solutions. However we do have a
tendency to complicate things, and that worries me.

But I'll stop waving my hands in the air here. I certainly won't be
against any solution if there is otherwise positive consensus around
it, and if I feel some of the practicalities have been considered

For example: who will run and maintain Gerrit? Where? The iteam hasn't
done an excellent job of keeping the tracker up, and even closing the
wiki was under consideration a while back. Athena is on its last legs,
and I wouldn't want to depend on it for fundamental XSF activity.

This also complicates the contribution process somewhat, and we
already have contributors unfamiliar with source control and git in
particular. Adding the requirement of understanding git branches
raises the bar for those people.

My 2p.


More information about the Members mailing list