On 12/23/2010 8:44 AM, Mike McQuaid wrote:
On 23 December 2010 13:24, David Cole<david.c...@kitware.com> wrote:
How do we make it very hard? What about KDE and Homebrew make this very
easy? Specifics, please.
I think for you guys general guidelines on what patches would/wouldn't
be accepted would be a good start. Documentation of your coding
standards and what I should do to test my work before submitting it
would help too. I can guess a fair amount because I've contributed to
a lot of open-source projects but others might not do the same.
I think the main thing that I find lacking here though is
responsiveness to suggestions. When I make one, I need to keep poking
again and again until I receive I response. Other things include
specific code review of patches and a quick "this functionality
would/wouldn't be accepted" when suggestions are made so I know
whether to work on it or not.
I think using Git/Github in your workflow could help with part of this
but a certain amount will need to be responding to users, either
through your current bug tracker, a better one or Github's issue
tracker.
Another option that might help is a cmake-dev mailing list that is
only for discussing development issues rather than users seeking help.
Something like this perhaps:
http://www.cmake.org/cmake/help/mailing.html
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
The way I see it, there are two types of contributions.
1. You have already written some code that does something you need for
your project.
2. You have a suggestion for a change that you would like to see but
have not done.
These two cases are treated differently. Here is the workflow I would
would like to see for them:
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.
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.
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.
In summary, Kitware and the CMake developers outside Kitware have been
working on being more inclusive. We realize that our process needs to
include more of the community. Recently we have made several changes in
order to include more outside help on the CMake project. Those changes
are as follows:
1. We moved to git
2. We moved to a quarterly release schedule.
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.
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.
Thanks.
-Bill
_______________________________________________
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
