cvs commit: src/sys/compat/linux linux_socket.c

[Brian Fundakowski Feldman]

On Thu, Mar 10, 2005 at 04:16:08PM +0000, Paul Richards wrote:
> On Wed, Mar 09, 2005 at 11:13:39PM +0200, Maxim Sobolev wrote:
> > M. Warner Losh wrote:
> > >In message: <422F087F.9030906 at portaone.com>
> > >            Maxim Sobolev <sobomax at portaone.com> writes:
> > >: and need this tool to upgrade otherwise perfectly working system(s).
> > >
> > >As a veteran of ABI wars, I think that you have an unrealistic
> > >expectations about what can be done.  While an interesting goal, too
> > >many of the developers are hard wired to not even think about such
> > >considerations to make it successful.  We have a hard enough time
> > >making backward compatibility work, there's no hope for 'forward'
> > >compatability.
> > 
> > As a junior of ABI wars I think I have a realistic expectation about 
> > what can be done. Yes, many developers don't care about `backward' 
> > compatibility, let alone `forward' compatibility, but in fact both are 
> > really necessary in we want to position FreeBSD as a sound design.
> 
> >From a commercial standpoint, forwards compatibility is I think
> actually more important. When you release a commercial product
> you're actually more concerned about it working on already existing
> systems.
> 
> Imagine something like Photoshop being written on the most recent
> version of Mac OS X and finding that compatibility only worked
> forward.  That would mean that most users out there would have to
> upgrade their OS in order to use the most recent version of Photoshop!
> What's most important commercially is that you can use the most up
> to date development environment to target the largest possible
> installed user base. It matters a lot less if you have to support
> patches for newer systems since that's a much smaller user base to
> support and the onward development of your own product tends to
> keep pace with future platform changes.
> 
> A "stable" ABI means it doesn't change, not that it changes in a
> backwards compatible manner. We should be able to enhance future
> versions of a branch without creating these ABI incompatibilities
> by supporting the existing interfaces until a future major release
> removes them.
> 
> Better yet, lets stop "developing" our stable branches and focus
> on stabilising them and getter more rapid development done in our
> -current branch. There was a rash of MFCs for the next stable release
> which were nothing more than a feature push and were of dubious
> value in helping stability.

How is this even a problem?  The company targets 5.3-RELEASE, period,
for all of 5.x.  They do not need to upgrade their build computer to
anything past RELENG_5_3 even in the face of security issues.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\