msn-pecan 0.1 good enough?
Felipe Contreras
felipe.contreras at gmail.com
Wed Mar 24 17:34:56 UTC 2010
On Wed, Mar 24, 2010 at 5:12 PM, Gordon <thekancer at rogers.com> 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
More information about the devel
mailing list