On Sep 20, 2008, at 3:37 AM, Robert Watson wrote:
The tension here is between making promises we can definitely keep
and starting to make promises that we can't. We'd like to err on
the former, rather than latter, side.
Yes. This is well understood and I agree with those priorities.
You already identified the end goal: extend support lifetimes. You
placed constraint on how that could be accomplished: you were going
to do the work. What I've done is identified our normal model for
getting from the current starting point (a guy on a mailing list
who, while enthusiastic, hasn't shown us the beef) to the proposed
outcome (a guy on the security-officer team, commit access required
to participate in the support process, etc). Here are the subgoals
I broke it out into:
Again, what you are saying makes a lot of sense, and I have no problem
with it. We're just missing the crucial bit -- what is it going to
take to reach that goal? Regardless of commit bits, etc and such
forth. Is 10 hours a week of one person enough? Does it really need 4
people with 10 hours a week? How do we get from here to there?
This is where I think we're missing each other. Achieving a commit
bit -- sure, no problem with what you have outlined. But you haven't
finished the thought enough to confirm whether me having a commit bit
would solve the problem we are trying to solve.
I mean honestly, is one person with a commit bit and some time enough
to solve the problem? I've been involved with enough projects to know
that the real answer might be, "no, we actually have all the people we
need with commit bits but our infrastructure makes doing this
difficult right now".
If you've seen the appropriate Southpark episode: "Step 3:
Profit!" "Dude, what's step 2?"
Let's make sure we understand each other clearly: the reason you're
getting replies using words like "demand" is that it is easy to read
your e-mails in exactly the above light. It is not a stretch to
interpret them as reading, "Put me on the security officer team
without having gone through any of the normal processes used to vet
a new member".
Well, I find it really sad that I would refer to a hilarious episode
about, of all things, Underpants Gnomes! and you would find some way
to read it as a demand.
Someone is going pretty far to think that, enough such that I doubt it
could be empirically proven, given that I have repeatedly stated that
I could give a darn about a commit bit - and that my only goal is to
make it easier for businesses like my $EMPLOYER to sustain
deployment. And furthermore, over 90-something percent of my
questions have only had the goal of acquiring information. Without
that information, I'm not even certain that my skillset is what is
necessary to improve this situation.
Once that information is made public, I may end up looking at it and
saying either "this isn't something my skills can contribute to in a
worthwhile fashion", "this isn't feasible based on what I know of
resources that could be brought to the table", etc etc and such forth.
I mean seriously, Robert -- if I wanted to demand something I'd be SoL
because I haven't the vaguest clue what to demand. I've facing this
high black wall of no information. Nobody (on this side of that wall)
can make intelligent decisions about what the right thing to do would
be.
I'm sorry, there is another way to think about this. Yes, I am
"demanding" (not a word I would prefer to use, but...). I would like
the release team to be specific about what resource limitations
prevent it from from longer support periods for -REL branches.
IF and WHEN such information is made available, my $EMPLOYER and a few
others would be interested in discussing what resources we could bring
to the table to help resolve those resource limitations. At that
point we would determine how to best use those resources in a manner
that the FreeBSD developers are capable of integrating and sustaining
in the long term. (ie what you've outlined in your past two messages)
We can talk about changing the process, but I think you can't
contribute to that conversation constructively without understanding
the process. Simply demanding change (and that's how it reads)
shows a lack of respect for how we got to where we are, and puts
people people on the defensive. Or offensive, in some cases. :-)
I've never demanded change. I spent the whole afternoon yesterday
rereading every post I've made to this list in the last 6 months, and
nothing there demanded anything other than information about the
resource limitations that were alluded to but never spelled out.
And yes, offensive seems to be the default selection by FreeBSD
developers.
If you approach a software company and say "Look, we like your
product, but it would really help us if you supported each minor
release for 24 instead of 18 months, and the way you're going to do
this is put our employee on your security response team", I think
you'd see a lot of raised eyebrows there as well.
That's the point. I've never said anything like that. And a software
company would totally understand the question as originally phrased.
"What resource limitations prevent you from supporting this product
for a longer period?" Any company would fairly promptly come back
with an answer.
FWIW, there are at least 3 companies whose software product is
supported on FreeBSD, or with Apache, or various other things because
of my integration work for them. We approached them and said "We
would like you to support XYZ. What do you need to do this?" The
software company chatted with us about it, and everyone decided it was
easier to have me do the integration work for them as opposed to
paying them more. (other companies we paid for them to do the work,
etc)
This is how things work. You ask a question, somebody answers the
question and you sit and chat about solutions that meet everyone's
needs. This situation with FreeBSD has been downright shocking
because I've never before in my life been attacked for saying "We need
this. How can I help?"
--
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]"
