On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
>>
>> 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.
It seems to me that this is putting more work on Dave, because in the
end he'll be the one merging back from the kernel to linux-core. But
then the stuff he merges might have become stale so it's more work.
Not to mention the linux-core directory also has things to upstream,
so we're talking 2-way merges.
> 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?")
Sure, to which a possible answer is "upstream your own stuff". Again I
suppose there could be more answers, but it's a simple first step.
Maybe once the un-upstreamed stuff is cleared, we can move on more
easily with other things.
> 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)
OTOH with the current scheme developers/testers can keep their old
kernel. All the nouveau users do that for example, the backwards
compatibility doesn't seem impossible to do and that certainly didn't
preven the DRM from working for years.
>
> 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
> ...
Oh, I realize this statement could be misinterpreted as "you're
responsible for breaking the drm" or some such. I meant "our drm
development model was working fine for a long time before you were
here, so why change it". We used to support Linux/BSD and under
development/un-upstreamed drivers in a single tree. We might lose this
and I think that's a mistake.
If you ask me we "just" need to change the "who's upstreaming what"
bit for now. I don't think there is an inherent problem to sharing the
DRM tree.
><MrCooper> yeah, it was fine before people stopped caring for anything but
> their little niche
> ...
The core of the issue is there though. Do we still want to share
stuff, or do we want to work in our own separate trees. And if we have
separate trees, what's the policy for the shared infrastructure: how
are the interfaces designed, how many drivers must implement it before
upstreaming it...
Stephane
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
