On Tuesday, August 26, 2008 5:15 pm Dave Airlie wrote: > DRM Development Process (Proposed) > > 1. Master branch in Linux tree style with links for BSD etc. > > 2. Always compatible with current release Linux kernel + with > backwards compat *where* practical for older kernels. We should > probably limit the back compat to like 6 kernel revisions or > something.
How will these patches be managed? Will they only live in DRM master? Or will they be upstream as well? > Patches > > 1. All patches to be sent to the mailing list with S-O-B, no patches > to be committed to master branch. Nothing goes upstream or into master > without Signed-off-by and maintainers Signed-off-by. 2. Do not mix > cleanup and developement ever. If you move a bunch of registers or > code into a separate file, do just that in one patch. 3. Backwards > compat patches in separate patches. So first patch should be > upstreamable, backwards compat patches should be in sequence. > > Upstream first policy > > This policy places a restriction on users of the drm, i.e. Mesa, DDX, > X server. No upstream release should include code that hasn't been > included in a Linux kernel release cycle. Upstream can use a > --enable-experimental-kernel-api type flag but default build should > never require any unreleased kernel/drm API to build or run. Distros > should not enable experimental APIs in releases, unless they are > willing to version their kernel and other components against each > other and deal with the fallout of API changes. > > All userspace APIs need to be submitted to dri-devel and to the Linux > kernel list, also all patches which need exports or use new non-drm > kernel functionality should be reviewed by both lists. > > Note: Do not expect because your code works that you won't have to > re-write it all for upstream. So upstream ideas early esp when you > interface to other kernel components. This sounds great. Sure it'll probably slow things down, but it should also ensure that features actually get out into distributions and that the APIs are relatively sane. > DRM tree layout (plans) > > 1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2. > Add backwards compat cleanly on top of this tree with some patches. 3. > Add BSD compat in places that need it. 4. Migrate BSD to using the > upstream src files instead of the shared-core ones. 5. Evict all > non-upstream patches to branches, currently > > * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface. Yay! This means I'll have to do a bit of archeology to port stuff forward, but it's well worth it, imo. > Suggestions + help needed > > In the future we may find we need a transitory drm-testing branch that > merges all the currently in development branches. This might help in > resolving conflicts before they happen. It would be nice to tinderbox > build the drm mainline and drm-testing against the last 6 released > kernels. On Linux at least, some subsystems do this with their linux-next branch. They pull in all the various topic branches that may or may not get into the next Linus release in order to get build & (some) test coverage. Overall this looks really good to me; it seems like it will address the weaknesses I've seen with the current model. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------- 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
