Date: Fri, 26 Aug 2011 10:06:32 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: mdf@FreeBSD.org Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org Subject: Official git export (was: Re: FreeBSD problems and preliminary ways to solve) Message-ID: <alpine.BSF.2.00.1108261000040.48200@fledge.watson.org> In-Reply-To: <CAMBSHm8uX45k0M4on=5Cpw_CKoddA=4oJSNXpH7dGPt=Vy2HOw@mail.gmail.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <CAJ-Vmo=v0UkQarauKrvWKdjMTC81BwXmyhU__rnaQeL3z45L-g@mail.gmail.com> <slrnj5ddgp.4ck.vadim_nuclight@kernblitz.nuclight.avtf.net> <CAMBSHm8uX45k0M4on=5Cpw_CKoddA=4oJSNXpH7dGPt=Vy2HOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Aug 2011, mdf@FreeBSD.org wrote: > On Thu, Aug 25, 2011 at 1:52 PM, Vadim Goncharov <vadim_nuclight@mail.ru> > wrote: >> Here an interesting question arise, in the philosophy/VCS field. We see >> that Linux/git adopted model where "dictator" has, say, 17 lieutenant for >> key subsystems, and pulls changes from them, each of them have, say, 17 own >> subordinates from whose he pulls, and so on. Instead of that 17^2 people >> FreeBSD has the same 289 men directly commiting to repository. It is >> repository here which acts as a "dictator" from technical side, and that is >> definetely better (e.g. no "kill -SIGBUS Linus" factors). The difference >> is, those 289 key people in Linux *can* pull changes from lower tiers, but >> FreeBSD people - can't (of course not at all, but it is significantly >> harder to contribute here). It is a plain model. > > I like that the Project is small enough that (1) I can be trusted to commit > to any of it, and (2) after a few more years of work on it, I may very well > know more than half of the code. It's not always possible to have lots of > functionality in a small code base, but less code is better, and I wonder if > FreeBSD's code size stays smaller because we can all work on all of it. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1108261000040.48200>