Splitting the repos...

[Patrick Cloke]

On 4/7/16 3:06 PM, Gary Kramlich wrote:

> On Thu, Apr 7, 2016 at 1:47 PM, Patrick Cloke <patrick at cloke.us
> <mailto:patrick at cloke.us>> wrote:
>
>     Gary,
>
>     First off I'll say that splitting this out would like making
>     building libpurple for Instantbird easier, so that'd be nice...
>
>     It might make development harder, however. This is from my
>     experiences developing on Instantbird which has components across
>     3 repositories: mozilla-central (UI core, networking, security,
>     etc. from Firefox), comm-central (Instantbird and Thunderbird
>     code), purplexpcom (libpurple and XPCOM interfaces to libpurple):
>
>  Nice I didn't realize there was a purple-xpcom :)  Anyways, how is
> this different than how Pidgin has a ton of external dependencies? 
> I'm not trying to justify it, just wondering what makes this different.
>
>       * It is significantly more difficult to get new people set-up if
>         they need to pull multiple repositories and can be more
>         confusing to explain things.
>
> With packages everywhere (even dev ones) (see below) that should help
> with getting people setup.  It really just is another dependency.
Maybe, it depends how much you expect developers to be working across
the different repositories vs. treating them as blackboxes.
>
>       * Mass changes over multiple repositories can become harder
>         (e.g. renaming things, changing the build system, etc.).
>
> Changing build systems is and should be a per repo/project thing.  For
> example, Pidgin uses autotools and depends on GPlugin which uses CMake.
Maybe, but it seems like having different build systems for different
Pidgin project is not a good idea. Causes developers to have to learn
multiple systems.
>
>       * Building can become more frustrating: you need to ensure you
>         have corresponding revisions of both repositories that build
>         together.
>
>  Again, hoping to solve this with CI/CD.
I don't see how this can just be "solved with CI/CD" please go into more
details.
>
>       * People might update a single repository and forget to update
>         others (e.g. a Finch developer might make changes to Finch and
>         corresponding libpurple changes; but not update Pidgin for
>         those same changes).
>
> Not all feature will make sense in all UI's; even if they do, I don't
> think one should block another from being released.
You're taking my example too literally. What about when you want to add
a feature to multiple protocols? E.g. the new combined HTTP support that
is going into libpurple3, there's this revision mismatch which now has
to be handled by developers. It's not as trivial as it sounds.
>
>     Overall I'd say: think very carefully about why you're doing this
>     and if it will really help anything. If you plan to do this,
>     invest in some tooling around it (e.g. make it easy to update to
>     compatible versions of all repositories without thinking much).
>
> The tooling is most of the CI work that I'm doing.  I haven't spoke
> much about it publically because, well right now the time is better
> spent making it work :)  Anyways, my goal with CI is to actually make
> it CI/CD.  I still have a ton of stuff to do on the Pidgin side, but
> the GPlugin stuff all builds packages per build job.  In other words,
> who needs nighlighties :)  That said, nightlies and releases would
> already be packaged for everyone.  I'm looking at some cloud based
> repository providers (bintray.com <http://bintray.com> and
> packagecloud.io <http://packagecloud.io>) for making these packages
> available to everyone once their built.
This isn't really enough information to make me feel like you've really
thought about what I've said above. CI/CD doesn't just magically fix
these issues.
> This should actually make it easier for Instabird as well, since you
> now longer need to compile libpurple, you can just say you need this
> version from this repo.  That said, once the pidgin stuff is setup in
> CI/CD I'd be willing to pull in purple-xpcom and whatever else we can
> help you build/test.
We use a modified version of libpurple and are not API compatible, so
this wouldn't help us.

For what it's worth, many of my thoughts are from the POV of "someone
who contributes occasionally or is trying to get up and running to start
contributing", not necessarily those of core developers. Both POVs are
important to sustain OSS, however.

--Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20160407/d686f941/attachment.html>