Re: [ANNOUNCEMENT] cairo-0.2.2 (beta) Released.

Pierre, This seems to come entirely out of the blue; I've not seen any public discussion of this issue, and I've not been party to any private discussions either. In a community project, deleting someone elses work based on a unilateral decision is going too far. It's one thing for the community to discuss and arrive at that decision, but for one person alone to remove the work of others is wrong. Even more so when there is no advance warning. To all: please consider this a warning--if anyone does anything like this again, I'm going to revoke their privileges. To the matter that spawned this discussion: When I was nominated to look out for PECL, I made it clear that I hoped that PECL would be a no-nonsense community effort. The PECL package submission process is this: - mention that you're working on something to the list - gather feedback and take appropriate action on it - assuming that people are generally in favor, create, commit, release I expect PECL developers to be able to resolve their differences between themselves. If they cannot, then I offer to help try to reconcile those differences off-list. If that doesn't work, then we can ask the community for input, if appropriate. If after all that, we can't arrive at a decision, then we'll simply defer that until some later time when something has changed. Hopefully you'll see that the general theme here is that we respect each others point of view, listen to each other, and work things out. I don't want anything like PEPr in place for PECL because I find that it is artificially restrictive. What happens when someone says they are working on something but then never find the time to publish it? That's fine. What happens if someone else is thinking about doing the same thing? Ideally, they'll talk about it and collaborate on a solution and it will come about sooner. What if it's been too long with no visible progress? Then we can take the existing working code and use that. There is no sense in blocking other people on something that may never come. Speaking for myself, in this and other projects I have deferred to others in cases where I've had a half finished version of something hanging around but not had time to complete it. In this particular case we have an auto-generated stub vs a planned and designed for PHP implementation of bindings for a library. I see benefit in having both implementations in PECL; one is ready now and can very easily be automatically updated to add support for new APIs as they evolve in the cairo library. The other isn't ready yet but promises to have a very nice PHP-spirit API that sounds like it's worth the wait. It seems the big question here is who gets the "nice" name for their extension. In general, if you can't work it out between yourselves, the first one to produce and publish their real working code gets first choice on the name. In this case, the auto-generated extension is the first one to do that so it should get the name cairo, and Pierre will need to find another name for his extension. Sorry Pierre. In the interests of API sanity for PHP users in the years to come, can we open a *short* thread to discuss how the APIs differ/conflict between the two packages and see if we can figure out how they can co-exist if someone were to install both, or if someone were to write a script that would take advantage of either one or both. Please make that thread a new posting with a separate subject, and keep it focused and on topic. Assuming that Pierre won't need to change all his APIs, this should be a painless thing to resolve. If we had namespaces, I suspect this would be even less of an issue. --Wez. On 11/15/06, Pierre <pierre.php@gmail.com> wrote:

Hello, A bit too much now, I deleted it. There was no discussion about it and if you have asked before, call it whatever you like but not "cairo". Yes, I know I'm late in the cairo backend and the new graphic extension itself, but you never asked me (esp. after I showed you the initial code in linuxtag a while back). Thanks for your understanding. --Pierre On 15 Nov 2006 13:43:16 -0000, PECL Announce <pecl-dev@lists.php.net> wrote: The new PECL package cairo-0.2.2 (beta) has been released at http://pecl.php.net/. Release notes ------------- Stuff added since 0.2.1: - reflection fix by disabling inclusion of cairo backwards compatibility macros - package regenerated using latest CodeGen_PECL to resolve phpize problems on systems with older autoconf installations - added comments to more constants - *_create_* functions never return NULL, error states need to be checked for using *_status_* functions Package Info ------------- A cairo API wrapper. For details about cairo see http://cairographics.org/. Related Links ------------- Package home: http://pecl.php.net/package/cairo Changelog: http://pecl.php.net/package-changelog.php?package=cairo

    Download: http://pecl.php.net/get/cairo-0.2.2.tgz

Authors ------------- Hartmut Holzgraefe <hholzgra@php.net> (lead) -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php