First git based automated build

[John Ralls]

On Aug 12, 2012, at 1:59 PM, Geert Janssens <janssens-geert at 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