Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Ingo Molnar <mingo <at> elte.hu>
Subject: Re: [git pull] drm request 3
Newsgroups: gmane.comp.video.dri.devel
Date: Friday 5th March 2010 06:49:55 UTC (over 7 years ago)
* Ben Skeggs  wrote:

> > But here's the thing: if you expect people to do development, they
_need_ 
> > to be able to mix things. A kernel developer needs to be able to update

> > their kernel. And a kernel _tester_ needs to be able to test that
kernel.
>
> Here's the thing.  *You* pushed for nouveau to go into staging before any
of 
> the developers were ready for it.  Two of the big reasons (from my POV)
for 
> not requesting inclusion were the context programs (which have since been

> dealt with) and that yes, we have no intention of keeping crusty APIs
around 
> when they aren't what we require.
> 
> The idea of staging was to allow for exactly the second problem, so why
are 
> you surprised?  The fact Fedora ships nouveau is irrelevant, we also
expect 
> that for the most part people will be using our packages, which deal with

> the ABI issues.

Here is my experience with the development of various ABIs - and i've been
on 
both sides of the fence, i've done 'flag day' ABI changes during
development 
myself, and i've done gradual ABI development as well.

One experience i can tell you with 100% certainty: no matter whether a
project 
is small or large, simple or complex, whether the old ABI is the ugliest
wart 
on this planet or just hit by an unfortunate limitation that needs to be 
eliminated.

The conclusion is crystal clear, breaking an ABI via a "flag day" 
cleanup/feature/etc is:

 - wrong

 - harmful

 - limits the developer base

 - limits the tester base

 - wastes time and effort. (fewer developers/testers means that while
_this_ 
   feature was easier to add, all your _future_ features will be a bit
harder 
   to do. It compounds up.)

 - so it hurts even the very developer who is most convinced that this was
the 
   right thing to do

It's a bad technical decision throughout. It's masochistic and often
suicidal 
to just about any project in essence. I've seen projects that did it once
and 
died just due to that single act of stupidity. I've seen projects that have

done it a few times and took the usage hit, limped along with the wounds
and 
never grew to the size they could have achieved. I've seen projects that
did 
it once, took the hit, learned from it and never did it again.

How many times does DRM want to take that bullet head on?

I have _never_ seen a situation where in hindsight breaking the ABI of a 
widely deployed project could be considered 'good', for just about any sane

definition of 'good'.

It's really that simple IMO. There's very few unconditional rules in OSS,
but 
this is one of them.

	Ingo

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
 
CD: 4ms