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
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
..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.
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
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.
Received on 2015-03-10