About ProgressReport and msn-pecan

[Felipe Contreras]

Hi Kevin,

On Fri, Jun 13, 2008 at 2:07 PM, Kevin Stange <kstange at pidgin.im> wrote:
> Felipe Contreras wrote:
>>
>> On Fri, Jun 13, 2008 at 3:15 AM, Mark Doliner <mark at kingant.net> wrote:
>>>
>>> On Fri, 13 Jun 2008 02:46:34 +0300, Felipe Contreras wrote
>>>>
>>>> On Fri, Jun 13, 2008 at 2:38 AM, Mark Doliner <mark at kingant.net> wrote:
>>>>>
>>>>> On Fri, 13 Jun 2008 01:23:24 +0300, Felipe Contreras wrote
>>>>>>
>>>>>> 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.
>>>>>
>>>>> FYI comments like this reduce the likelihood of a "hypothetical merge
>>>>> or the
>>>>> possibility of contributing directly on the project" (as was suggested
>>>>> in the
>>>>> blog post you referenced at the beginning of this email thread).
>>>>
>>>> Because I think libpurple is far from perfect?
>>>
>>> Saying "libpuple is far from perfect" is very different from saying "it's
>>> uglier, but I guess when you mess with libpurple that's what you are
>>> looking
>>> for anyway."
>>>
>>> The former statement is more polite (although still a little rude).  I
>>> find
>>> the latter statement to be pretty offensive.  Impoliteness and disrespect
>>> for
>>> our code are not things that build a healthy open source community.
>>
>> Well, I'm sorry, but it's true, every single attempt I have made to
>> improve things has failed. The choice of pretty unpopular DSCM, a
>> centralized development model, a website that constantly has kittens
>> (or used to), a mess with header includes, a lack of object-oriented
>> code, disregard of freedesktop standards, and now an unreasonably old
>> dependency support.
>
> You list these items like each one was specifically chosen to make things
> harder for you.  Everything that exists in Pidgin or libpurple does for some
> set of reasons.  Whether or not the reasons are any good or even apply
> anymore is certainly debatable.  I think you would be hard pressed to find
> any developer that believes libpurple is perfect.  If we thought so, we
> wouldn't have any plans for the future of the library.

Exactly, so why should the fact that I think libpurple is far from
perfect decrease the possibilities of merging msn-pecan? That's all I
asked.

> Monotone is a relatively new VCS, but it seems to work pretty well as far as
> I've used it.  In our search, we (Ethan primarily) looked at many and guided
> us toward the one he found most promise with.   Many people have already
> gotten involved in spite of having to use monotone, so I don't buy your
> argument that it's prohibitive to development.  You already knew we were
> using MTN when you chose git from what I recall, so it's your own fault if
> that makes things harder for you.  Monotone provides static binaries, so if
> you can't find a package for your distro, you still have an option.

Don't make this about me, I've been using Monotone, even analyzing the
database, trying to understand the source-code and even created tools
to extract information. I will present my findings in a separate
email, along with tools to convert the repository to git
automatically.

I'm not bringing up the MTN issues here, I'm just saying it's an
unpopular DSCM, that's a fact.

> The web site problems come with the territory of trying to move out onto our
> own development system, a requirement of operating things like monotone from
> a central location.  The issues have been largely ironed out and things work
> pretty well now.

You have a tendency to want to do everything by yourselves, that's why
I brought the point. I'm glad that things are working well now,
hopefully it will stay that way. But still, is it so crazy to leave
the project hosting to, I don't know, project hosting experts?

> I don't know what "mess with header includes" you're referring to.  As far
> as I know most of the headers are reasonably laid out and functional.

Please refer to this picture:
http://people.freedesktop.org/~felipec/connection_h_dep.png

Do you think that's not messed up? Sure, it could be worst, but that's
not the point.

> Object oriented code is certainly a design goal of gobjectification, or have
> you not been paying attention to that whole discussion?

I haven't seen a consensus among developers, some people want that,
others argue that's not required. All I know is I don't see any 3.0.0
branch.

> And I'm sure we'd like to work toward supporting reasonable freedesktop.org
> standards.  Which ones are we so blatantly and offensively disregarding in
> your eyes?

For starters; ~/.purple.

> As for old dependency support, this has been thoroughly explained in this
> thread.  You are maintaining a separate plugin, so you can do whatever you
> like, but if you want to know why your code isn't clear for merging with
> Pidgin, that's certainly one reason that holds us back until we're
> comfortable breaking compatibility for older *maintained* distributions,
> like RHEL 3.

I know that, and I've explained why I think your decision to support
those systems is wrong, and just makes things more difficult.

