About ProgressReport and msn-pecan

[Richard Laager]

On Fri, 2008-06-13 at 15:40 +0300, Felipe Contreras wrote:
> 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?

With regard to the website, I don't think there's much we could do
differently there. If we had a hosted website instead of a (virtual?)
server, we'd still have the same content.

> > 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.

I think that diagram is irrelevant. connection.h includes only 4 headers
from libpurple, which it needs. We also now have purple.h to simplify
the lives of plugin authors. If you have a *concrete* change to suggest,
please do.

> > 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.

Who is not in favor of gobjectification? The problem here is a lack of
time by interested people. If you want to help here, please do.

$ mtn list branches | grep gobject
im.pidgin.gobjectification

See my reply below, though.

> > 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.

I assume you meant this, which is actually a freedesktop.org spec and
not a path name:
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

First off, dot directories pre-date that standard by probably decades.
Second, there are still a lot of projects using them, so it's not like
we're the last holdout. Third, we've discussed that before:

Moving data from ~ to ~/.local/share doesn't really buy you much.
Instead of having a ~ cluttered with directories, you have a
~/.local/share cluttered with directories. The /etc to /etc/xdg change
is basically the same. That spec seems to have a couple of advantages:
1) It provides a common environment variable that can be used to allow
users to move their configuration files. 2) It splits out cache data
(like buddy icons, in our case), which is nice when you're doing ~ on
NFS or similar (or roaming profiles on Windows). The downside to
splitting the data is that instead of a ~ cluttered with directories,
you end up with *multiple* directories cluttered with directories.

That said, I don't have a problem supporting that spec for 3.0.0. It'd
have to be a 3.0.0 change because it would break backwards compatibility
of the configuration files. I don't think that the minor benefits gained
are worth forcing a major version bump just now. If this is really
killing a use case for you or someone you want to support, I'd propose
you add the support now as a configure option that defaults to off. We
can then remove the option (and turn it on) for 3.0.0.

In fact, if we decide to follow this spec, we should probably add
support for *looking* in that location sooner. For example, let's say we
add support for looking at the XDG locations in 2.6.0: if it found a
configuration directory in those locations, it would use it. Otherwise,
it would fall back to ~/.purple. However, it would still create
~/.purple by default. That way, 2.6.0 would be forwards compatible with
3.0.0, which would create $XDG_xxx/purple, etc.

> I separate the cleanup changes from the relevant ones.

Here was one example that Kevin mentioned. I'm not going to take a
position as to whether this is an isolated example or a trend, because I
haven't looked at your revision history:
http://github.com/felipec/msn-pecan/commit/40c0bbedef9baec773b9975aad8d1ffde2a02a8c

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

Fast development is great. Kevin's comment is about revisions like the
one above, where the commit message says one thing and there are big
unrelated changes there. That could easily have been committed as two
revisions, which would reduce* this concern without slowing down
development more than a few seconds.

* I say reduce rather than eliminate because in this particular case,
the functions were renamed for no apparent reason. However, if a cleanup
or refactoring change were legitimate, it still should be done
separately.

> 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.

If you can GObjectify structures in place, great. By all means, please
go ahead with this if you'd like. I can review patches for you if you'd
like.

> 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.

This is exactly what has been done to overcome this problem.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080613/88923f2e/attachment.sig>