DRMPolicy

Do not read this page yet, it is not ready and things will change!

The Nouveau DRM Development Model and Policy

The Nouveau development tree is http://cgit.freedesktop.org/nouveau/linux-2.6/

The Nouveau upstreaming tree is at url-to-kernel.org?.

The Maintainer is: who?

The Nouveau development (nouveau/linux-2.6) tree and the Nouveau upstreaming tree are two different repositories due to access control. Only The Maintainer has write access to the upstreaming repository, so that Dave can pull from it.

All patches sent to The Maintainer must be made against the upstreaming tree. The Maintainer will sign and commit the patches to the upstreaming tree, from where they go to Dave Airlie and then to Linus. The upstreaming tree and Linus' tree will be periodically merged into nouveau/linux-2.6.

Nouveau development happens in nouveau/linux-2.6. Every committer, who commits a change into master, is responsible for sending the change as a patch to The Maintainer after sufficient public testing. The changes committed to nouveau/linux-2.6 should also be of Linux upstream quality.

This gives all devels the freedom to commit stuff for public testing, and the opportunity to squash, split or ignore (revert & squash) patches when sending upstream. It also offers end users an up-to-date tree for testing, as the upstreaming tree may experience latency due to The Maintainer. The Maintainer will occasionally compare the upstreaming tree to nouveau/linux-2.6 and kick all devels who have not had their changes sent to him.

Submitting patches to The Maintainer

All patches must be standard Linux upstream quality:

Additional info on patches is in SubmittingPatches on relevant parts.

The patches are sent inline in email, carefully avoiding extraneous newlines:

All patches sent to The Maintainer for inclusion in the Nouveau upstreaming tree should be either Nouveau code, or dependencies for future Nouveau patches.

The Nouveau upstreaming tree maintenance

The tree will not be rebased, and it is based on Linus' master. Linus' master will be merged on every release and release candidate(?) tag.

For each patch, The Maintainer adds his Signed-off-by. Before sending a pull-request, the tree is at least boot-tested.

How to do the pull-requests work in practise? Set up a throw-away tag (branch) for-airlied, and continue committing patches to master? Or just hold off committing to master until Dave has pulled?

What to do with DRM fixes that are published during -rc's? Just wait for the next -rc and pull that? Shouldn't be a problem for the development tree.

The upstreaming probably gets very little testing by end users?

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html 

< airlied> the rules for submitting to me are the same as the rules for submitting to him in 
           theory
< airlied> pq: I'd prefer any trees I get to be boot tested of course :)
< pq> hmm, a good question is, what happens with the devel tree, when the upstreaming tree gets 
      up; which way patches fly
< airlied> pq: and any changes outside the nouveau subdir to be pass across lists.
< airlied> you probably need to get people to take their patchse out of the devel tree and send 
           them to you
< airlied> esp if they end up being across numerous commits
< airlied> you could probably just pick patches directly out of it
< airlied> and pu them into the upstream tree
< airlied> it really depends on how clean the devel tree is
< pq> hmm, or maybe the devel tree will reduce into a compat tree, and everyone just works 
      against the upstreaming tree - or have experiments in the devel repo
< airlied> when you pull back in Linus tree you'll also have to resolve conflicts