Splitting the repos...

[Ethan Blanton]

My two cents:

(For a variety of reasons, some naming in this email is a bit fast and
 loose; when I say "libpurple", "Pidgin", and "finch", I mean whatever
 codebase ultimately became those projects.)

Gary Kramlich spake unto us the following wisdom:
> This has been brought up in devel at conference.pidgin.im recently and I'd
> like to actually discuss it here where everyone can see it.  I've been
> waiting to bring it up until I had more of the CI stuff setup, but now is
> as good of a time as any.
> 
> 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.

I do not strongly support the general split, but neither do I oppose
it.  I am rather indifferent.  Protocol plugins may be a different
story; see below.

As some here may now, back in the dawn of time when the Internet was
young and bits rarely travled with the rapidity that they do today, we
chose to split protocol logic and communication into the libpurple
library, and implement application logic and a UI on top of that as
Pidgin.  This was an obvious improvement at the time, and it led to
such large wins as finch.  However, at the time, I strongly opposed
splitting libpurple out into a separate repository with separate
release schedule.  The reasons for this were, basically:

1) There was really only one consumer of libpurple at the time (I
   think Adium and telepathy both sort of could use it, but it was a
   hack; there were also forks of Pidgin that "used" the core of
   Pidgin, maybe including bitlbee?  There were certainly no consumers
   of the compiled-and-installed libpurple, because it didn't exist),
   and that was Pidgin.  It was stupid to incur whatever overhead
   there might be in dividing up the repo in order to support ...
   ourselves.

2) Pidgin and libpurple were one monolithic project with a LOT of
   development going on at that time.  The changes taking place in the
   two projects ranged from huge UI improvements and modifications to
   source code reorganization and substantial abstraction of
   functionality.  Most changes taking place on either the UI or
   library side were accompanied by changes of similar scope and
   complexity on the other.  Decoupling the two would impose a burden
   (the overhead in point 1) on developers crossing that divide, which
   was all of us.

3) Compile times, download sizes, and package complexity were a thing.
   Bandwidth wasn't what it is now, CPUs weren't as fast, disks
   weren't as large, etc.  Furthermore dependency trees were a lot
   smaller then, and the general mentality was that small dependency
   trees were valuable.  (I don't necessarily disagree with that now,
   but it was more of a religion then!)

4) Subversion sucked.

Fast forward fifteen years, and point 1 is just plain false; there are
half a dozen packages using libpurple.  Point 2 is no longer true in
the way it was then, although some vestiges remain; for example,
Pidgin/libpurple 3 will represent large changes to both projects made
in tandem and with a lot of intertwined complexity.  However,
development in general is much more sedate, and even when it's rapid,
it's more disciplined.  Concern about download/compile times is mostly
lost to history, obviating point 3.  Dependency trees contain
thousands of packages.  Adding one dep to Pidgin to divide out
libpurple really isn't a big deal.  Finally, and thankfully,
subversion is dead.

That really leaves only part of one of my reasons from that time,
which is that decoupling the source *will* increase complexity for
developers of the primary libpurple clients, Pidgin and finch.  In
return, distro packaging and configuration logic become simpler,
particularly for users who are not installing Pidgin or finch. More
importantly, compatibility-related changes can be made to libpurple
without necessarily requiring a version bump in Pidgin/finch, and
vice-versa.  This is, for example, one of the benefits of pulling glib
out of Gtk+, and it has certainly worked out there.

I don't buy Gary's point that it levels the playing field for other
clients, even though it's true, because the *burden* on other clients
is nil (--disable-gtkui --disable-gntui or whatever, big whoop!).  The
burden on Pidgin and finch, however, will *not* be nil, so the
comparison isn't valuable.

So we should be considering internal benefits and costs, here.

> 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.

I don't care about CI artifacts, in this discussion.  The reason for
this is that it's a mistake to add additional dependencies to the
development *process*; CI is a valuable tool, but if it's considered a
necessary component to make the divide, that's bad.

But the sentiment isn't entirely invalid.  Most developers of
libpurple/Pidgin are simply *using* the software in question (e.g.,
writing protocol plugins), not developing *on* it.  For those users,
this change is a no-op, except that it may become simpler to compile
just the parts they need if they need something newer than their
distro provides.  It may not, however, if they need the whole stack.
Who knows.

CI also doesn't solve the tandem development problem, and we should
*encourage* tandem development.  Making a bunch of changes to
libpurple and then calling it 3.0 and going back to catch up Pidgin is
clearly a bad idea (and I'm not claiming that anyone is suggesting
it).  This means that as the internals are mutated, so will be the UI,
and the two will have to be kept in some sort of sync by all
developers involved.  CI probably doesn't help or fix this, because
that sync may not always be "whatever was just built right now", but
rather "whatever matches the state of my development tree".  I'm sure
that can be handled via CI, too, but ... the complexity isn't in
typing 'make', it's keeping the versions in sync in the first place.

Of course, tandem Adium/libpurple or instantbird/libpurple development
is fine, too, and may be encouraged by the split.  However, that runs
the risk of Pidgin/finch falling out of sync.  Right now they don't,
but external projects might -- after the split, they all might!

So what are the benefits to the project itself?

1) I'd like to see libgnt split out, as it doesn't change much, isn't
   really related to IM, and could very much be of use to other
   projects.  Tying its releases to libpurple (its versioning is
   already decoupled) is a false restriction.  (Of course, other
   projects *aren't* using it, and I doubt that's primarily due to the
   source tarball it's attached to, so ...)

2) Configuration complexity is fairly high, and not wholly shared
   between Pidgin and libpurple.  Dividing them up may pay dividends.
   On the other hand, replacing a lot of our home-rolled stuff with
   glib as we are for 3.x will reduce this problem, and a lot of the
   complexity is in gstreamer, which touches both.

3) Minor versions of Pidgin, finch, and libpurple could be decoupled
   to at least some degree.  I strongly doubt this would extend to
   major versions, but maybe at some point in the future; again, see
   Gtk+/glib.  This has benefits for management reasons (such as
   security implications) as well as development reasons.

4) Breakage in one part of the project might be less painful than it
   is now for people who aren't working directly on that part.

All in all, these don't add up to enough to cause me to swing one way
or the other on this topic when laid against the pain of the division.
I will not oppose either decision.

What I do oppose is moving prpls out of core, unless they have an
active external maintainer who wants to pull them out for some
practical reason.  We already have problems with prpl rot.  If a prpl
is pulled out of core, it should simply be deprecated and then removed
if no one shows up to maintain it.  We can always restore it later if
a maintainer appears.  We shouldn't move it to a side repository where
it can rot even faster, and become an additional maintenance burden.

Ethan