Git migration - github vs

Geert Janssens janssens-geert at
Thu Nov 1 06:15:07 EDT 2012

On 01-11-12 10:29, Christian Stimming wrote:
> Am Mittwoch, 31. Oktober 2012, 15:33:02 schrieb Geert Janssens:
>> This discussion has been had multiple times before and frankly I hope
>> this will be the last time.
> Yes.
>> - 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
>> 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 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
>> pulls periodically from this master repo to keep in sync.
> Yes, sounds good. The master repo would be this:
>> Only selected developers have commit access to the github repository.
>> This is all access control we need here.
> Yes. Where can this be managed? Is it this page (only for the currently four
> admins):
> Or rather this one:
> (I just tried adding some
> few people; the list is for sure not yet complete)
I would use the second option. Not every developer has to be admin per 
se. If a non-admin developer does have admin ambitions, I probably 
wouldn't object to giving these rights though if he/she has a proven 
track record and other admins agree.

Additionally, since we have 4 repos, we could different access rights 
for these if we want.  If someone only feels comfortable modifying the 
website, then there's no need to give him/her push access to the source 
code repo.

We don't have to do this really though. Git is distributed. So any 
goofup can be corrected from any of the cloned repositories. But we can 
if we'd prefer to.
> <snip>
>> 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.
> It doesn't have to be promoted, yes. The feature itself OTOH seems quite
> useful for me, so that inline comments can be inserted and then referenced
> from e-mail:
I see a risk here for semi-private conversations to spin off of this. 
Ideally these comments would immediatly mailed to gnucash-devel, but I 
haven't found a way to configure github like that. Instead github sends 
a mail to the author/committer (I'm not sure which, because I'm both in 
this case).

Someone manually has to forward this to the list.

But perhaps this is just me trying to get used to a more distributed 
development model...


More information about the gnucash-devel mailing list