From: Ingo Molnar <mingo@elte.hu>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Airlie <airlied@gmail.com>, Dave Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org,
Jesse Barnes <jbarnes@virtuousgeek.org>,
dri-devel@lists.sf.net
Subject: Re: [git pull] drm request 3
Date: Fri, 5 Mar 2010 07:49:55 +0100 [thread overview]
Message-ID: <20100305064955.GA6453@elte.hu> (raw)
In-Reply-To: <1267748927.3496.6.camel@nisroch>
* Ben Skeggs <skeggsb@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Jesse Barnes <jbarnes@virtuousgeek.org>,
dri-devel@lists.sf.net
Subject: Re: [git pull] drm request 3
Date: Fri, 5 Mar 2010 07:49:55 +0100 [thread overview]
Message-ID: <20100305064955.GA6453@elte.hu> (raw)
In-Reply-To: <1267748927.3496.6.camel@nisroch>
* Ben Skeggs <skeggsb@gmail.com> 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
--
next prev parent reply other threads:[~2010-03-05 6:51 UTC|newest]
Thread overview: 290+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 23:56 [git pull] drm request 3 Dave Airlie
2010-03-04 18:18 ` Linus Torvalds
2010-03-04 18:27 ` Matt Turner
2010-03-04 18:27 ` Matt Turner
2010-03-04 18:36 ` Jesse Barnes
2010-03-04 18:36 ` Jesse Barnes
2010-03-04 18:39 ` Jesse Barnes
2010-03-04 18:39 ` Jesse Barnes
2010-03-04 18:51 ` Linus Torvalds
2010-03-04 18:51 ` Linus Torvalds
2010-03-04 18:56 ` Jesse Barnes
2010-03-04 18:56 ` Jesse Barnes
2010-03-04 19:08 ` Linus Torvalds
2010-03-04 19:08 ` Linus Torvalds
2010-03-04 19:25 ` Dave Airlie
2010-03-04 20:01 ` Linus Torvalds
2010-03-04 22:06 ` Dave Airlie
2010-03-05 0:08 ` Linus Torvalds
2010-03-05 0:28 ` Ben Skeggs
2010-03-05 0:28 ` Ben Skeggs
2010-03-05 0:41 ` Linus Torvalds
2010-03-05 0:41 ` Linus Torvalds
2010-03-05 0:56 ` Luc Verhaegen
2010-03-05 0:56 ` Luc Verhaegen
2010-03-05 1:08 ` Linus Torvalds
2010-03-05 1:08 ` Linus Torvalds
2010-03-05 1:16 ` Luc Verhaegen
2010-03-05 1:16 ` Luc Verhaegen
2010-03-05 1:22 ` Linus Torvalds
2010-03-05 1:22 ` Linus Torvalds
2010-03-05 1:20 ` Linus Torvalds
2010-03-05 1:28 ` Dave Airlie
2010-03-05 1:28 ` Dave Airlie
2010-03-05 5:17 ` Linus Torvalds
2010-03-05 5:22 ` Dave Airlie
2010-03-05 5:22 ` Dave Airlie
2010-03-05 5:30 ` Linus Torvalds
2010-03-05 5:30 ` Linus Torvalds
2010-03-05 5:42 ` Linus Torvalds
2010-03-05 5:42 ` Linus Torvalds
2010-03-05 5:17 ` Linus Torvalds
2010-03-05 1:20 ` Linus Torvalds
2010-03-05 1:19 ` Upstream first policy Kyle McMartin
2010-03-05 1:28 ` Linus Torvalds
2010-03-05 2:00 ` [git pull] drm request 3 Tony Luck
2010-03-05 2:00 ` Tony Luck
2010-03-05 20:34 ` Felipe Contreras
2010-03-05 20:34 ` Felipe Contreras
2010-03-05 6:49 ` Ingo Molnar [this message]
2010-03-05 6:49 ` Ingo Molnar
2010-03-05 7:06 ` Pekka Enberg
2010-03-05 7:06 ` Pekka Enberg
2010-03-05 7:17 ` "C. Bergström"
2010-03-05 7:53 ` Ingo Molnar
2010-03-05 7:53 ` Ingo Molnar
2010-03-05 15:18 ` Linus Torvalds
2010-03-05 15:18 ` Linus Torvalds
2010-03-05 7:17 ` "C. Bergström"
2010-03-05 7:44 ` Ingo Molnar
2010-03-05 7:44 ` Ingo Molnar
2010-03-05 7:58 ` Dave Airlie
2010-03-05 7:58 ` Dave Airlie
2010-03-05 8:16 ` Stephane Marchesin
2010-03-05 8:16 ` Stephane Marchesin
2010-03-05 10:00 ` Making Xorg easier to test (was Re: [git pull] drm request 3) Carlos R. Mafra
2010-03-05 12:54 ` Valdis.Kletnieks
2010-03-05 12:54 ` Valdis.Kletnieks
2010-03-05 15:22 ` Matt Turner
2010-03-05 15:41 ` Daniel Stone
2010-03-05 15:49 ` Making Xorg easier to test David Miller
2010-03-05 15:49 ` David Miller
2010-03-05 16:03 ` Alan Cox
2010-03-05 16:03 ` Alan Cox
2010-03-05 16:06 ` Daniel Stone
2010-03-05 16:06 ` Daniel Stone
2010-03-05 17:50 ` Xavier Bestel
2010-03-05 17:54 ` David Miller
2010-03-05 18:02 ` Jesse Barnes
2010-03-05 18:05 ` David Miller
2010-03-05 18:05 ` David Miller
2010-03-05 18:02 ` Jesse Barnes
2010-03-05 17:54 ` David Miller
2010-03-05 17:50 ` Xavier Bestel
2010-03-05 15:41 ` Making Xorg easier to test (was Re: [git pull] drm request 3) Daniel Stone
2010-03-05 15:22 ` Matt Turner
2010-03-05 15:53 ` Linus Torvalds
2010-03-05 15:53 ` Linus Torvalds
2010-03-05 16:11 ` Daniel Stone
2010-03-05 16:30 ` Linus Torvalds
2010-03-08 8:57 ` Daniel Stone
2010-03-08 8:57 ` Daniel Stone
2010-03-05 16:30 ` Linus Torvalds
2010-03-05 16:11 ` Daniel Stone
2010-03-05 16:26 ` Jesse Barnes
2010-03-05 16:26 ` Jesse Barnes
2010-03-05 10:00 ` Carlos R. Mafra
2010-03-05 13:55 ` [git pull] drm request 3 Luc Verhaegen
2010-03-05 13:55 ` Luc Verhaegen
2010-03-05 16:21 ` Jesse Barnes
2010-03-05 16:21 ` Jesse Barnes
2010-03-05 12:38 ` Alan Cox
2010-03-05 14:37 ` David Miller
2010-03-05 14:46 ` Mike Galbraith
2010-03-05 14:46 ` Mike Galbraith
2010-03-05 18:05 ` Ingo Molnar
2010-03-05 18:05 ` Ingo Molnar
2010-03-05 15:09 ` Alan Cox
2010-03-05 15:11 ` David Miller
2010-03-05 15:11 ` David Miller
2010-03-05 15:09 ` Alan Cox
2010-03-05 15:17 ` Daniel Stone
2010-03-05 15:17 ` Daniel Stone
2010-03-05 15:26 ` David Miller
2010-03-05 15:26 ` David Miller
2010-03-05 15:40 ` Daniel Stone
2010-03-05 15:40 ` Daniel Stone
2010-03-05 15:48 ` David Miller
2010-03-05 15:48 ` David Miller
2010-03-05 16:02 ` Alan Cox
2010-03-05 16:02 ` Alan Cox
2010-03-05 16:05 ` David Miller
2010-03-05 16:05 ` David Miller
2010-03-05 17:58 ` Younes Manton
2010-03-05 17:58 ` Younes Manton
2010-03-05 16:13 ` Linus Torvalds
2010-03-05 16:23 ` Alan Cox
2010-03-05 16:23 ` Alan Cox
2010-03-05 16:44 ` Linus Torvalds
2010-03-05 16:44 ` Linus Torvalds
2010-03-05 17:04 ` Alan Cox
2010-03-05 17:10 ` "C. Bergström"
2010-03-05 17:19 ` tytso
2010-03-05 17:19 ` tytso
2010-03-05 23:54 ` Garry Hurley
2010-03-05 17:04 ` Alan Cox
2010-03-05 16:13 ` Linus Torvalds
2010-03-05 16:04 ` Daniel Stone
2010-03-05 16:06 ` David Miller
2010-03-05 16:31 ` Alan Cox
2010-03-05 17:36 ` Jerome Glisse
2010-03-05 17:36 ` Jerome Glisse
2010-03-05 16:31 ` Alan Cox
2010-03-05 16:06 ` David Miller
2010-03-05 16:46 ` tytso
2010-03-05 19:38 ` Corbin Simpson
2010-03-05 19:38 ` Corbin Simpson
2010-03-05 21:01 ` Corbin Simpson
2010-03-05 21:01 ` Corbin Simpson
2010-03-05 21:51 ` tytso
2010-03-05 21:51 ` tytso
[not found] ` <e7bd23c31003051452i117eadc1m5284ac5d14b6465d@mail.gmail.com>
2010-03-05 22:59 ` Corbin Simpson
2010-03-05 23:50 ` Tilman Schmidt
2010-03-05 23:50 ` Tilman Schmidt
2010-03-05 16:46 ` tytso
2010-03-05 17:23 ` Linus Torvalds
2010-03-05 17:23 ` Linus Torvalds
[not found] ` <hmra63$898$1@xyzzy.farnsworth.org>
2010-03-06 6:17 ` Dale Farnsworth
2010-03-06 17:21 ` Valdis.Kletnieks
2010-03-06 17:21 ` Valdis.Kletnieks
2010-03-05 16:04 ` Daniel Stone
2010-03-05 15:56 ` Luca Barbieri
2010-03-05 15:56 ` Luca Barbieri
2010-03-05 16:13 ` Alan Cox
2010-03-05 16:13 ` Alan Cox
2010-03-05 16:19 ` Linus Torvalds
2010-03-05 16:19 ` Linus Torvalds
2010-03-05 16:38 ` Alan Cox
2010-03-05 16:38 ` Alan Cox
2010-03-05 20:59 ` Felipe Contreras
2010-03-05 20:59 ` Felipe Contreras
2010-03-05 16:25 ` Luca Barbieri
2010-03-05 16:25 ` Luca Barbieri
2010-03-05 15:42 ` Alan Cox
2010-03-05 15:42 ` Alan Cox
2010-03-05 16:07 ` Linus Torvalds
2010-03-05 16:07 ` Linus Torvalds
2010-03-05 17:42 ` Jeff Garzik
2010-03-05 19:11 ` Justin P. mattock
2010-03-05 19:11 ` Justin P. mattock
2010-03-05 17:42 ` Jeff Garzik
2010-03-05 14:37 ` David Miller
2010-03-05 12:38 ` Alan Cox
2010-03-05 0:08 ` Linus Torvalds
2010-03-04 22:06 ` Dave Airlie
2010-03-04 19:25 ` Dave Airlie
2010-03-04 19:33 ` Jesse Barnes
2010-03-04 19:33 ` Jesse Barnes
2010-03-04 19:12 ` Matthew Garrett
2010-03-04 19:12 ` Matthew Garrett
2010-03-04 18:45 ` Linus Torvalds
2010-03-04 18:45 ` Linus Torvalds
2010-03-04 18:43 ` Linus Torvalds
2010-03-04 18:43 ` Linus Torvalds
2010-03-04 18:50 ` Matthew Garrett
2010-03-04 18:55 ` Linus Torvalds
2010-03-04 18:55 ` Linus Torvalds
2010-03-04 19:01 ` Linus Torvalds
2010-03-04 19:01 ` Linus Torvalds
2010-03-04 19:04 ` Matthew Garrett
2010-03-04 19:04 ` Matthew Garrett
2010-03-04 19:14 ` Linus Torvalds
2010-03-04 19:14 ` Linus Torvalds
2010-03-04 19:25 ` Matthew Garrett
2010-03-04 19:41 ` Linus Torvalds
2010-03-04 19:53 ` Matthew Garrett
2010-03-04 19:53 ` Matthew Garrett
2010-03-04 20:07 ` Linus Torvalds
2010-03-04 20:46 ` Matthew Garrett
2010-03-04 20:46 ` Matthew Garrett
2010-03-04 20:57 ` Stephane Marchesin
2010-03-04 20:57 ` Stephane Marchesin
2010-03-04 22:54 ` Linus Torvalds
2010-03-04 23:03 ` Dave Airlie
2010-03-04 23:19 ` Linus Torvalds
2010-03-04 23:19 ` Linus Torvalds
2010-03-04 23:27 ` Michel Dänzer
2010-03-04 23:27 ` Michel Dänzer
2010-03-04 23:28 ` Linus Torvalds
2010-03-04 23:28 ` Linus Torvalds
2010-03-04 23:35 ` Dave Airlie
2010-03-04 23:35 ` Dave Airlie
2010-03-04 23:53 ` Linus Torvalds
2010-03-04 23:53 ` Linus Torvalds
2010-03-05 0:24 ` Ed Tomlinson
2010-03-05 0:24 ` Ed Tomlinson
2010-03-05 0:24 ` Kyle McMartin
2010-03-05 0:24 ` Kyle McMartin
2010-03-04 23:28 ` Dave Airlie
2010-03-04 23:28 ` Dave Airlie
2010-03-04 23:03 ` Dave Airlie
2010-03-04 23:05 ` Jesse Barnes
2010-03-04 23:05 ` Jesse Barnes
2010-03-05 12:26 ` Alan Cox
2010-03-05 12:26 ` Alan Cox
2010-03-04 22:54 ` Linus Torvalds
2010-03-04 19:41 ` Linus Torvalds
2010-03-04 19:25 ` Matthew Garrett
2010-03-04 22:28 ` Adam Jackson
2010-03-04 22:28 ` Adam Jackson
2010-03-04 23:03 ` Linus Torvalds
2010-03-04 23:03 ` Linus Torvalds
2010-03-04 23:14 ` Stephane Marchesin
2010-03-04 23:14 ` Stephane Marchesin
2010-03-05 12:29 ` Alan Cox
2010-03-05 12:29 ` Alan Cox
2010-03-05 16:18 ` Adam Jackson
2010-03-05 16:18 ` Adam Jackson
2010-03-04 19:32 ` Jeff Garzik
2010-03-04 22:18 ` Adam Jackson
2010-03-04 22:21 ` Jeff Garzik
2010-03-04 22:59 ` Adam Jackson
2010-03-04 22:59 ` Adam Jackson
2010-03-05 11:24 ` Jeff Garzik
2010-03-05 11:24 ` Jeff Garzik
2010-03-05 15:46 ` Adam Jackson
2010-03-05 15:46 ` Adam Jackson
2010-03-04 22:21 ` Jeff Garzik
2010-03-04 22:18 ` Adam Jackson
2010-03-05 1:47 ` Robert Hancock
2010-03-05 1:47 ` Robert Hancock
2010-03-05 12:21 ` Alan Cox
2010-03-05 12:21 ` Alan Cox
2010-03-05 19:30 ` Eric Anholt
2010-03-05 20:39 ` Luca Barbieri
2010-03-05 20:39 ` Luca Barbieri
2010-03-05 19:30 ` Eric Anholt
2010-03-04 19:32 ` Jeff Garzik
2010-03-04 18:50 ` Matthew Garrett
2010-03-06 15:23 ` Sergio Monteiro Basto
2010-03-06 17:40 ` Linus Torvalds
2010-03-06 17:40 ` Linus Torvalds
2010-03-06 19:06 ` Sergio Monteiro Basto
2010-03-06 19:06 ` Sergio Monteiro Basto
2010-03-06 19:28 ` Linus Torvalds
2010-03-06 19:28 ` Linus Torvalds
2010-03-06 20:49 ` tytso
2010-03-06 20:49 ` tytso
2010-03-06 20:52 ` Alan Cox
2010-03-06 20:52 ` Alan Cox
2010-03-06 22:38 ` tytso
2010-03-06 22:38 ` tytso
2010-03-04 21:21 ` Maarten Maathuis
2010-03-04 21:21 ` Maarten Maathuis
2010-03-04 21:22 ` Maarten Maathuis
2010-03-04 21:22 ` Maarten Maathuis
2010-03-04 21:27 ` Maarten Maathuis
2010-03-04 21:27 ` Maarten Maathuis
2010-03-04 18:18 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2010-03-05 22:18 Jonas Ritz
2010-03-02 23:56 Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100305064955.GA6453@elte.hu \
--to=mingo@elte.hu \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sf.net \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skeggsb@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.