Splitting the repos...

David Woodhouse dwmw2 at infradead.org
Thu Apr 7 18:31:19 EDT 2016

On Thu, 2016-04-07 at 09:19 -0500, Gary Kramlich wrote:
> As you may or may not know, I strongly support splitting the repo
> into libpurple, pidgin, libgnt, and finch repos.  I would also like
> to split out some of our less commonly used protocol plugins (namely
> meanwhile and zephyr) to separate repos to get the dependency and
> build complexity down.
> For most developers, this means you'll have to build an libpurple and
> or libgnt separately.  However, once all of the CI stuff is setup, if
> you just want to work on pidgin or finch you shouldn't have to
> compile libpurple and libgnt separately anymore since you can pull
> them out of the CI artifacts.
> At any rate, discuss! :)

I don't really feel strongly either way, which is probably just as well
since I'm not really qualified to have a strong opinion either.

But a few thoughts.... firstly, I don't think CI is going to help.
Right now, if I want to work on Pidgin 3.x while my distro is shipping
2.x, I'm going to need to build and install everything locally in
/opt/pidgin3 or something (which is what I already do, so no real
change there).

I'd note that Evolution has a similar split, between Evolution the GUI
and Evolution-Data-Server the back end. It *theoretically* allows
separate and parallel development. In practice it's a complete fiction.
Evolution and EDS versions are released in lockstep and a given
Evolution version will have a dependency on the *precisely* matching
version of EDS, because no attempt is really made at maintaining a
stable API/ABI and keeping track of when the dependencies needs to

There's a lot more to a *meaningful* split than just separating
different directories out into different repositories, and it hasn't
been clear from the rest of the discussion that this is *really* going
to happen. Which makes me suspect that the split isn't going to be
stunningly productive.

If we really *are* talking about separating out libpurple and other
bits and letting them develop at their own pace though, then that seems
reasonable. Just don't underestimate the work involved. And let's have
a proper discussion about library and symbol versioning, etc.

I'd *strongly* suggest that we finally come into the 21st century and
allow C99 structure initialisers in the protocol plugins though, if
they're going to be developed out-of-step with libpurple. That whole
"count the NULLs" crap from the 1990s is a constant pain and it
*already* leads to problems, which are only going to get worse.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <https://pidgin.im/pipermail/devel/attachments/20160407/9d580e2c/attachment.bin>

More information about the Devel mailing list