On Thu, Jun 20, 2013 at 4:43 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> 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.
Whether we go internal with Gerrit or hosted on Github, I sincerely
hope we'll only have one repository so this shouldn't be a problem
(thus why we didn't want to use subgit to synchronize between git and
svn).
> 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?
We can use pull requests (or gerrit reviews or etc) but still continue
using our existing bugzilla tracker, yes? I am also not a fan of
Github's bug tracker, and we don't have any deep svn/bugzilla
integration at the moment, so keeping bugzilla for the time being
shouldn't be a problem.
>> 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?
It would be nice to be able to build both at once, which doesn't
appear to be possible at the moment.
