"matthew sporleder" <msporleder@gmail.com> writes:

> Agreed!  -current is for forward-moving OS development.  Branches are
> for production use.

We're _doing_ forward-moving OS development.  The OMAP port is the tip
of an iceberg of new features we're adding to NetBSD.  (See my "Fun
Thing" email for a list.)

> The -real- mistake here was a company following the advice of
> someone to base a product on a target that moves daily.

No. The _real_ mistake here was caring enough to take on the overhead
of working in -current so we could contribute back.

> Do you re-branch/re-merge your internal work after your nightly cvs
> update?  (I think in this case it was weekly?  I don't recall
> exactly) How would you ever complete your work?  Without the stable
> branch, when can you say "current is good enough right now."?
> -current never stops!

(It was monthly, by the way. And we delayed when -current happened to
be too unstable at the moment.)

If you're developing a product that you intend to ship in 18 months
that involves adding significant new features to the OS you're going
to ship it on, you do not have the luxury of working in a stable
branch until very late in the project.

I've done this in a _lot_ of projects over the last thirty years, and
this is the *only* time I've had something like this happen.

> This whole thread feels like someone trying to pass the blame for a
> misguided technical decision.

If we were developing an application only, you would be partially
correct. Given that we're adding significant features to the OS
itself, are you sure you still want to make that claim?

> Can you imagine trying to use linux 2.6.yesterday to base your
> production embedded app on and then complain when netfilter gets
> replaced by some other project?  You'd be laughed out of usenet. ;)

No, I can't imagine that. I _have_ however built products (3 so far)
in which I tracked Linux closely and only settled on stable late in
the project, including one that tracked the tip'o'tree until three
months before it shipped.

On the other hand, I can't imagine either Andrew Morton or Linus
Torvalds accepting a patch that broke active architectures.

You might, by the way, take a close look at Linus' rules for
deprecating features. You'll find that your example would never happen
in the way in which this example happened:

1) _All_ techical disucssions on Linux developement that stands a
   chance to make it into the tree happen on _open_ technical mailing
   lists

2) _No_ code goes into the tree that breaks existing architectures.

3) _Deprecated_ code is not removed for years after the deprecation
   has been announced.

By the way, I _routinely_ run the Linux equivalent of -current (2.6.x,
currently .20) as the _production_ kernel on my work boxes.