On Aug 12, 2012, at 1:59 PM, Geert Janssens <janssens-ge...@telenet.be> wrote:

> Just FYI,
> 
> I ran the modified daily_build_git.sh on the build server (and directly from 
> the cloned git repo as well instead of using a separate packaging directory).
> 
> The build was successfully built and uploaded. So that's one step closer to 
> git migration.
> 
> I think we should now come to an agreement on where we want to host the 
> master repository. Fixing the remaining hooks and scripts depends on this 
> choice.
> 
> Can someone come up with a summary of the advantages and drawbacks of both 
> options:
> - hosting on code.gnucash.org
> - hosting on github
> - or even an alternative git hosting provider
> I don't have enough experience with git hosting providers to really do this.


Are there any commit hooks that we can't do without? If so, we'll need to 
translate them and figure out how (and if) to make them work on the selected 
hosting provider.

It's on Github now, so there's some benefit to keeping it there. There are a 
few downsides:
* People will want to submit pull requests instead of submitting patches via 
bugzilla
* People will want to interact with us by sticking inline comments on change 
sets.
* We'll have to work something out with Trac, or just browse via Github. Trac 
is nicer IMO.

Another obvious alternative is Sourceforge, since that's where we already host 
downloads. They're in a bit of a migration right now -- they're getting rid of 
hosted applications (which in our case would mean trac) in favor of having 
projects run those applications in a virtual server of some sort -- but that's 
supposed to be fixed by the end of the year. We'll be able to put Trac there 
for browsing (ViewCVS doesn't work very well with git IMO) once that's sorted 
out. 

We could also go to Gnome.org, where we already use Bugzilla. We'd have to 
grovel a bit, and it takes time to get approved, but it's doable. Browsing 
would be with their version of CGit, which isn't too awful. The big issue there 
is that there's no compartmentation of push privileges. All committers can push 
to any repo. I guess the theory is that anything stupid or malicious can be 
quickly reverted, and repeat offenders can be ejected.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to