Moving gd development to php.net

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.

Yes, we are definitely still very interested in gd. We would of course
be much happier having you continue to lead things, but if you don't
have time for it we can take over.

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

I don't see any reason to change the gd license.

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.

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

We rely very much on a solid C API so there would be no reason move away
from that. We have some hacks to make gd play nice with the PHP memory
manager, but I don't think it would take much to abstract that nicely
and allow any sort of memory manager override for other languages.

We don't have a lot of Perl/Ruby developers on hand, but it would live
in its own top-level repository at cvs.php.net/gd and we have ACLs on
our CVS access so we can easily add gd-only accounts for any developers
who would like to work on it.

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

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?

From a logistics point of view, we can definitely do it. We have a
couple of people who know the code quite well and all the infrastructure
required. The main hurdle is having someone volunteer to actually take
the lead on this. I can help, but I don't have the cycles to really
drive it. So if I can get a couple of people to volunteer some
sustained time for this, I would say we should go ahead.

-Rasmus

On Tue, 28 Mar 2006 16:35:24 -0600 (CST)
boutell@boutell.com (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