[CMake] CPack 101

[Bill Hoffman]

On 12/23/2010 8:44 AM, Mike McQuaid wrote:
> On 23 December 2010 13:24, David Cole<david.cole at 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