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
...etc
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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
