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

Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800:
> 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

And many other open source software projects...  FreeBSD isn't unique
in this.. I've submitted patches to many other projects just to have
them ignored for years too...  It's a problem of voluteer orginizations..

> 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.

You're trying to target to large of an audience...  You need to get _A_
committer interested in your work, and get HIM to guide you and commit
your work...

> 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. 

stop talking about core...  -core makes absolutely no technical decisions
about how FreeBSD is..  it is the developers, and previously there was
a technical review board for settling differences between developers
that were pure "technical" in nature...  And if you claim you didn't
know this, then you better read the email you respond to more closely,
since this has been pointed out to you numerous times..

and you said in another email:
> First, this is obvious and true for all open source projects.  But no,
> FreeBSD _never_ advances because someone writes code that does something
> well.  FreeBSD _only_ advances when the core developers agree that this
> thing is worthy of their interest.

hmmm...  you really are choosing to completely ignore what people have
said about core, that at least you did add developers after core, which
makes it appear less likely that you're talking about -core.. but lots
of stuff gets done w/o core developers... I did lots of work on -sparc64,
and I'm pretty sure you wouldn't call me a core developer..  and I also
got TS-7200 arm support (though it hasn't been committed to cvs due to
issues that I haven't resolved with device configuration)...

As for the whole installation thing, you need to talk with re (release
engineering) as they are the ones to really have final say in what
installation and releases look like...

> 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

FreeBSD isn't commercial, so you can't talk about budgets...  And most
orgs want some sort of prototypes and feasibility study done before
they'll commit any budget to it...

> 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.

Yeh, you can get a & b, but you can't get commitment to accept what
comes out of a & b...  Unless of course you can make the time between
findout what a & b are and having code that implements a & b down to
zero...

None of this prevents you from getting a basic prototype that works,
but isn't complete with bells and whistles..  Look at what Colin did
with FreeBSD update, I didn't see him demanding anyone in FreeBSD to
sign off on his work...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."