Dave, This process looks ok to me, but I think some clarifications are needed:
Dave Airlie wrote: > Okay I've put some thoughts up at: > http://dri.freedesktop.org/wiki/DRMProcess > > and I've pasted it in below this for discussion. > > some other points: > > a) People are pushing for a process change, we will have something > change, however this isn't a who shouts loudest competition, so more > than likely you'll end up compromising, deal with the fact that > nirvana for you may be hell for others. > > b) BSD developers do exist now, giving out that they didn't exist in > the past or aren't adding features is pointless. Would you seriously > start developing features before > getting the code caught up?. So live with the fact that we should help > the BSD guys *if* its practical. So we shouldn't do anything major > that alienates their further development. > (personally I care little for BSD, the license or the OSes, however > I'm attempting to be some way fair). > > c) We get testers from drm master, we get better testers using drm > master for features than a separate kernel tree. We get better > regression tests from getting stuff upstream. However upstreaming > stuff to Linus is not how to find regressions, it helps but its > suboptimal in that he will eventually ignore us if the regression rate > gets too high. So upstreaming is great for features like GEM, however > it would suck for something like vblank-rework. This appears to point > at, upstream is great if you touch one driver and exist in your own > world, however if you want interfaces that all drivers can use like > vbl-rework you need to work somewhere else or carry two interfaces > until everyone is ported. > > So lets see if we can improve this for everyone... > > Dave. > > > DRM Development Process (Proposed) > > ... > 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. > > Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a "new" driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? > 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. > Are driver-specific IOCTL interfaces included in this? Regards, Thomas ------------------------------------------------------------------------- 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
