> > Well, if the overhead of merging upstream is a concern, then how about > not worrying about bc at all and let people who want to back port deal > with it? Oh, and what about just keeping the drm drivers in a linux > kernel tree? That'll make upstream merging even easier yet...
The less crap I have to remove from the diffs the better, I have a script and it removes stuff mostly fine, maybe someone should actually bring this idea up on the list with a proper plan for how to deal with a) BSD b) backwards compat for using updated DRM drivers on older kernels. If someone writes a coherent proposal I'm all ears, all I'm hearing is "other kernel subsystems", but on my review 2 other kernel subsystem have a major userspace part to worry about, alsa and v4l. They both developed in out-of-tree with backwards compat code. If enough DRI developers are willing to take the stand that they don't care about a or b, then I'm willing to change the development model. So far I've hear grumbles and mumbling, where I expect coherent proposal or gtfo. The biggest thing I have against this is that it cuts our testing base down, we have a small testing base already, cutting it further jsut to benefit some developers who are frustrated isn't really a gain. Dave. ------------------------------------------------------------------------- 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
