Git migration - github vs code.gnucash.org

[Mike Evans]

On Wed, 31 Oct 2012 19:26:05 -0700
John Ralls <jralls at ceridwen.us> wrote:

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

This gets my vote.  Bugzilla is a far better tracking system than
Guthub, IMHO.

Mike Evans

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.