Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22630
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <442D93F1.2010607@lerdorf.com>
Date: Fri, 31 Mar 2006 15:41:21 -0500
User-Agent: Thunderbird 3.0a1 (Macintosh/20060324)
MIME-Version: 1.0
To: Thomas Boutell <boutell@boutell.com>
CC: internals@lists.php.net
References: <Pine.LNX.4.61.0603281622050.29484@boutell.com>
In-Reply-To: <Pine.LNX.4.61.0603281622050.29484@boutell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Moving gd development to php.net
From: rasmus@lerdorf.com (Rasmus Lerdorf)

> 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