From: Linus Torvalds on


On Fri, 5 Mar 2010, Dave Airlie wrote:
>
> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
> rebuild + install.

This one doesn't work on F12.

It wants xorg-x11-server-devel > 1.7.99.3-3.

Is there some limited set of rpm's I can get from the f13 archive?

Linus


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on
On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds
<torvalds(a)linux-foundation.org> wrote:
>
>
> On Fri, 5 Mar 2010, Dave Airlie wrote:
>>
>> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
>> rebuild + install.
>
> This one doesn't work on F12.
>
> It wants xorg-x11-server-devel > 1.7.99.3-3.
>
> Is there some limited set of rpm's I can get from the f13 archive?

If by limited you mean the whole X server + udev updates that would work,

if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm

That src rpm should be rebuildable on F12, I just removed the requires
on F13 stuff.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on


On Fri, 5 Mar 2010, Dave Airlie wrote:
>
> if not then:
> http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
>
> That src rpm should be rebuildable on F12, I just removed the requires
> on F13 stuff.

Well, that wants the new kernel, but I can force it with --nodeps..

I'll reboot and test.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on


On Thu, 4 Mar 2010, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> >
> > if not then:
> > http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> >
> > That src rpm should be rebuildable on F12, I just removed the requires
> > on F13 stuff.
>
> Well, that wants the new kernel, but I can force it with --nodeps..
>
> I'll reboot and test.

Bingo.

Could this be done as a real F12 binary package (maybe call it
"force-nouveau-0.0.16" or something) for testers to use? I had most of the
X devel tools set up anyway since I used to build intel drivers from git
for one of my experimental machines. And I guess most kernel devs can
generally easily do the rpm build, but I'd hate to lose any more plain
testers than I absolutely have to.

And it would make it way easier for people to try out their kernel, notice
that X doesn't work, and then let them know that something like a simple

yum install force-nouveau-0.0.16

makes it work. Compared to having them install X builds, do a "rpm -Uvh
--nodeps" etc etc.

Anyway, this at least makes me feel like I don't have to revert that
commit just to be able to test current -git again. Thanks,

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

* Ben Skeggs <skeggsb(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/