On Jun 20, 2013, at 2:17 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
> Git (cue ominous music). I managed to install SubGit (a bidirectional
> Git ↔ SVN gateway) a few months ago. It seems very nice but I wasn't
> crazy about the idea of managing our current repository count times two.
> I think we should just switch over to Git in the near term but I'd like
> to hear everyone's opinion on this. If you would be severly impacted by
> moving to Git please respond to the list or let me know privately.
> Otherwise I'll start planning the switch for later this summer.
>
> Moving to Github. Assuming we switch to Git it would be possible to host
> the official repository at Github.
>
> Advantates:
> - I'm not sure that an in-house equivalent (e.g. Gerrit plus a
> private repository) would be better than what Github offers.
> - It would be less for me to worry about / manage.
>
> Disadvantages:
> - This would mean transitioning to an different workflow.
So we could just clone the Github repository, do work in the clone, commit, and push to the Github repository, right?
libpcap and tcpdump currently have both an in-house repository and a Github repository, and that's a pain; I do my development work on a clone of the in-house repository, and push to that repository, and I'm not sure whether the changes then get pushed to the Github repository or not. Bug fixes are often submitted as pull requests on Github, and get pulled using the Github Web site, and those then have to get merged into the in-house repository.
That also raises the question of people submitting patches as pull requests - I'm not entirely happy with Github's bug-tracking mechanism (and moving Bugzilla to it might lose all sorts of information - I migrated libpcap's and tcpdump's SourceForge bug databases to Github, which means I ended up as the submitter of almost all the libpcap and tcpdump bugs), so I'm not sure I'd go with it as a Bugzilla replacement. What to do then about pull requests?
> Qt. We need to coordinate work (e.g. so that we don't inadvertently
> interfere with Thomas' GSoC effort). It would be helpful if autofoo
> supported both GTK+ and Qt builds (I think Jeff is looking into this).
It works for me on OS X Mountain Lion, at least; what's *not* working?
