From: Jesse B. <jb...@vi...> - 2008-08-26 21:21:03
|
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: > On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <jb...@vi...> wrote: > > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote: > >> > As for the "new development model"... Things are actually worse than I > >> > thought. There are some fairly large differences between linux-core > >> > and upstream, some of which have been in linux-core for a long time. > >> > It's one thing to have an out-of-tree development process but another > >> > entirely to let stuff rot for months & years there. It just adds to > >> > the already huge set of driver combinations we have to worry about and > >> > support... > >> > >> How is doing merges preventing us from working on a single tree ? It's > >> two completely separate problems. > > > > There are several problems, see the earlier thread "Adapt on_each_cpu" > > where we talked about the current dev process problems. > > I am outlining the fact that you confuse a problem and its solution. > > Problem: merging stuff upstream takes time to Dave > Your solution: have lots of in-development trees and everyone > upstreams its stuff which breaks other drivers and platforms > A possible solution: everyone upstreams its stuff from a common tree > which keeps other drivers and platforms working Figured I should reply to this too (still trying to cool off after our heated discussion on IRC). I'm definitely *not* proposing a bunch of in-development trees to break other drivers and platforms. I don't want to break other drivers and platforms. Let me state again my issues: 1) drm master is way out of date wrt upstream Linux (and yes this is my fault too). This sucks and I'm trying to fix it by sending Dave easily digestible and tested patches against the tree he'll send to Linus for 2.6.28. 2) our current development process makes it fairly easy to get into situation (1). It's far too easy to push something into drm master and assume Dave will take care of it. It's also easy to push something in that the BSD guys miss, causing them to do extra work next time they merge ("hmm wtf is this new code supposed to do?") 3) dealing with ongoing Linux changes in the drm tree is harder than it has to be (we just continually add more compat code all the time, and things often break with new kernel updates) So really I'm just looking for solutions to (2) and (3). For me, that means developing & testing against a Linux tree first, since that's what goes upstream and that's what I have to support. It doesn't mean I can't push the resulting patches into drm master or work with people to make sure things get ported to BSD, etc. I don't think there are any silver bullets here. No matter what we do I think it's a lot of work. On a more personal note, statements like the below really suck: ... <marcheu> jbarnes: it was working fine before you were here, dude ... <MrCooper> yeah, it was fine before people stopped caring for anything but their little niche ... I've worked hard to make sure changes I make update all drivers in the DRM master tree, and worked with the other OS guys to keep things up to date, making things better for everyone in the process. If I've made anyone's life harder, I'm sorry, that's definitely not my intention. When I said, "So drm-next is all I care about anymore", it was more out of frustration than anything else. It's certainly all I care about *at the moment* since I'm trying to get most of the stuff from linux-core into upstream Linux, but that doesn't mean I'll stop working on drm master on other drivers or OSes. Jesse |