On 23 December 2010 14:30, Bill Hoffman <[email protected]> wrote: > Something like this perhaps: > > http://www.cmake.org/cmake/help/mailing.html > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Excuse my extreme ignorance, I had no idea that existed. Subscribing! > 1. you have some code. > The biggest thing that slows down adoption of new code in CMake is lack of > testing. New features that are not tested, are not welcome into CMake. If > the code has a CMake test and there is good dashboard coverage for the test, > then the code will be adopted much quicker. The code can be done on github > or gitorious.org, or just a patch attached to a bug entry in the CMake bug > tracker. If a cmake developer can just merge in the code, and run ctest to > test the new code, it makes it very easy to commit. Ok, that's good to know. So the basic use-case should be to write the code, write a test that runs it and ensure it's hooked up to ctest, make sure it passes and then make a merge request detailing the above. A few questions: What platforms does it need to be tested on? What branch should you base it off? I wasn't sure if you guys looked at the merge requests on Github/Gitorious, that's good to know. > 2. You have a suggestion for a change but no code. > I think there are two sub-cases for this as well: > A. You are willing to write the code yourself. > B. You think that someone else should write it for you. > > For A, you would want to get buy in from the developers and community before > starting the code. For this the cmake-developers mailing list would be the > place to start. Although, sometimes it might make sense to float the idea > on the cmake mailing list first to see what the community things, and then > use the developers list for implementation details. Ok, great. > For B, you have to do a pretty good sales job for the work to be done. You > are basically asking for a handout. Kitware does not directly invest in > CMake, new features developed by Kitware come from Kitware customers > requesting them. So, you can hire Kitware (become a customer), or if your > suggestion lines up with the needs of an existing customer, you might get > lucky. Of course Kitware people are not the only ones developing CMake, you > might be able to convince someone else to do the work. Either way, this is > the hardest type of change to have made. Sure. I'm not in this group as I'm happy to do the work myself but that's good to know. > 3. After each release we send out and email to the cmake and > cmake-developers list, and ask for people to suggest the things they would > like to see in the next release. Here is the current list: > http://public.kitware.com/Bug/roadmap_page.php. Next release is scheduled > for Jan. 10. Cool, again, good to know. > 4. We have directed all new bugs on the bug tracker to the cmake-developers > list. This allows all developers to see new issues as they come in. > > 5. We have made an effort to clean up old stuff in the bug tracker. > > > So, if you have time that you want to spend on CMake development, join the > cmake-developers mailing list. Write some tested, documented code and > contribute it. Great, I think I understand how to do that a bit better now. It would be great if the contents of your email above was included here: http://www.cmake.org/cmake/project/getinvolved.html and also possibly on your Github/Gitorious pages. Thanks for the comprehensive reply and sorry for any criticism from my misunderstandings above. -- Mike McQuaid http://mikemcquaid.com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
