# Moving gd development to php.net - Thread: https://externals.io/message/22627 - Original archive: https://news-web.php.net/php.internals/22627 - Started by Thomas Boutell on 2006-03-28T22:35:24+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #22627 — Thomas Boutell — 2006-03-28T22:35:24+00:00 URL: https://externals.io/message/22627#22627 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. 2. Licensing. gd is already in PHP, so this shouldn't be a big problem, but concerns might be raised. 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. 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? -- Thomas Boutell Boutell.Com, Inc. http://www.boutell.com/ --- ## #22630 — Rasmus Lerdorf — 2006-03-31T20:41:21+00:00 URL: https://externals.io/message/22627#22630 · In reply to: #22627 > 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 --- ## #22631 — Pierre — 2006-03-31T22:29:50+00:00 URL: https://externals.io/message/22627#22631 · In reply to: #22627 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 --- ## #22648 — Thomas Boutell — 2006-04-02T23:11:54+00:00 URL: https://externals.io/message/22627#22648 · In reply to: #22631 Just for clarity's sake, I'm officially agreeing to this and I'm fine with the choice of Pierre as maintainer. Pierre and whoever else, let me know when and where to deliver my current work in progress, and where to forward the patches I've already received. When there's a 2.0.35 release to be made, or sooner if it seems appropriate, I'll make an announcement and direct folks to the appropriate PHP page. -- Thomas Boutell Boutell.Com, Inc. http://www.boutell.com/