> > > > Personally, I only use the existing DRM repo on old kernels because that's > > how > > it's structured. It's actually more work for me to download & build a > > recent > > kernel, then update & build the DRM drivers against it that it is to simply > > update the DRM drivers and build against my current kernel (or just updating > > a theoretical DRM kernel tree & building for that matter). > > > > So really I don't think keeping compat *in-tree* for old kernels gives us > > extra testing. It's really no harder or easier to do the same thing with a > > full kernel tree, just different. IMO anyway. > > Yeah, we could keep the BC code around if we moved the drivers > in-tree, and that would let you compile the drivers against an older > kernel using something like:
First you said this :).. > > Another benefit from having the DRM repo structured as linux kernel > tree is that changes from upstream linux development (janitorial > stuff, tree-wide api changes) only takes a 'git merge' to carry over > to the DRM tree. In other words, making it easier to push changes > upstream works both ways, it also becomes easier to pull down changes > from upstream that touches the DRM subystem. Hm, I guess that's what > your saying in 4). Then this, the thing is to keep it building you need compat code, code that can't go into Linus tree, so we end up with a tree that isn't like Linus tree, and we still have to patch manage transitions so we don't save anything doing this over what we have now. > > So, I very much agree with your proposal and don't feel I can add > much, except to point out that a migration to in-tree drm development > doesn't need to be a big and painful process. Basically, we just > decide to do it, and designate a kernel tree on freedesktop.org that > we work from and start with the current state of upstream drm. There > will be some work in moving things over from drm.git to the kernel > tree, but we were going to do that *anyway* as part of getting it > upstream. What will be different is that Dave won't have to do all > that work, we can split it up between us and all Dave will need to do > is to merge the branch and push it to Linus. This is of course what > Eric is already doing with GEM in people.fd.o/~anholt/linux-2.6, and > that would be a great way to get the vblank rework upstream too. If we do this, I'm going to introduce new rules for features/patches that will put a lot more work on people. 1. Nobody gets commit access to master branch except me. 2. All work is done in topic branches that are throwaway once complete. So when the branch owner decides the work is upstreamable, They create a set of clean patches against the current master, send them to dri-devel for review, if they pass review then the branch owner creates a new clean branch and asks me to merge it, it also includes Signed-off-by lines. Some people say we want the history, Linus wants bisectable history so invariable when a feature reaches a useful stage it should go upstream in clean s-o-b patches that are bisectable and pass checkpatch.pl, not in a 50 separate patches with fixes in it. We can generate a throwaway drm-next tree that merges all the topic branches currently in play if people want to have some superview. 3. All API changes to go to the list as soon as possible (should be done now). I'm sure I'll think of some more. 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
