About ProgressReport and msn-pecan

[Felipe Contreras]

2008/6/13 Ethan Blanton <elb at pidgin.im>:
> Felipe Contreras spake unto us the following wisdom:
>> When you think about it projects increase their dependencies when they
>> need something new. Why? Because there are bug-fixes, improvements, it
>> just makes everyone's life easier.
>>
>> Also, it's a sign of respect to the GLib developers. What would you
>> think about Adium developers if they used a libpurple from 2002? Of
>> course, it's different, GLib *is* widely used.
>
> No, this logic is deeply and fundamentally flawed.  This is not a case
> of Pidgin *requiring* an old GLib, merely continuing to build agaist
> an old glib.  There is no disrespect here (if anything it's respect --
> old glib remains good enough for us even after all this time!), and
> there is no burden upon the maintainers of glib.

Increasing the requirements increases the pressure on old systems to
upgrade. The disrespect is with the all the new development that has
happened in this case on those 6 years.

>> Usually if some lame user can live with a library that is from 2002 he
>> can very well live with an old version of Pidgin.
>>
>> You are worrying about a potential user that doesn't exist. If I was
>> using a stone age system, I would compile a new GLib on /opt/glib, and
>> export LD_LIBRARY_PATH=/opt/glib/lib; voilà.
>
> No, you are wishing away a user which *does* exist.  We have had the
> debate of moving our glib and gtk+ requirements forward on multiple
> occasions, and on each occasion, a real user has stepped forward and
> made a compelling case for support back as far as 2.0.0.  As John
> said, we will probably be sliding this forward a bit for libpurple
> 3.0.0, precisely because glib 2.0.0 is so old.

What would that compelling argument be that there is no other solution
but Pidgin supporting as far back as 2.0.0?

Are these users unable to use two GLib versions at the same time?

>> Anyway, I just added support for GLib 2.0.0 in msn-pecan, and now it's
>> uglier, but I guess when you mess with libpurple that's what you are
>> looking for anyway.
>
> This is more of that combative attitude you claimed you don't display.
> If you want to have different requirements from libpurple, that's
> fine, we aren't stopping you -- but if you want to play the game of
> producing good, stable software which is useful for a large range of
> distributions and platforms, you'll have to work a little harder.

I was surprised to read that msn-pecan has an "affinity for ignoring
compatibility with older glib", which is not true since I was already
supporting a reasonably old glib (2.6) creating the necessary
workarounds. How do you think I should react when I suddenly learn
that I'm expected to support systems from 2002 for which I need to
create ugly workarounds?

Seriously, I'm going to use gio at some point, since that's what every
sensible network code should be using. I will have to include the
whole thing just to support these ancient systems.

I don't support what people don't ask for.

I build and test myself for i386-linux, armel-linux and i386-win32.
There is support for FreeBSD as well as Darwin, and soon Adium
integration.

Personally I've found that msn-pecan is more stable in armel-linux
than your msnp9, and in overall my users also find it more stable.
While at the same time providing the features they need. I don't think
I'm the one that needs to try harder.

Perhaps it's you the one that should be working harder on making your
software work properly on slow networks, firewalls, different kinds of
proxies, and so on. BTW, I do test inside proxies, and emulate
networking problems like latency and corruption.

-- 
Felipe Contreras