Prompted by how well it worked with Intel, and changes in my personal life leading to reduced time availability (except at 4am...) I'm going to clarify the process for getting patches upstream now. (a...@amd also trialed this to get r600 upstream).
1. Apart from maybe minor changes I will no longer pull drm.git patches into Linux kernel tree automatically. 2. All patches should be sent to dri-devel and me against my drm-next tree. 3. Patches must conform to kernel coding standards and have acceptable checkpatch.pl results. My only major issues with checkpatch.pl is 80 char line length restrictions, please try your best but don't make the code really ugly to achieve this. Some scripts/people are too anal. This also means no kernel version checks upstream (however we might be able to convince people about this, if we get build from Linus tree working). 4. I will accept sub-module maintainers who want to maintain their driver in a git tree, but it'll take a bit of time for me to trust you that I'll pull directly, and patches should still pass by the list. Ask Eric how to do this. 5. if someone wants to step up and maintain drm.git as a going concern let me know, I'm glad to help if I can. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
