Git migration - github vs code.gnucash.org

Geert Janssens janssens-geert at telenet.be
Wed Oct 31 10:33:02 EDT 2012


This discussion has been had multiple times before and frankly I hope 
this will be the last time.

The previous discussion didn't end in an explicit consensus, but I think 
we were close to finding a compromise at least. A summary:

- Nobody opposed to using github. In fact most developers are in favour 
of using it.
- John indicated that github is good, but we shouldn't use the github 
issue tracker or pull requests. They appear to be a source of trouble.
- Mostly Derek insists on having a canonical repository on 
code.gnucash.org as well. Others haven't explicitly agreed or disagreed 
on this.
- Yawar proposed to have the main activity run on github, and pull 
periodically to code.gnucash.org. The latter can be considered canonical.

Let's continue to build on this. I propose this setup:

One master repo hosted on github. One canonical repo on code.gnucash.org 
pulls periodically from this master repo to keep in sync.

Only selected developers have commit access to the github repository. 
This is all access control we need here.

All others that wish to contribute have to fork/clone this repository 
and send in patches.

It looks like we better don't use github's issue tracker and pull 
request mechanisms. John stated this explicitly on the previous 
discussion, but there is criticism on these tools also in other (large) 
projects. Instead we continue to use our own contribution process, 
being: patches have to be sent to bugzilla or the mailing list (the 
latter has a higher risk of getting lost). Issues should be tracked in 
bugzilla. Ideas and requests could be tracked in either bugzilla or 
uservoice.

There is also a feature on github to annotate patches (write inline 
comments). I don't know it's advantages or drawbacks, but given the 
opinion on pull requests and issue tracker, it's probably safe to not 
promote the annotation tool so far. Instead discussion of patches 
continues on the mailing lists as is now.

I have not really decided yet how to handle access control to the 
canonical repository on code.gnucash.org yet. In principle nobody needs 
to push anything to this repo. It should simply fully automatically pull 
from the github master repo. But just in case for maintenance or other 
situations, I think it makes sense to allow push access by the same 
developers that currently can commit to svn on code.gnucash.org.

I have deliberately skipped implementation details in this mail (how to 
enforce access control, how to trigger push/pull requests,...). I first 
would like to come to a consensus on the concept. Then work out the details.

So any issues with this proposal ? (If so, please use bugzilla, not the 
github issue tracker ;p ). Or if you agree, please state so as well, so 
we can get an idea if we can pursue this proposal or not.

Geert


More information about the gnucash-devel mailing list