State of Pidgin: Attracting and Maintaining New Contributors

[David Woodhouse]

On Thu, 2018-03-15 at 12:42 +0100, Matěj Cepl wrote:
> Looking at it from this point of view, I really do not see 
> bright future for Mercurial (perhaps Facebook can save it, but 
> I wonder whether and when they will rather fix git or build some 
> tooling on the top of the git to make it work for them, after 
> all Microsoft did just that).

I understand the argument that people should have the *choice* to use
Mercurial, if they want to. I've no problem with choice.

I don't quite understand why anyone would *want* to use Mercurial, but
fine. I am reminded of the line from Monty Python's Life of Brian — "we
shall fight for his RIGHT to have babies!".

But really, the problem for Pidgin is exactly the opposite way round.
At times it looks like we're being *forced* to use Mercurial, instead
of the common tools that we're familiar with.

We are told that submitting patches by email or attaching them to
tickets isn't acceptable and we *have* to make a PR in Bitbucket.

When we do that using the common git-remote-hg tools, there are
complicated Mercurial-specific things about branches vs. bookmarks
which mean that the simple approach is "wrong". I think git-cinnabar
improves that slightly but still I *think* I need to clone a completely
new repo on bitbucket for each simultaneously open PR, because of the
'bookmark' vs. 'branch' thing.

There's no clear documentation on *how* to use the common and familiar
tools to create an acceptable PR, which is hardly a good way to
encourage drive-by contributions. 

The feedback we get is "just use Mercurial natively". Which isn't
really offering much choice, now is it?

And frankly, it's crazy talk. This is 2018. I'm not about to go and
(re)learn — and teach my fingers the muscle memory of — the command
line interfaces of RCS, CVS, Subversion, Mercurial, Bazaar, TLA or any
of the other legacy version control systems. Nobody really is, unless
you really make them believe that they have no choice, *and* they care
enough about contributing that they are willing to make that additional
investment of time and effort so that Pidgin can be "special".

We should be *reducing* the barriers to contribution, not increasing
them. Even if the git-remote-hg/git-cinnabar process was simple and
clearly documented, even "you have to go and make an account in
bitbucket" is more than we should have in an ideal world.

I work with other projects like LLVM which for legacy reasons aren't
using git either. But there's an official git tree shadowing SVN, and
it's relatively easy to submit patches. Nobody tells me "you MUST
actually use subversion on the command line".

Pidgin has regressed in that respect. It *used* to be possible to work
with git-remote-hg and push to the repository, and it wasn't as painful
as it is now. With the move to Bitbucket, it seems that stopped working
in the same way, and now it's much harder.

I will *attempt* to document what it takes to make viable PRs, but I'm
not entirely sure I know, even now. And it's taking time that *could*
have been spent on actually fixing stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <https://pidgin.im/pipermail/devel/attachments/20180315/da39ab4d/attachment.bin>