On 12/23/2010 02:44 PM, Mike McQuaid wrote: > On 23 December 2010 13:24, David Cole <[email protected]> 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 _______________________________________________ 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
