Re: State of Pidgin: Splitting the Tree

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
own thing/repo/plugin?

On 3 October 2017 at 18:58, Gary Kramlich <[email protected]> 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 <[email protected]>
>
> _______________________________________________
> Devel mailing list
> [email protected]
> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>

_______________________________________________
Devel mailing list
[email protected]
https://pidgin.im/cgi-bin/mailman/listinfo/devel