[CMake] CPack 101

[Mike McQuaid]

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.

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.

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

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


> 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? ;)

-- 
Mike McQuaid
http://mikemcquaid.com