State of Pidgin: Splitting the Tree

[Gary Kramlich]

On Tue, Oct 3, 2017 at 2:00 AM, Eion Robb <eion at robbmob.com> wrote:

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

Awesome!  We do enough version checks right now between glib and gtk that
adding a few more for purple really shouldn't be a big deal.


> Would this include splitting the voice/video stuff from libpurple into
> it's own thing/repo/plugin?
>

Perhaps.  That entire API needs an overhaul badly.  Unfortunately we need
someone that really knows the GStreamer stuff..  Unless of course we can
figure out how to just pass around GStreamerSinks and GStreamerSources.


>
> 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
>> future.
>>
>> 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.
>>
>> Thanks,
>>
>> --
>> Gary Kramlich <grim at reaperworld.com>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at pidgin.im
>> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>>
>
>


-- 
Thanks,

--
Gary Kramlich <grim at reaperworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20171003/bb72c14d/attachment.html>