State of Pidgin: Splitting the Tree
eion at robbmob.com
Tue Oct 3 03:00:05 EDT 2017
I'm a big fan of doing a split. In particular, I think it would really
help out other UI's to separate the Pidgin/libpurple codebase, as a lot of
pain points they deal with, Pidgin sidesteps by having tight coupling with
libpurple (e.g. see the Instantbird patches). The only pain-point I see
would be making sure newer Pidgin's can handle older libpurples; more
version-checks and stuff.
Would this include splitting the voice/video stuff from libpurple into it's
On 3 October 2017 at 18:58, Gary Kramlich <grim at reaperworld.com> wrote:
> Greetings Programs!
> If you have not yet seen the introduction email with a subject of "State
> of Pidgin: Introduction", please go read it first.
> I've mentioned a few times now that I believe we need to split the tree
> into at least four separate repositories. My proposal is to split it into
> libpurple, pidgin, libgnt, and finch.
> I firmly believe that right now that any convenience of having everything
> in the same repository is actually more of a disservice to each of the four
> distinct projects in the current repository.
> Splitting the repository gives us some benefits for each individual for
> each project individually. The biggest of which is smaller and more
> focused releases that can't get blocked by the other projects. It also
> gives us the ability to bring in other maintainers that would focus on that
> repository specifically. This is by far the biggest benefit I see from
> splitting the repository. I don't expect this to happen immediately, but
> having the possibility to do it will better serve that project in the
> Splitting libpurple into it's own repository makes it easier for packagers
> and third party user interfaces to work with libpurple. The natural
> division that we would create would avoid any confusion around what
> dependencies are libpurple and which are Pidgin. It would also force us to
> make sure that no UI code will ever reach libpurple.
> Splitting Pidgin into it's own repository allows us to focus on that UI
> specifically and improve it. And let's face the facts here, while Pidgin's
> UI is fully functional, it is very much showing it's age. By splitting
> this, Pidgin becomes just another Gtk+ application which happens to talk to
> a library that does all of the heavy lifting. This lowers the barrier to
> entry quite substantially.
> Since the creation of libgnt I've been saying it should be in it's own
> repository. This is due to many reasons, but I've only become of the
> biggest one recently. libgnt has basically zero exposure. I know a few
> finch users who happen to be developers and they had absolutely no idea
> that the UI toolkit was a separate library that they could use in their own
> projects. By splitting this out and promoting it as a Gtk+ like toolkit
> for ncurses it can develop it's own community and continue growing instead
> of hiding in the shadow of the Pidgin repository.
> Like the other three, Finch will benefit from a focused approach to it as
> well. Like libgnt, Finch also suffers from a lack of promotion. By giving
> finch it's own spotlight it can grow in the ways its users and developers
> need it to grow.
> There is still the question of where, if we decide to split these
> repositories, they should go. A quick search on Bitbucket shows that the
> team names for finch and gnt are already in use. However, we could put
> them under pidgin or the imfreedom teams on Bitbucket.
> Please discuss.
> Gary Kramlich <grim at reaperworld.com>
> Devel mailing list
> Devel at pidgin.im
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel