On Saturday 28 February 2009 05:28:38 am Pekka Paalanen wrote: > On Fri, 27 Feb 2009 23:54:21 -0800 > > vehemens <vehem...@verizon.net> wrote: > > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: > > > 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? > > > > As long as it stays on xorg, I wouldn't object as it would allow drm.git > > master to be used for leading edge development. > > Leading edge development of what, exactly? > If libdrm is moved out of drm.git, what is left is... Nouveau DRM?
Poor wording on my part. What I (and others) would like see to happen is the various branches merged into master. Having everything centralized should improve the code quality as improvements would be pooled. > What does this suggestion of "divorce libdrm" mean? Only libdrm itself, > or all the libdrm_* additional libraries too? To a single other repo, > or each (sub-)library to its own repo? The intent here would be to remove any possible objection of merging the branches into master. If this is proves sucessful, the fork would die off at some point. > btw. where is Radeon DRM development happening now and in the near > future? Do you need drm.git linux-core for anything? Any development that occurs, doesn't show up in drm.git until someone decides to share it. How and when that occurs is up to the individual. The only solution I know of is to have a project that the developer wants to contribute to. Having multiple branches in one place would result in drm.git being much more useful then it currently is. This would include linux-core. ------------------------------------------------------------------------------ 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