Re: Notes from Sharkfest '13

[Evan Huus <eapache () gmail com>]

On Thu, Jun 20, 2013 at 4:43 PM, Guy Harris <guy () alum mit edu> wrote:
> On Jun 20, 2013, at 2:17 PM, Gerald Combs <gerald () wireshark org> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe