Upcoming Releases Schedule...

[Jo Rhett]

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