On Wed, Mar 24, 2010 at 5:12 PM, Gordon <[email protected]> wrote:
> What drove me to comment on all of this is the way that Felipe is going about 
> trying to have his 'fork' included in the next Adium release.

It's not "mine" as there's a bunch of people that contribute to the project.

And it's not a 'fork' because I wrote the original one; it's more like
the code switched homes.

> Felipe, the primary Adium developers have already given you very valid 
> reasons why they will not switch to msn-pecan for this release. 'No 
> regressions' is not just a buzzword, it is policy.

Policy is just a word, policies can change, and policies can be stupid
(I'm not saying this one is).

> You need to accept that.

No.

> I am one of those people that use MSN -> Yahoo contacts. Would direct file 
> transfers be nice? Possibly for some people, but for myself, I use gmail to 
> transfer files up to a certain size and FTP for files past that size. Would I 
> appreciate that I could no longer use the MSN -> Yahoo bridge in exchange for 
> direct file transfers? Not at all. If I wasn't following this listserv and 
> didn't know about losing Yahoo contacts, I likely would have filed a bug 
> report, which in turn would have taken precious time away from the developers.

Ok, so that's *one* person that cares about this.

I have a question for you: What's the percentage of YIM contacts in
your MSN account?

> Furthermore, according to your blog, msn-pecan has been stable at 0.1 at less 
> than a month. I don't know about everybody else, but switching from a proven, 
> stable library to something that is essentially a hostile fork, which hasn't 
> even been in use for more than a month, seems dangerous within a popular 
> product like Adium.

Wrong. msn-pecan has been stable most of the time with some up and
downs, 0.1 is the first release that is considered *serious*. Not
stable; rock-solid.

And wrong; libpurple's stock msn is proven _unstable_. You can even
read it from the mouth of Pidgin developers:
http://theflamingbanker.blogspot.com/2010/01/on-subject-of-bugs-or-help-wanted-and.html

Don't spread FUD; msn-pecan has been used by a considerable use-base
since years in many different platforms.

> If direct file transfers is such a hot request, what is to stop you (or 
> somebody else) from submitting it as a patch to libpurple?

As I said before; the code of libpurple's msn is beyond redemption. I
would have to make *huge* drastic changes to all the MSNSLP code
(which I wrote entirely) to even be slightly confident about it. And
to keep the code simple I would have to implement the network
abstractions that I already did in msn-pecan.

Pidgin developers don't want that.

> It almost seems like you are doing this to spite the maintainers of 
> libpurple, which is not a vote of confidence for the ability to work with you.

We, the people involved in msn-pecan, collaborate just fine with
Telepathy, AMSN, papyon, and Instantbird developers. Pidgin developers
don't, not even with GNOME, or freedesktop.

> You might have the greatest product in the world, but what happens if you 
> have a disagreement and decide to not support msn-pecan anymore? Well, this 
> is exactly what you've done with libpurple - you say so yourself on your 
> blog. This does not instil confidence.

You speak as if Pidgin developers were supporting MSN just fine; they
are not. Moreover, I have been supporting this MSN code for 10 years
now, the fact that Pidgin developers decided to stop picking up the
goodness is *their* fault.

> Felipe, the way you are going about this is very odd and you can come across 
> as very abrasive. You have taken the time to reply to many of the developers' 
> valid points with sarcastic and sometimes aggressive retorts. One example of 
> this is "As I said in another reply; empty slogans such as "no regressions" 
> mean nothing. It's just a way of making engineers (or managers) happy.". 
> You're attacking common Adium policy here.

Criticizing policy is not heresy.

> Heck, it is the policy of any good shipping software. In my opinion, the only 
> time a feature regression would be acceptable is if it fixes a severe, 
> crippling bug. As far as I've seen from my own heavy use in Adium, Libpurple 
> is stable and I've come across very few bugs.

Avoid regressions as much as possible is a good policy. No regressions
ever until the end of times even if most users would be happy with it,
is not.

> For reference, I downloaded and tried the msn-pecan / Adium test from Google 
> Code when it was first announced. I didn't catch any noticeable benefits so I 
> subsequently switched back to the stock Adium. I was initially impressed by 
> the enthusiasm, but after researching the history of the fork and what it 
> does exactly, I can say that I've lost that enthusiasm.

Good that it works for you... I assume you don't care about the
countless people that can't even login or get constant disconnections.

> You need to accept what the developers have said repeatedly. Things are 
> already progressing very slowly getting the next release out the door. Even 
> if msn-pecan did not introduce a somewhat major feature regression, it would 
> likely not be included in 1.4. The most likely scenario is that when the 
> developers focus on 1.5 they might be ready to consider msn-pecan, at which 
> point somebody will likely let you know. But as it is, the time and resources 
> to implement a change like this for the next release is not possible. Your 
> regular bombardment of emails to the developers is not going to magically 
> convince them otherwise.

You are distorting the conversation.
1) msn-pecan was proposed for 1.4 if the Yahoo regression was fixed
2) I provided a bunch of reasons why I think the Yahoo regression is
not important
3) The fact that it was even a regression was contended
4) Regardless of the result of 3) Adium developers decided that it's
too soon for 1.4
5) You came by

*Now* that it has been explained that it's too soon for 1.4
(regardless of the YIM issue), it's perfectly sensible to aim for 1.5.

Cheers.

-- 
Felipe Contreras

Reply via email to