I don't see msn-pecan even been merged into upstream, but I certainly
don't want the blame to be on my side, so I'm supporting GLib 2.0.0
even though I think it's stupid.

>> I've tried to improve things, and I've got impoliteness, offensive
>> comments and disrespect for my work, and my ideas (when I don't get
>> ignored). Of course, not from everyone, but still, I don't think this
>> is a very healthy community anyway.
>>
>> I'm just saying what is happening; supporting libpurple is making
>> msn-pecan uglier. I can't wait to put all the libpurple support in a
>> module, so at least I can contain the ugliness.
>
> I can't follow MSN pecan development because so many of your commits change
> random things in addition to the stated change in your commit message.  I
> assume that you know what you're doing when you delete lots and lots of code
> you don't think is important in a cleanup, but you don't explain it
> anywhere... The way you write the changesets I've seen they become obsolete
> so fast it's impossible for us to merge them unless we review them within a
> matter of days.

I separate the cleanup changes from the relevant ones.

Also, github provides facilities to write comments on each commit, and
each line of the diff, I would gladly answer your questions. And of
course there is msn-pecan mailing list.

I know you can't keep up with the fast development in msn-pecan, I
won't slow it down for some "hypothetical merge".

> I wasn't involved with Pidgin too deeply when you were a major contributor,
> but if your patches were anything like what I've seen in your commits, I can
> understand why they may have had to rot for a while while we tried to figure
> out whether they did anything undocumented that might break something
> else... and when we have to rewrite or disassemble a patch to make it work
> with Pidgin, that takes a lot more time and attention from an otherwise busy
> person.
>
> Now if you really find libpurple to be SO ugly, poorly maintained and
> unusable, why are you working with it?  If there are improvements you see as
> necessary, write clean patches doing only what is needed to fix the problem
> and explain cleary why you feel the change is necessary and what exactly it
> fixes.  Remember that patches that break the existing API are likely to be
> held off until we are ready for that major version bump down the road, and
> that not every issue can be addressed with the haste you seem to believe
> makes for better code.

I work on it because even if it's has horrid internals (IMHO), it
works, and it's the client I use (for now).

Why don't you grep for my patches that actually got in?
cd8c000c5205ad2bdbbc2c7de67b5f08b72e17c8
716d84a169bb99b378b5268b6c4e6f337d4d7615
e39a6e9be3df05b59a878001feb9276b9ceb66a9
cee4435a3ff47ac514db834171773a6143ef3efa
7e8103bd3c5298a43a4e18bb59037980f5c213c9

In some others, people felt there was no need to mention me:
a9b967ef48f5df65686f453f94132b83a4e90145

Or check my requests?
http://developer.pidgin.im/ticket/5762

>> And BTW, other people along with being offended would ask for ways to
>> improve, but that's not the Pidgin way.
>
> Of course we want suggestions on how to improve, but we demand reasons for
> changing things, explanations of how the improvements will benefit the
> project and justifications for abandoning an old methodology.  You can't
> simply tell us what you don't like and what you think we should do; you also
> have the burden of having a meaningful argument that will sway our opinion.
>  If you're not prepared to do that, we're probably not going to put too much
> stock in your suggestions.

I've done that, many times. But I'll will summarize and create a
document in a wiki.

> I keep thinking you could be such a valuable contributor to Pidgin on MSN,
> and I've told several people it would be great if we could try to make you
> feel welcome, but the more I see your actions, the more it seems you don't
> /want/ to feel welcome, you want free reign.  You refuse to accept the
> parameters of our coding standards, or to justify the need to break them,
> and then every time we get into one of these threads, you fall apart at the
> first sign of any criticism and lash out at the project in general.  If you
> can't handle criticism and defend your ideas, it seems like you're hanging
> around the wrong project.

What makes you think that I refuse the parameters of your coding
standards? Do you see any major discrepancy in msn-pecan?

The change I'm more interested in is GObjectification. I've been told
that such change requires API breakage and so it must wait for 3.0.0,
but that's not true, I've explained that you can have internal API
changes and still keep the external old API with a wrapper. I know
because I started doing exactly that years ago.

I've also been told that there are no more fileds available for prpl
structures, which I find stupid because at least one field could have
been used for storing the version, making it extensible. I've been
told that this could go into 3.0.0, but I've already argued that
GObject interfaces is a much superior alternative... only to be
ignored.

I believe it's you who should learn a little bit about GObject, and
then refute these arguments.

> I have to give up trying to believe there's a reason to defend your
> contributions.

Don't worry, I'm going to make one final sprint and then I'm out of here.

-- 
Felipe Contreras