Bill Segall wrote: > > # emailing your commits to the mailing list > > git send-email origin/master.. > > > > # ..or pushing to github > > git push github local_branch_name > > You're right. There is effectively no difference between these two except > .... > > 99% of developers know about the push and have never used send-email.
I think the onus is on developers to educate themselves about the tools they use, rather than on projects to conform to what people are used to consume from GitHub Inc. Now don't get me wrong, some things on github.com are nice, but I still wouldn't go near them as infrastructure provider. It's nowhere near worth it for me. > After the send-email some fraction of the developers engaged enough to be > on a mailing list might be motivated enough to download and have a look at > a patch but we've already presented a barrier to entry, cos it's not just > click to look. I don't know about your mail program, but mine show patches sent to the mailing list right then and there - because they double as emails. That seems much less of a barrier; no need to click on anything. > And once we look at the patch, we get a lovely color encoded web view, Indeed a mailer doesn't really do that. > we get to see the developer stats and their activity. Who cares? I think the patch is more important. > If I'm doing especially well, the CI system might have shown me that the > patch compiles, that the tests passed and that it even fixed an existing > bug. CI is nice, but by no means exclusive to github.com. In fact, you would probably have to rely on a different service provider. Or a volunteer could set up our own. > To adopt the patch one of the chosen few might be able to click and accept > it so we don't get emails that complain they posted a patch to the mailing > list 6 months ago etc. I like piping emails to git, but my experience is that very few patches can actually be applied without further work, so some back-and-forth communication is neccessary. E.g. email. Or I guess one could choose to use Facebook. > And it's there for people to find, adopt, fork, improve, contribute > further to at lower cost. I disagree that only github.com provides that, or provides it best. > The point I'm making is that Sure, but.. > engagement, ..this is much easier said than done. Regardless of github.com or libssh2.org actual humans need to engage and manage contributions. libssh2 like pretty much every other project is understaffed, and no colourful web page will change that. > process, The self-hosted process with patches on mailing lists works really well for a large number of projects, including the Linux kernel. > and visibility (the UI thing) Being understaffed, it's important for the processes to be efficient, and email is both efficient and visible. The list and its archives are public, the bug tracker is public, the repo is public. > People these days have an expectation Maybe they should have fewer expectations and make more contributions? > if you're not meeting and hopefully exceeding those expectations > you're losing the one currency that matters which is developer > engagement. We can only speak about "losing" if we have had something, and as I wrote, this project, like all others, is understaffed. Using github.com (or any other!) services isn't magically bringing qualified contributors into the project. Your reasoning makes perfect sense for a startup trying to be the hippest in order to attract and keep developers who might care more about appearances (visibility) than about actual code. That's not really what libssh2 needs. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
