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

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

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to