Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote:
> I believe core has a policy of never supporting vaporware...  There is
> always the chicken and egg problem with arguments like this...  I'll
> code this if you agree to support it and maintain it/I will agree to
> support it once you code it...   In FreeBSD, and many open source
> projects, no code, no support, how can you support or even agree to
> support something that doesn't exist?  And then as soon as FreeBSD
> agrees to support something that doesn't exist, either a) other people who
> were interested in the project stop, even if you end up never producing
> a bit of code, or b) someone else produces better code, drops the
> support for the original, but then the author complains about being
> told they'd support his code, and going with another code base...
> 
> Bottom line:  Once code exists, then support can be talked about..
 
This is the chicken and egg problem that will kill FreeBSD.   I don't
bother writing up patches for FreeBSD because every time I do they sit in a
PR and get ignored for several years.  Then someone that does have commit
rights makes their own patch (which often is less useful) but they own it
and the best I've ever succeeded at was convincing them to put some of the
ideas from my patch into their code.

Note that none of these patches were ever rejected for any technical or
political or any other reason.  They just don't get paid attention to.

Thus, I try to get consensus that the idea has merit.  IF freebsd
committers can be bothered to pay attention to the idea, I'll write code
for it.  But I'm too old and tired to spend another week writing up
something that will get ignored for X years and then dropped for obsoletion
again.

AND there are a lot of opinions and politics around how to version the core
that have nothing to do with code.  There's no value in writing code that
will be ignored because it doesn't agree with -core's view of "should be".
I'm a coder, not a politician.  If we can get consensus on what type of
implementation would be acceptable to core, then I and many others would be
happy to write code to implement this idea.  But this is a considerable
amount of work that will be closely tied to the operation system
installation.  It's not something that you can churn out 7 different
implementations of just to see which one fits the current polical
environment. 

Back to your finale:

> Bottom line:  Once code exists, then support can be talked about..

This is bullhockey and you know it.  Once the project is done, we'll
authorize a budget for it?  Once the season is over we'll know who should
be on the starting team?  Yeah, hindsight is sweet.  But this isn't a
simple change.  It will require very close integration with the installation
and kernel modules at least (and probably more).  So having some sort of
consensus that (a) the project has interest and (b) what flavors would be
acceptable to the existing groups - are both necessary for this project to
even mumble it's first line of code.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation