Message-ID: <e7bd23c31003051138k14436b42t5bf544c375413c6c@mail.gmail.com>
Date:	Fri, 5 Mar 2010 11:38:46 -0800
From:	Corbin Simpson <mostawesomedude@...il.com>
To:	tytso@....edu, Daniel Stone <daniel@...ishbar.org>,
	David Miller <davem@...emloft.net>, skeggsb@...il.com,
	airlied@...ux.ie, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, dri-devel@...ts.sf.net, mingo@...e.hu,
	torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk
Subject: Re: [git pull] drm request 3

On Fri, Mar 5, 2010 at 8:46 AM,  <tytso@....edu> wrote:
> On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote:
>>
>> So you're saying that there's no way to develop any reasonable body of
>> code for the Linux kernel without committing to keeping your ABI
>> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
>> that worked really well for Xlib.
>
> No, that's not what people are saying.  What people are saying is,
> "avoid flag days".  Deprecate things over a 6-12 month time period.
> We have lots of really good interfaces for doing that.
>
> You say you don't want to do that?  Then keep it to your self and
> don't get it dropped into popular distributions like Fedora or Ubuntu.
> You want a larger pool of testers?  Great!  The price you need to pay
> for that is to be able to do some kind of of ABI versioning so that
> you don't have "drop dead flag days".
>
> If you don't want to be a good citizen, then prepared to have people
> call you out for, well, not being a good OSS citizen.

I was trying my hardest to not say anything, but...

Nouveau isn't an official Xorg project. It hasn't been added to the
jhbuild list for auto-checkout, it doesn't get tinderbox time
(admittedly a function of being part of the jhbuild) and I don't think
it's on the katamari list, so it's never been shipped as part of an
Xorg release. It is only in mainline under the staging rules; drivers
come and go from staging under fairly lax rules.

Fedora ships this stuff because they're actively developing it and
enjoy deploying half-broken things to users in the vain hope that it
magically won't break. I can't count the number of kittens eaten by
Fedora systems I've used. (It is kind of sad that Fedora's still the
best distro about not deploying broken stuff but still remaining
up-to-date.) Tellingly, it doesn't look like this interface change has
been deployed to stable Fedora, just Rawhide.

The Ubuntu people don't talk to us as much as they should. Seeing how
badly they biffed Radeon and Intel KMS deployment, it's hard for me to
believe that deploying Nouveau went smoothly. I don't have much more
personal experience; my work computer has an HD 3450 in it now instead
of the old GeForce, and that's my only Ubuntu box.

If distros want to run weird experiments on their users, let them!
Sure, sometimes bad things happen, but sometimes good things happen
too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
Plymouth, the list goes on and on.

If the problem here is actually that a distro is deploying a staging
driver and picking up the pieces themselves, then just say it. This
whole thing with flag days, deprecation, interface changes, etc.
hinges on the idea that the code being deprecated was stable, usable,
and widely deployed, but it wasn't and isn't.

That said... Code probably is moving too fast inside nouveau. There is
a bit of a wall to go through to get new patches upstream, which one
would hope would inspire some developer restraint. intel and radeon
both still have most (if not all) of the legacy code needed by ancient
userspaces, and both DDX drivers are doing multiple-branch releases to
keep old userspace interfaces alive for people unable to update their
kernels. It might be useful for the nouveau guys to really seriously
consider code before it leaves their trees and enters mainline;
writing code that you won't commit to is quite lame for the obvious
reasons, but also for some unobvious reasons, e.g. it makes you look
like you don't actually know what you're doing and would rather just
keep reinventing wheels without justifying and testing your design
choices. (This is also why I was not exactly pleased with the
suggestion of retooling all of the r600 userspace over a change to the
CS system; we just spent the better part of a year moving everything
over to CS!)

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists