On Fri, 2008-08-01 at 15:45 -0700, Jesse Barnes wrote: > 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.
Well, I'm only like a third of a developer, but I'll give it a shot. You are correct that the most important thing for me is being able to readily identify what code is or should be portable and licensed appropriately. I suppose in many ways this is easier for oga to swallow because he already works in his own tree. I however work entirely out of drm.git and just drop that into our cvs/svn tree for releases. If we move to a linux tree, does that mean that I will have to pull a full linux git tree and then try to hand pick the drm bits out? Where would the bsd specific code live? What about libdrm? Do I have to setup my own repo for the bsd parts and just try to merge stuff from the linux tree? I want us to be able to move as quickly as we can to deliver new features and functionality, but I see this move as just another step towards making drm even more linux-centric. As for BC, as the code stands now, the bsd side of the house has a few ifdefs that enable certain features from certain releases of bsd, but it pretty much can just drop into any 6,7,8 release as-is. That may become more of a pain as I try and rework various code paths taking advantage of newer features, but for now it mostly just works. I realize that some of the new features KMS and GEM are relying much more heavily on specific kernel features, which already makes my task daunting. I don't think that anyone is intentionally trying to make things more difficult, but I don't see how this move doesn't make it even more difficult for me to try and keep pace with linux crowd. I know I need help already and if I have to keep up with every patch and bugfix that goes in and cherry-pick it, I won't have time to do much else. robert. > 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 -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
