On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie <airl...@linux.ie> wrote: > > 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.
Sounds good to me - one question: should we divorce libdrm from the drm.git repo? cheers, Kristian ------------------------------------------------------------------------------ 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
