On Thu, 25 Aug 2011, md...@FreeBSD.org wrote:

I'm less concerned about the code base size, and more concerned about how we can best support an ecosystem of FreeBSD-derived projects. FreeNAS, PC-BSD, pfSense, zrouter, etc, but also companies like Juniper, Yahoo!, NetApp, Panasas, EMC, etc, all want to do two things to FreeBSD:

(1) Specialise aspects of the FreeBSD environment (2) Extend aspects of the FreeBSD environment

Where possible, we should integrate changes that make their lives easier, of course (and do -- several PC-BSD developers were given FreeBSD commit bits specifically so that they could merge back PC-BSD changes).

However, we do have to ask ourselves if our revision control model makes their lives easier. I personally believe that the model we currently use scales quite well (subject to some unfortunate limitations in Subversion merging support) for what we're trying to accomplish as the FreeBSD project. However, one aspect of the git/Mercurial/etc model that we aren't able to capture particularly well is making it easy for people to pull in FreeBSD as a "flow of changesets" to use as a foundation for their own projects. I've visited a number of companies tracking FreeBSD, and they all find this difficult -- not just the social model of how to do it, but also simply the technical obstacles. Many use Perforce and find that works well, but I think we need to provide stronger support for the downstream open source community.

One way to do this is to make "more official" our output if git exports of the repository -- something that many other Subversion-based projects do: Chromium, clang/LLVM, Tor, etc. Folk like Ulrich have been doing this on a casual basis for some time, but I think we need to formalise this and provide end-user documentation on how to use git to track FreeBSD, contribute patches, etc. There are a number of hitches people have to know about: the potential impact of obliteration, how to handle $FreeBSD$ correctly for system call additions, and so on. Simply writing them down and having an official git.FreeBSD.org (or even gitsvn.FreeBSD.org) would go a long way.

I have to admit I've always preferred Perforce to git, simply because it strikes me as a more structured approach, partial checkouts (but especially composition of different depot pieces in a single checkout to create hybrid trees), etc. But git is widely used, and quite effectively used, by large communities. We need to support those communities better.

Robert