Moving libdrm out of drm.git seems like a good idea to me. Sure they are different sides of the same coin but drm and libdrm should have their own physical git repos. It makes things a little cleaner in my eyes. It also makes things easier for git noobs.
-Ryan On 2/28/09, vehemens <vehem...@verizon.net> wrote: > 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 > ------------------------------------------------------------------------------ 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
