On Friday, August 1, 2008 3:27:33 pm Dave Airlie wrote: > > 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.
As we discussed on IRC last night, I think these changes are perfectly reasonable (in fact just what I'd expect if we moved to this model). Sure, it will force contributors to be more disciplined, but that's probably a good thing anyway. I'd still like to hear from the BSD guys about how we can best keep shareable code obvious and contribution conditions clear, but so far I haven't heard any serious problems. If you're still nervous about making the move (I would be), we could consider doing a trial run of the new development model for 2.6.28, but we'd probably want to start right away if 2.6.28 really is our target. Jesse ------------------------------------------------------------------------- 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
