mailing list archives
Re: Notes from Sharkfest '13
From: Guy Harris <guy () alum mit edu>
Date: Thu, 20 Jun 2013 16:43:02 -0700
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.
- 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.
- 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?
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe