Upcoming Releases Schedule...

Jo Rhett jrhett at netconsonance.com
Sat Sep 20 00:46:37 UTC 2008

First, I'd like to thank you for taking the time to respond to this  
seriously.  I hope you'll read my reply in the very serious, and not  
accusative tone it is meant.  (I am a little tired and fried at the  
moment, I may not use the best phrasing.  I hope I do.)

On Sep 19, 2008, at 4:20 AM, Robert Watson wrote:
> This is the same answer I gave Lowell, but let me expand on it  
> slightly.  Our community grants rights (read also: responsibilities)  
> on the basis of credibility in the community.  Here's a possible plan:
> work for supported branches.  This in turn may convince them that  
> they should invest their time in mentoring you for a FreeBSD commit  
> bit, and potentially join the security or release engineering teams  
> once you've established that you are a member of the developer team  
> who works well with others, does good technical work, and who is in  
> it for the long haul.

Look, I understand what you're saying here.  And I don't discredit or  
disagree that it shouldn't be handled this way.  But what you have  
addressed is a stepwise integration policy of a developer, and does  
not address how to get a business to commit those resources.

Why?  Because you are asking for the business to commit the resources  
without a goal.  No, I'm not saying that FreeBSD has to guarantee  
anything.  We both know that guarantees on open source projects aren't  
worth much.

What I'm saying is that your scoped outline has no goal.  Nothing to  
even reach for.  Except maybe perhaps a commit bit for me.  If I had  
wanted a commit bit, I'm sure I would have one by now.  I'm not  
particularly worried about that.  I don't even really care to have one  
(though I would if that was necessary).

But that's the highest goal of your outlined scope.  A commit bit.

What's missing?

	A. A goal
	B. An assessment of the requirements to reach that goal

To get a business to commit resources to a project there must be an  
actual goal.  And to reach that actual goal there must be both (a) a  
plan to get there, (b) a reasoned assessment of the effort involved,  
etc etc and (z) the effort taking place to reach that goal.  Obviously  
(z) matters and perhaps you can say it matters most. But no sane  
business tries to do (z) without a clear idea of what (a)(b)(...) is.

If you've seen the appropriate Southpark episode: "Step 3: Profit!"   
"Dude, what's step 2?"

> (1) It doesn't give the immediate gratification of seeing the  
> official support
>    status extended for releases.  However, as you say, you're  
> already doing
>    the work.

I'm honestly confused by this statement, because I can't imagine  
anything about the proposed work being "immediate" no matter how it  
was approached.

> and that have they confidence of the security team that will be able  
> to work with appropriate discretion in protecting the confidential  
> and often critical security information we receive.

Unless the security problem is reported internally within FreeBSD  
alone (very few problems are) I usually have the security details long  
before you release patches.  I don't see this as much of a hindrance  
if any.

> Don't take this as a personal slight -- none of this says you aren't  
> able to work with others, that you don't have the technical skills,  
> that you don't have the time, aren't willing to make the commitment,  
> or that you lack adequate discretion.  Rather, it's saying that the  
> way we evaluate people for participation in the project is that they  
> have a track record of these things in the community.  In a largely  
> online and volunteer community, that's the way it works.

There's *nothing* wrong with what you have said.  What you have said  
makes perfect sense from an integration perspective.  But I don't  
think it addresses the issues at hand -- businesses need to have  
explicit goals and at least a haphazard guess at the requirements to  
reach those goals before they'll commit resources.

I don't see these problems as being in conflict.

In fact, I would personally suggest that most of the resources you  
need to improve your releases don't need commit bits.  I personally  
have no objection at all to running all patches through another set  
(or two, or three) of eyeballs.  It's a damn good practice ;-)  It's  
unlikely to slow me down one bit.

^^^ you may know more about the resource limitations and why commit  
bits are necessary to relieve your resource strain.  In that  
situation, please educate me.  Or everyone.  In particular, I'll be  
happy to buy you coffee/beer/poison of choice at your leisure if that  
would make this easier.

Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

More information about the freebsd-stable mailing list