Getting Stuff Done (Re: One critical security flaw...)

Ethan Blanton elb at
Mon Feb 1 12:19:15 EST 2010

Sadrul Habib Chowdhury spake unto us the following wisdom:
> > 	* Finish the ICQ X-Status stuff ASAP for 2.7.0 (string freeze
> > 	  for release within 3 days of completed merge).
> I personally wouldn't hold up a release because of the X-status stuff,
> mostly for two reasons: it affects only one (two?) service/protocol, and
> it clearly isn't something a lot of users (and more importantly
> developers) want. I would rather suggest that we [try to] include this
> in 3.x. That way, it wouldn't be necessary to work around the potential
> ABI-breakage (changes in PurpleRequestField) the latest patch causes.

While this isn't a volunteer to do the integration ... I kind of
disagree.  The X-Status patch has been floating around for literally
years, and I'd like to see it merged.  We're not sending a very
promising message to contributors when we put patches off for so long,
and I think this is what John is trying to address.

I realize the X-Status patch had some issues which took time in and of
themselves (like icon ownership, if I remember), but no matter how you
slice it, it's been on our plate for a *while*.

> > 	* As soon as 2.7.0 is out, create a branch such as
> > 	  im.pidgin.pidgin.2.7.x (I'm open to better names) from the tag
> > 	  of 2.7.0 for future maintenance releases.
> > 	* Once 2.7.x is branched, 2.x.y is API frozen--no new API unless
> > 	  absolutely required to fix a security issue.
> > 	* Once 2.7.x is branched, im.pidgin.pidgin is for 3.0.0 development.
> > 	  All new features, API additions, etc. should happen only on this
> > 	  branch or other branches that will be merged *only* to
> > 	  im.pidgin.pidgin.
> I would suggest to make it a 'feature freeze', rather than an
> 'API freeze'. I would welcome API changes to make 2.x branch cleaner
> while the main development continues to happen towards 3.x
> This is probably a good time to toy with the idea of decoupling the major
> version numbers of libpurple and the UIs (pidgin, finch). I personally
> think this is a good idea, but I don't know how much effort would be
> needed for this, and if it would be worth the benefits.

I don't think this is a bad idea.  Libpurple is now used by enough
people to merit decoupling it from Pidgin, I think.  We'll have to
think about how to handle releases and version compatibilities,


The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <>

More information about the Devel mailing list