|| ||Robert Noland <rnoland-AT-2hip.net>|
|| ||Dave Airlie <airlied-AT-gmail.com>|
|| ||Re: DRM development process wiki page..|
|| ||Tue, 26 Aug 2008 23:02:44 -0400|
|| ||dri-devel <dri-devel-AT-lists.sourceforge.net>|
On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
> Okay I've put some thoughts up at:
> 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).
We all have our religions. ;) This is the most fair of any of the
proposals I've seen or heard. I am certainly willing to compromise, but
even this proposal converts the project from what has historically been
a collaborative effort (yes, I know) into a linux project that merely
tolerates renting a subdirectory in the repo to BSD. I'm honestly about
ready to throw in the towel. While I have been slowly raising awareness
in FreeBSD circles with my frequent pleas for help, I just don't have
enough voices to influence the outcome. I have been getting some
attention from far more qualified developers than myself lately, but no
commitments for substantial work have yet been made. I already know
better than to commit infrastructure changes that impact linux, even if
they fix obvious bugs. The linux side of the house is not held to the
same standards obviously. Jesse and I, have a reasonably good track
record of collaborating early enough that we have been able to commit
working code at very near the same time. I am having a really difficult
time seeing what benefit I get from continuing to work in drm.git with
this proposed model. While all commits to master going through the
mailing list, I don't anticipate that I have any veto power or even
delay powers until I can at least prevent imports from breaking BSD.
Then once I do get it squared away, I'm still left having to send those
to the ML and wait for approval to push the fixes. I can just save
myself that part of the hassle and work privately. If I'm going to have
to hand edit and merge every change, I don't see how it is really any
harder to do that in my own repo, where I'm only subject to FreeBSD
rules. That way, if I need to make a change to infrastructure to fix
issues, all I have to worry about is maintaining ABI/API compatability.
We all want nice pretty pristine code in our kernels and if I can't
easily import the shared code it just isn't worth it. I can get testing
on our -CURRENT branch, at least for things that aren't inherently
sketchy. I'm probably more likely to attract other developers attention
if I'm working in our tree anyway.
Generally, most everyone has always been helpful and I do really
appreciate that and hope that continues to be the case.
> 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...
> 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
> 3. Macros for BSD compat to wrap Linux APIs. So we minimise the
> nightmare of macros in driver code. no more DRM_ if they can be
> 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.
> 1. For large features or new drivers create a new branch in drm tree.
> Stay in the branch, these branches will never ever get merged ever.
> ever. When the developers feel the branch is suitable for upstream,
> they need to create a clean set of patches following the rules above.
> All API additions need to be reviewed and feedback taken on board. If
> this involves another round of development, nuke the old branch and/or
> start a new one from the patchset. Repeat cycle. When patches are
> approved by anyone who cares they will get merged into the drm master
> and into the upstream drm-next queue. Backwards compat patches will be
> merged into drm master.
> 2. For minor cleanups and fixes, patches should be sent to dri-devel.
> 3. If a patch gets reverted from upstream kernel for a regression it
> will also be reverted from the drm master branch.
> 4. If someone gets in the queue and you conflict you get to keep the mess.
> 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.
> 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
> 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
> Dri-devel mailing list
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
Dri-devel mailing list
to post comments)