Dave Airlie wrote: > On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström > <[EMAIL PROTECTED]> wrote: > >> 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? >> > > Yes I'd be happy with that, of course I'd also like the development to > occur in the open. > If someone else were to start working on something in the open that > others were working on under contract or in secret, then I'd expect > the contracted group to merge to the open stuff.... >
Yes, that sounds fair. I guess at least the very least should be a common understanding with the people actively working on the open stuff on what to keep and what not to keep. > >>> 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? >> > > Yes, any userspace API, anything we need to support for ever and ever. > That's really the point that this may or may not be the same thing. The old drm model placed a driver's user space interface under versioning, and any app using that interface would need to monitor the major version number to check for compatibility, although major bumps were strongly discouraged. /Thomas > Dave. > ------------------------------------------------------------------------- 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
