[CMake] CPack 101

[Michael Wild]

On 12/23/2010 02:44 PM, 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.
> 
> Firstly, http://producingoss.com/ is a great read.
> 
> Specifically though, Homebrew is pretty much the golden child of
> encouraging external contribution. We're the most forked repo on
> Github, the 6th most watched and have had 719 code contributors in
> about a year and a half of existing. We've managed this with only 4
> people with commit access, all of whom have full-time jobs in the
> industry working on other projects.

Well, I also did some contributions to homebrew, and I have to agree
that patches get picked up really quickly. There's one big "but",
though: Writing a formula is fairly simple. Just copy an existing
formula that is similar to your favourite package, adapt it, build,
commit and push. Many contributions are even much simpler: just update
the version number, done. The learning curve is extremely low. Also,
Homebrew is Mac-only, so contributors don't have to worry about all the
exotic platforms out there. They are geeks and nerds who like to build
stuff themselves. I'd bet that almost everybody using Homebrew is also
contributing to the formulae, but I'm very sure that only a select few
actually ever even take look into the internals and supply patches to
this part of the project.

With CMake the situation is more complex. You have three distinct user
groups: (1) People trying to build the software on their machines. They
do not care whether the build system is CMake, SCons, Ant, autohell or
just plain Make. They just want it to work. (2) Developers who use CMake
as their build system of choice and (3) people from the second group who
got annoyed enough by some missing feature or a bug to make the step and
contribute a patch.

Now, the real complication is that CMake must support a large array of
esoteric hardware and operating systems, to which most of the people do
not have access to, or even don't know about, so they can't even take a
guess at potential problems. Also, if you want to get something into
CMake, you have to provide a test and documentation, both of which are
tedious and not very attractive tasks. Also, the CMake code base is
much, much more involved.

There are probably quite a few more issues which make it a lot harder to
contribute to CMake than to Homewbrew.

> 
> I think Github and DVCS really allows you to scale well. If you
> publish decent guidelines for how people can contribute and use e.g.
> pull requests on Github or similar Git mechanisms then you can have
> incredibly quick workflows for viewing, mergeing, testing and pushing
> user code.

That's already there:

http://www.cmake.org/Wiki/CMake/Git
http://public.kitware.com/Wiki/Git/Workflow/Topic

You can also just publish a topic-branch on GitHub and then put a
pull-request in the bug-tracker.

> 
> I have an alias "bpi" in my shell which downloads from a pull request
> or user repository commit on Github, applies it to my local
> repository, shows me the changes and installs the relevant changes
> packages. Once I type "git push" this is now shared with everyone
> using the project.
> 
> 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 almost everything that fits into the CMake-picture would get
accepted as long as it meets the quality standards, is documented and
tested. Also, FindXXX.cmake module need a maintainer who commits to
keeping them up-to-date and fixing issues that crop up.

> 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.

Agreed. Sometimes the response is a bit disappointing. But this probably
also has to do with the fact that one's personal pet-itch isn't as
important to other people as one would like it to be ;-)

> 
> 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.

IMHO Github's issue tracker is far below par. CMake uses Mantis which is
much more powerful, but likely also not to everybody's liking. It
certainly is a bit more complicated to submit a bug report in Mantis
than in the Github tracker.

> 
> Another option that might help is a cmake-dev mailing list that is
> only for discussing development issues rather than users seeking help.

Ummmh, you mean this?
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

> 
> Just a few ideas for you. Hopefully some of them are useful. I'm more
> than willing to discuss this in further depth, either here, personal
> mail or at an open-source conference (next one I'll definitely be at
> will be the KDE one in Berlin 2011).
> 


That said, I think it has become much easier to contribute than in CVS
times. That was just a PITA. But there certainly is room for
improvement, I agree with that. For one, the Wiki is plain inaccessible.
E.g. above mentioned CMake/Git Wiki page is completely isolated. Nothing
links there! Also, the Git/Workflow/Topic page is only reached from (1)
this isolated CMake/Git page or from the ITK development documentation.
Then, there is a clear lack of documentation on how to prepare a new
test. Looking into the existing tests doesn't really help (at least that
was my impression), as most of the stuff is so convoluted, it takes
hours to pick apart.

> 
>> Thank you. Even with more external developers, I think we'll struggle --
>> that would just be a different sort of struggle.
> 
> Sure, it will probably involve more reviewing/mentoring but less code writing.
> 
> 
>> Again, let me stress, no offense taken. There is no way you can offend me,
>> unless you start calling me names for no reason. Reasonable discussion
>> always welcome.
> 
> So can I call you names as long as I have a good reason? ;)
> 


I just realised how long winded this message is, but it's too late and
too close to Christmas for me to bother, so please excuse this (mostly)
inconsequential drivel...


Michael