Fwd: Re: msn-pecan now has direct connection support (fast file transfers)

[John Bailey]

Gary Kramlich wrote:
> That won't work.  I mean, I can't merge the objects into i.p.p:h, and
> the majority of the time it doesn't fully build anyways so it can't be
> merged into i.p.next.major:h.  In other words, the moving target issue
> will not be solved by branches.

I wasn't suggesting that it was; although I didn't explicitly state it, what I
was suggesting is what I'll get to below, except not to use i.p.p:h for your
work until you felt it was merge-ready.  A maintenance branch for 2.x and
development on i.p.p would likely be better, though.

> I think the best way to explain this goes as follows.  You know how we
> always laugh at the people that want to fork.  Yeah, same issue, I'm
> redesigning basically the entire library.
> 
> A few things that will help, but won't until development on i.p.p
> becomes maintenance only, is structure member hiding.  I'm doing that as
> well as the object hierarchy at the same time, and the usage of
> structure members is what 99% (rough estimate) of the build failures are.

What if we, after 2.4.0 is released, put a firm freeze on libpurple and say no
new API, features, etc. in the core until 3.0.0, and then get struct member
hiding done for 3.0.0?  Would this aid in gobjectifying for 4.0.0 at all?  I
realize this would delay the benefits of gobjects, but would it help the moving
target stuff at all?

If this would help, could we all agree to it?

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20071230/103722f3/attachment.sig>