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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxx> (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