> > 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?
Yeah, that's what I'd expect. > Where would > the bsd specific code live? I guess it would be in the apprpriate BSD CVS or something? > What about libdrm? That should probably be in its own repo. > Do I have to setup my > own repo for the bsd parts and just try to merge stuff from the linux > tree? Yeah, although given what Dave mentioned, you'd also see patches proposed & submitted more visibly on dri-devel before going into the repo. A BSD DRM maintainer could actually setup a separate, BSD specific repo along the lines of the Linux one, and merge patches just like Dave will be doing for Linux. That might be easiest (and who knows, maybe even better than what we have currently from a BSD perspective). > 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. Sounds like the BSD camp moves its internal APIs a bit more slowly than Linux. Certainly makes things easier for driver people... > 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. If anything, I think this will actually slow down the pace of commits on the Linux side. We should see fewer, higher quality commits than under the current scheme, so with a "BSD gatekeeper" setup like I mentioned above things might even get easier... Thanks, 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
