Git migration - github vs code.gnucash.org

John Ralls jralls at ceridwen.us
Wed Oct 31 22:26:05 EDT 2012


On Oct 31, 2012, at 7:33 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> 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.

Sounds good to me.

Regards,
John Ralls




More information about the gnucash-devel mailing list