On Tue, 28 Mar 2006 16:35:24 -0600 (CST)
[EMAIL PROTECTED] (Thomas Boutell) wrote:

> Hello folks,
> 
> I'm the original author of the gd graphics library used in PHP.
> Although there are alternatives, gd is probably the most common way
> to manipulate images on the fly in PHP code.
> 
> As some of you are no doubt aware, I haven't released a new gd update
> in quite some time. Other projects took up vastly more time than
> expected, and it's dawned on me that this is not going to change.
> Also, gd has forked already, with many improvements and fixes existing
> only in the PHP version. So it's time to do the right thing and offer 
> the bazaar-keepers the keys to the cathedral.
> 
> What I am proposing is to move gd development to php.net. I would
> still like to maintain http://www.boutell.com/gd/ as a useful
> resource for gd programmers and make contributions myself as an
> individual developer. But php.net would become the official home of
> gd, and I would relinquish control.
> 
> The issues I can see with this proposal are:
> 
> 1. Interest. Does the PHP community want to take this on? PHP
> developers, including some involved with patching the PHP "fork" of
> gd, have expressed interest in the past. But I'm not assuming they are
> still interested. So, you tell me.

As the main maintainer of the php GD library (the library not the
extension itself), I think that you finally choosed the best solution.
I asked you to do what you are asking now in the past. So yes, I'm still
interested :)

> 2. Licensing. gd is already in PHP, so this shouldn't be a big
> problem, but concerns might be raised.

The license should remain untouched.

> 3. Continued support for using gd from C and, therefore, from
> other non-PHP languages. Right now, gd has a reasonable API for
> C programmers and others, such as Lincoln Stein, wrap that API for
> languages like Perl, Ruby, etc. I don't know whether the PHP
> developers would be excited about continuing to offer a 
> human-programmer-friendly C API for features added in the future.
> Also, it should continue to be possible to build gd in the
> absence of the rest of PHP.
> 
> A strong motivation for this, from PHP's point of view: support
> for other languages leverages the bug-fixing and enhancement-making
> abilities of developers outside the PHP community, improving
> PHP's graphics capabilities as a result.

As Rasmus said, we like to rely on solid C API, having a larger user
base can only make it better.

> 4. Maintaining programmer documentation for the C API. Volunteers 
> from outside the PHP community might be needed to make that continue
> to happen.

How do you maintain the docs now? Or the website? Can we import
everything in the php cvs (for the GD part of boutell.com)?

> 5. Patches already submitted to me need reviewing and possible
> application. I would gladly make my gd inbox available.

You can send them to me. As soon as the issue trackers is up and
running, I will add them, easier to track :)

> What's your thinking, PHP folks? Has the time come for 
> gd to become a PHP project? Are those interested in that also
> willing to ensure that gd remains useful to non-PHP developers?

I want to keep GD usefull for other projects, that was my goal with my
various mails about keeping our work synced or to use a common CVS
repository, even in php.net.

PHP has the infrastructure we need for the GD library, the cvs, mailing
lists, issue trackers and web sites.

I'm obviously volunteer to lead the project if there is a need for
one (releases, initial setup, etc...). I also hope to get the other
binder maintainers or users involved.

Thanks for this decision,

--Pierre

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to