[GSoC] Merge branches (to all GSoC students)

[Ankit Vani]

Hi Tomasz

On 28 September 2013 17:39, Tomasz Wasilczyk <twasilczyk at pidgin.im> wrote:
> - Is your code building on win32? The current main branch does.

I haven't tried it yet, will do it now and report as soon as I have a working
windows build.

> - Is your branch compiling without any warnings?

I have warnings, but not regarding my changes. I have them in the main branch
as well (I had sent you a log).

> - Generally: don't break things. Are there any TODOs in your code that
> removes some previously present functionality? Maybe something doesn't
> work as previous, because there is some more work to be done?

soc.2013.gobjectification does not remove any previous functionality.

However, soc.2013.gobjectification.plugins removes plugin IPC (which can be
handled by other things such as GObjects and signals).
Another thing removed in this branch is the ability for finch to install
plugins by selecting a custom file. GPlugin does not support loading files
from custom paths - it only probes plugins added to the configured search
paths.

Another change I should mention for the soc.2013.gobjectification.plugins
branch (not ready to merge yet anyways) is that the pref "/plugins/prpl" has
been changed to "/protocols", but I haven't written the migration code yet.

> - Have you tested your build under valgrind? You can use the following call:
> $ valgrind --leak-check=no --suppressions=valgrind-suppressions pidgin
> -d > pidgin.log 2>valgrind.log
>

soc.2013.gobjectification seems alright with valgrind, similar to main
branch.

soc.2013.gobjectification.plugins has some problems with plugins not being
unloaded due to inconsistent use counts, which is an open issue in GPlugin.

> This year's projects are rather extensive and touches many parts of
> the project. That means, they can interfere with each other. Have you
> been thinking of the order of merges?

That depends on if the other students are willing to GObjectify their own
code. If the other projects are merged first, I can GObjectify all of it
before merging my branch (I don't mind). If the others want to do the
GObjectification of their code themselves (they know more about it), they can
merge it after. In both cases, I suppose we will need help from each other.

What do you say, my fellow students?

> It's nice that all of you declared the wiliness to work on your
> projects after the end of GSoC. However, don't rely on such desires
> when planning of tasks needed for merge - student's duties on
> university often make such plans failed. As an example, please look at
> last year's statistics plugin GSoC project - it was "ready to merge",
> but it isn't merged for the whole year.
>
> This one applies especially for GObjectification project: if you don't
> merge it now, you won't do it ever.
>
> Please, don't make your projects failed just because you got other
> commitments and you have no more time for finishing them.

Yes, that makes sense, and I understand. I will ensure that GObjectification
is ready to merge as soon as possible.

In any case, you don't have to worry about me because I don't have any such
commitments for little under a year now. And after doing this much, I'm not
letting it go till its merged in. :P

Thanks,
Ankit Vani