Splitting the repos...

[Gary Kramlich]

On Thu, Apr 7, 2016 at 2:14 PM, Patrick Cloke <patrick at cloke.us> wrote:

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

I Wouldn't expect many to be going across multiple repositories.  I mean
it'll happen, but it's no different than working on something in GTK+ and
then realizing you need something in Glib.

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

I agree, I was making a point that dependencies aren't all going to have
the same build system.  Pidgin and Finch should really be dealing with the
same pains that Instantbird and Bitlebee do

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

Bamboo outputs artifacts that are package repositories for the target
system.  The users (including developers) add them to their system's
package manger.  You target a version and work against it.  Similarly to
the above, this is no different than trying to target a new Glib or GTK+
for Pidgin.

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

Again, we shouldn't be treating Pidgin and Finch any different than
Instantbird or BitlBee.  That would mean that the feature would get added
to libpurple, and after it lands it would be implemented in Pidgin and
Finch, just like what would happen with Instantbird and BitlBee.

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

I'll see if I can't get a design doc thrown together this weekend.  For the
record, this is a problem I've been trying to solve for a very long time
and I finally believe I have something that actually works for FOSS
projects that are targeting multiple versions of multiple platforms.  That
said, the tool isn't the best, but it's workable.

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

I believe this is the main source of contention here.  Have we discussed
implementing your changes upstream before? If so, maybe it's time, if not,
then lets talk about it and see if we can't get you using vanilla libpurple
that has the stuff you need.  When that's the case, that should make your
development much easier.

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

Agreed, and I appreciate your input :)

--Patrick
>

Thanks,

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