Talk:Migrating Nmap to Git

On moving to git, in general terms

Git is nice, but what benefits would migrating bring and what would we give-up as a result? In particular, I'd love to see Fyodor and David weigh in on what it currently takes to prepare a release and what improvements they'd like to see. Also, what model of development would be best (for the people who have to merge): single branch, twin branch (e.g. master and develop) or git-flow? Jah (talk) 23:27, 6 December 2013 (UTC)

Pros

• Releases can be tagged because branching is cheap (I think that the expense of branching in SVN is the reason releases aren't tagged). This means that it would be very easy to build a specific release from the past which could help in various ways like:-
  • being able to build an old release for a platform that is no longer supported
  • testing an old version when someone complains that "Nmap version N works fine, but the some number of later versions don't"
• The likelihood of more scripts and new features because of the ease of making a pull request from a fork (relative to the existing SVN workflow)

Cons

• It's going to take a lot of work to migrate. :/

On Hosting

In my opinion, Nmap-hosting would be preferable to third-party hosting: I trust Fyodor et al much more than I trust any third-party and I very much like that Fyodor et al maintain ultimate control over the project. Jah (talk) 23:27, 6 December 2013 (UTC)

On Migrating

• Can we agree on a firm commitment to preserve all of the commit info currently available in SVN? Jah (talk) 23:27, 6 December 2013 (UTC)
  • I think this is laudable, and possible for the most part. However, I think there were some changes in the past that would make this difficult. Certainly, git-svn cannot handle all the changes to the beginning of the project. There may be some other way to archive the SVN history, though. Bonsaiviking (talk) 04:34, 7 December 2013 (UTC)

On Bug Tracking

• Would using a bug tracker be necessary because otherwise there'd be two places to keep track of development discussions: the mailing list and pull requests? What then would the dev@nmap list be used for? Jah (talk) 23:27, 6 December 2013 (UTC)
  • Mailing list would be for general discussion. Certainly there would still be bugs reported there, since old versions direct users there. "Pull requests" is kind of a Github-specific thing; not all bug trackers are so tightly linked to patches. Bonsaiviking (talk) 04:38, 7 December 2013 (UTC)

• How would general bug reports from non-developer users be handled in a bug tracker? Would there be more bug reports: would the barrier be lowered for filing reports and would the quality of reports be reduced as a result? Jah (talk) 23:27, 6 December 2013 (UTC)
  • I don't think the barrier gets much lower than sending an email, and that method would certainly still be valid. I would expect that for valid bugs that come in via the mailing list, someone would create a bug on the tracker. The primary benefit is that bugs don't slip off the radar. Bonsaiviking (talk) 04:38, 7 December 2013 (UTC)

On Continuous Integration

• The ability to catch basic errors, which happen from time to time, is obviously a benefit. Does using Git make this easier than with SVN? How much work would actually be involved: wouldn't this mean that the CI service would need access to one each of the various operating systems so that it can make sure Nmap builds cleanly on all of them? Jah (talk) 23:27, 6 December 2013 (UTC)
  • Depends on the CI service. Travis-CI uses 64-bit linux with gcc and clang. This is obviously far short of our intended support base, but it's a beginning. The advantage here is not really VCS-dependent, but rather that the popularity of Git and Github means that there are CI service providers available. Bonsaiviking (talk) 04:44, 7 December 2013 (UTC)