Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Jun 1999 21:58:45 -0400 (EDT)
From:      Chuck Robey <chuckr@picnic.mat.net>
To:        Vince Vielhaber <vev@michvhf.com>
Cc:        Jaye Mathisen <mrcpu@internetcds.com>, "Jordan K.Hubbard" <jkh@zippy.cdrom.com>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG, Garance A Drosihn <drosih@rpi.edu>, Amancio Hasty <ahasty@mindspring.com>
Subject:   Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Message-ID:  <Pine.BSF.4.10.9906032125480.82061-100000@picnic.mat.net>
In-Reply-To: <XFMail.990603205907.vev@michvhf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jun 1999, Vince Vielhaber wrote:

> > Just realize, IF you're loud enough, and succeed, the programmers will
> > all desert you, and you'll have a nice place to argue, but no more
> > software.  Core here does an excellent job, with all the problems they
> > face, most committers will agree to that pretty quickly, and they are
> > the only ones with a vote.  Look to reality for the reasons why.
> 
> No need for blowing up, so relax.  You may wanna grab that bourbon 
> bottle yourself and take a sip.  

Maybe you're right, but I'm tired to people talking about core like
they're some evil overlord group.  These guys are longtime FreeBSDers.
They've been doing it a long time, and a large part of why they are
still doing it is because of a feeling of responsibility.  They're doing
a great job, even if it's not 100% without error, and FreeBSD would go
right down the tubes pretty quickly without coolheaded guidance, just
because of the lack of control.  You don't have to look hard at all to
see several recent (and some ongoing) episodes of folks trying to go off
on their own, and the only real restraint is the realization of what
kind of limits core will allow.

It's got a *great* track record.  We can argue specific issues, but
attacking core itself, that I'm going to jump up and shout about.

> 2) Nothing was ever said about telling volunteers what to do or not do.

You referred to a group other than core setting policy.

> 3) Nothing was mentioned about the technical abilities of an appeals
>    board or oversight group.

You said that group would have no committers or core on it.  Anyone
who's shown skill and time has been pretty quickly asked to become a
committer, so that pretty much means you're asking for either
non-technical folks, or folks without the time to follow things close
enough to have any real idea what's going on.

Seeing as you did admit you haven't followed the issues closely enough
yourself, you're one of the ones you figure would be on that board,
right?

> 4) Ever do or say something that someone told you that you're out of 
>    line?  

Oh, yeah, sure, I make mistakes.  Maybe wrong here, but I said above
what keyed me off.  It sure isn't bragging if I say here that I'm
willing to bet I make more mistakes than you do, but I don't think I'm
wrong here.

> 5) Let's go back to your volunteer thing.  You have volunteers willing
>    to work for you - for free.  It's no secret that in the past core
>    has been a problem for some (or maybe even many) of these volunteers.
>    They went away.

As has been pointed out endless times, you have to know how to code and
be willing to read FreeBSD code enough so that you can contribute well
integrated code.  If you can't code or don't have the time, no, you
can't contribute that way.  You can help us by putting in problem
reports, but not by trying to gain control, even a small part.  The
coders control FreeBSD, because they love it.  Those are really the only
folks who get to directly contribute.

Free contributors, out of control, are a mob.

> 
> If there's noone they can go to, why should they (or anyone else) bother
> to volunteer?

The FreeBSD mailing lists are the most active, quick response groups on
the net.  Don't you feel silly claiming there's no one they can go to?

> Earlier in this thread Matt was accused of running rough shod over everyone.
> Looking over the history and hearing the complaints of some of those involved,
> I admit not knowing both sides of the FULL story, that core may be partially
> to blame.  But who is there for the *VOLUNTEERS* to turn to?  Core?  They 
> may have caused the problem.  Then once the emotions start to rise there's
> absolutely NOONE for any of them to look to besides Jordan and/or David.
> Like they don't already have enough to do.

That last paragraph ... "core may be partially to blame".  Did you read
the entire thing, which went on in the -current and -committers list?
If you didn't, then you don't get a chance to comment.  If you want to
jump on core, read the mailing list archives and get the arguments in
order.  You can't just slander folks that way, and expect it to be taken
as just innocent sniping, because sniping isn't innocent.

In fact, Matt was hearing a great deal of negative comment on his
commits, from folks who originally did the code, and he was ignoring it,
claiming it "slowed him down".  This went on over weeks.  The only way
to stop him, demonstrably, was what was done, because all the mail
arguments did was raise temperatures, not slow things down a whit.

Matt does *great* code, he just doesn't like to read and test as much as
code away and react later to problem reports.  Being that he was working
on the virtual memory system, something which can very easily get
totally beyond repair without careful testing, his refusal to slow down
was more than could be tolerated.  He may well write better code than
nearly all of us, but he needed to do it slower.  He sure as heck writes
better code than I do.

> It's obvious there's a problem with the status quo, but if the status quo
> continues to run rough shod over any possible solution, status quo will 
> end up running out of volunteers and there will be yet another BSD to add
> to the collection.  Maybe the next one can be called ClosedBSD?

Why, because you listen to a few days of the loudest complainers, and
decide without further ado that they must be right?

There were good reasons behind both of the two recent problems, but
you've admitted you haven't done the reading to comment on it.  Why do
you then feel qualified to say it's core's fault?  Say I agreed with you
(I obviously don't), what would your reasons be?  If you can't *really*
answer that, and not just add in suppositions, then you are being
ethically dishonest.

> 
> Now reread your own last paragraph.  It goes at least two ways.  How much
> talent and support (technical, financial, advocational[1], etc.) are you 
> willing to lose before anyone's told they're outa line?  For all that 
> matter, how much has already been lost?  You used the phrase "crack pot".
> Doesn't a cracked pot leak?  Isn't that what's already happening?  Talent
> leaking out?

The problem *was* folks who wanted to code far faster than the review
process would allow.  Core still feels that's wrong.  If Matt were
willing the *guarantee* that he wouldn't overrun reviewers, then he'd be
back as a comitter tonight.

It is *not* worth it to bring on all possible contributors, if they're
going to innocently cause more damage than they fix, even if they are
doing it with the best of intentions.

Controlling contributors is the whole problem core's been working on,
they fully realize the tradeoffs, do you really think they don't?

----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@picnic.mat.net       | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770         | I run picnic (FreeBSD-current)
(301) 220-2114              | and jaunt (Solaris7).
----------------------------+-----------------------------------------------






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906032125480.82061-100000>