On 03-11-12 15:57, John Ralls wrote:
On Nov 3, 2012, at 5:14 AM, Geert Janssens <[email protected]> wrote:
On 01-11-12 16:10, Derek Atkins wrote:
Geert Janssens <[email protected]> writes:
[snip]
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.
I would suggest that developers commit to code.gnucash.org, which can
then push to github.
I'd rather see it the other way. If developers commit to code.gnucash.org,
while all others fork from github you get a similar indirection like we have
now with svn. I don't like that. It's a source for all kinds of small errors
and sync irregularities. I have had to clean my local svn directory in git
countless times because if this. This is no doubt partly because git and svn
are two completely different systems, but I can envision small issues like this
also in a pure git environment. I clearly prefer github to be the repository
where all activity happens and code.gnucash.org a pristine canonical copy.
For non-committers, github is clearly the most interesting choice: it's higly
visible and a well-known brand. That's where we most easily will come in
contact with potential new contributors. I think we all agree we should
leverage that benefit. For me then as a committer, I would really find it more
easy if I only have to deal with one upstream repo in my daily activity instead
of two.
I already mentioned before that I may still have my brain clinging to the old
centralized development model of svn and may have some difficulty estimating
correctly how simple or complicated some constructs are in the distributed git
concept. But in my current understanding at least for me it's easier if I could
have github as my main upstream for all my day to day development work and only
when maintenance is needed on code.gnucash.org, work with that repo as upstream.
Why can't we set up commit hooks on each that immediately push to the other?
Yes, there's a small chance of a conflict if two people push changes of the
same file to each repository at the same moment, but the team is so small that
that likelihood is infinitesimal.
Otherwise, I don't see this as a big deal. Having multiple remotes in a local repo has
its uses. I maintain two repos for my gtk-osx projects, one on Github and one at
git.gnome.org. The latter is the "official" one, but it is indeed helpful to be
able to work with contributors on Github. Unless the change is truly trivial and
obviously correct, I don't use Github's merge facility on pull requests, I pull in the
patch and test it, then push it back to both repos. I also keep a personal Gnucash repo
on Github. It's useful for feature branches (which I rebase from time to time, be
warned!), giving me an offsite backup and anyone interested a look at what I'm up to.
Regards,
John Ralls
John,
From what I see you and Christian have the most experience with working
in git. So I'm tempted to follow your advice. The above is mostly my
opinion, but clearly limited due to a lack of experience.
So for now, the proposal stands as:
- github -> master repo for non-committers, highly visible, easily forked
- code.gnucash.org -> canonical repo, only used by the core developers
(anyone with commit access to current svn)
- a sync will be set up to push each commit in code directly to github.
All other details so far as described in the previous mails in this thread.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
