Date: Thu, 21 Feb 2002 12:49:48 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Barcroft <mike@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Greg Lehey <grog@FreeBSD.ORG>, Jake Burkholder <jake@locore.ca>, David O'Brien <obrien@FreeBSD.ORG>, current@FreeBSD.ORG Subject: "Forking" FreeBSD: CVS vs. P4 Message-ID: <3C755D6C.BE8F1776@mindspring.com> References: <200202181912.g1IJCGK32122@apollo.backplane.com> <20020218114326.A98974@dragon.nuxi.com> <200202181951.g1IJpip33604@apollo.backplane.com> <20020218153807.E96115@locore.ca> <20020221111915.N65817@wantadilla.lemis.com> <200202210146.g1L1kqg91511@apollo.backplane.com> <3C746FC1.897E759C@mindspring.com> <200202210435.g1L4Z0H92642@apollo.backplane.com> <3C74B9EA.9692E27E@mindspring.com> <20020221144620.B68344@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Barcroft wrote: > I'm getting sick of reading this. Terry, if you want this code > integrated into FreeBSD, here's what you do: 1) Find yourself a > mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current > sources, 4) Have them reviewed, 5) Commit them. > > If you aren't interested in doing this, you are the sole person to be > blamed for them not being integrated into FreeBSD. And I'm getting sick of being dragged down into details in what should be a meta-discussion, thus effectively glossing over the major point in order to pick on one or two "objectionable" paragraphs out of an entire posting. Right now we have a situation where people are complaining about large scale changes being "dangerous", and at the same time complaining that they are taking place in the P4 repository instead of the CVS repository. One of these points of view has to give, so a uniform policy exists that people can comply with before they burn months of work for naught, or are unwilling to give up all that work -- just as the "386BSD 0.5 interim release" group was unwilling to give up their work, and "forked" 386BSD to create the first FreeBSD. Either it's OK to make large scale changes in the CVS repository, or it's OK to make them in a seperate (only currently P4) reposity, and integrate them later. Topologically, as far as the project is concerned, there's no difference between making changes locally or making them in the P4 tree. The alternative is to simply disallow the changes, which I'm sure would please some people. I prefer the dichotomy be resolved, rather than glossed over. I think it's valuable to look at why this "immune response" is suppressing, among other things, my list of examples... which was far from comprehensive, and which are not *my* examples, in particular, merely because I raised them. As was noted elsewhere, there are now 57 P4 branches, most of them active, in which work is taking place outside the umbrella of "the one true HEAD" of the CVS repository. There's no possible way this situation could have arisen in the first place, had not people found themselves beating their heads against _some_ obstacle that migrating to P4 based developement removed, and which removal was worth the cost of being yelled at for using P4 (among other costs). It seems to me that what people are getting upset about is the fact that the people using P4 are "routing around the damage" and are thus able to collaborate effectively towards goals that others won't believe in until they have a working example thrown in their face, and would prefer to not have that. We have to ask ourselves: what damage is being routed around that could be worth paying the "popularity penalty", when people yell "Hey! That's *my* barrier you're routing around!". The differences in the P4 vs. CVS environment are many, but the main ones which seem, sociologically, to favor P4 are: o Multiple lines of developement o Reduced politics o Reduced/removed review barrier o Better small project collaboration vs. patches and email I should think that people would be interested in *why* the situation has arisen, and not merely interested in bitching about the fact that it exists. Frankly, though I think having only "one true HEAD branch", as imposed by the use of CVS, has hurt FreeBSD's progress enormously (by creating a GlobalCop model game), I have to say that the middle two are probably primary in the minds of the people now using P4. In fact, I'll say it straight our: IMO, it's the review barrier. Matt's commit bit was yanked a long time ago, right after he reached the point where he could spend 12+ hours a day hacking on FreeBSD, and the reviewer resources simply could not keep up with his output. He effectively flood attacked the review process. The reaction of yanking the bit, and the subsequent backlash "corrected" this: not by increasing the review rate, but by decreasing the rate at which new code is submitted, and decreasing the maximum size that can make it through review. The problem is not the barrier itself, it's the rate at which the barrier processes, and the maximum load it can handle. Now we have a P4 repository, and there are at present 57 special interests who are routing around that barrier's inability to handle load. Perhaps it's time to follow the lead of Linux, and break the review barrier into multiple barriers, with seperately controlled review processes. People involved in review would then have to pick what they cared about most, and *trust* the rest of the people to make the right decisions. The overall ability to handle load would go up, just like adding machines to a web farm increases capacity. Doing this has certain drawbacks, as Linux has discovered (USL had a similar situation with similar drawbacks), the foremost being that cross-domain changes were inordinately hard to push through (cv. Linux's recent issues with their VM system "forking" between the RedHat/Alan Cox version, and the "official"/Linus version). I would argue that such changes are only "inordinately hard" in comparison to other changes, and that "inordinately hard" is no worse than what's there now. Small changes will still pass individual barriers as easily as they pass the big one today -- easier, in fact, with less people standing in line to rubber stamp the changes. Hopefully, over time, these drawbacks can be overcome, or a better approach will come along (e.g. the barriers being drawn on the lines of well documented and rigidly defined interfaces, agreed upon between the various guards at the various gates). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C755D6C.BE8F1776>