All- I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public. Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges. Two problems with dropping PHP4 support: 1) Many hosts (including mine) only support 4.x 2) If one project (Drupal) drops it but the other doesn't (Joomla), the audience (both developers and users) may abandon the project that drops PHP4. Jonah's modest proposal: An agreement to set a release version (or date) where major PHP-based projects drop PHP4 support. Larry, always ambitious, suggested that we get WordPress and Galley involved, too. I can very clearly see the advantage to projects setting an arbitrary date (say, January 1, 2008) after which we don't officially support PHP4. THis wouldn't say that we try to break PHP4, simply that new feature development (and patch support and security updates) require PHP 5. So consider this a modest proposal to get folks thinking about how to move forward together. I already passed Larry on to Jonah to see who might make that decision on the Joomla side. - Ken Rickard agentrickard
I guess it'd be good to make a bunch of ISPs aware of this too, might kick some arse and get some long overdue server upgrades on track! On 23/05/07, Ken Rickard <agentrickard@gmail.com> wrote:
All-
I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public.
Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges.
-- phone: 0774 3917404 skype: daresbalat msn: bobulatorm@hotmail.com
Well, the idea is to make the ISPs aware when/if we actually agree to something. "We're thinking about dropping PHP 5 eventually" isn't as quite persuasive as "We're dropping PHP 5 on X date, just so you know..." :-) Emailing Jonah was on my to do list for tonight, but unless Ken's already talked to him I'm going to hold until tomorrow night in case anyone else wants to throw in a comment here (or a tomato, if appropriate). Dries, is this something we'd have your permission/blessing/veto on? As for me being ambitious, well, guilty as charged. :-) I spoke to Larry Masters, the CakePHP founder/project lead, at php|tek last week. He said they were already looking to drop PHP 4 support for their 2.0 release, but would be willing to sign on to such a group effort if it got off the ground. On Tuesday 22 May 2007, Bob wrote:
I guess it'd be good to make a bunch of ISPs aware of this too, might kick some arse and get some long overdue server upgrades on track!
On 23/05/07, Ken Rickard <agentrickard@gmail.com> wrote:
All-
I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public.
Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
As a web hosting company, I think this is a great idea. One of the impediments to updating all hosting accounts is the cost/benefit of making such an invasive change. The biggest cost is convincing customers that it's necessary to incur additional testing and modification costs on sites that were working just fine with PHP4. We're driven by the market. With only minor demand and little justification to rock our customers' boats, we're as stuck as everyone else, and PHP5 instances are relegated to special configurations or separate applications. Consequently, big projects must support PHP4 to play to our least common denominator - it's a vicious circle! Such a "deadline" would provide enough justification to make the switch without worrying that PHP4 customers will feel jerked around on a whim and go elsewhere ( to that "stable" PHP4 host ). Long story short: +1 -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org]On Behalf Of Larry Garfield Sent: Tuesday, May 22, 2007 9:00 PM To: development@drupal.org Subject: Re: [development] PHP5 going forward Well, the idea is to make the ISPs aware when/if we actually agree to something. "We're thinking about dropping PHP 5 eventually" isn't as quite persuasive as "We're dropping PHP 5 on X date, just so you know..." :-)
On 23 May 2007, at 04:00, Larry Garfield wrote:
Emailing Jonah was on my to do list for tonight, but unless Ken's already talked to him I'm going to hold until tomorrow night in case anyone else wants to throw in a comment here (or a tomato, if appropriate). Dries, is this something we'd have your permission/blessing/veto on?
My current thoughts are on http://buytaert.net/php-is-dead-long-live- php. If the other projects agree to set a hard date, then I'd be happy to talk more to see if we can all agree on such a date. Feel free to involve me in the conversation when the time is right. -- Dries Buytaert :: http://www.buytaert.net/
Hi, I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go. I like the setting of the date for dropping PHP4 support, as it gives something to work towards, but I think that it needs to be at least 12 months into the future to be nice to all the Hosting companies. This also gives the PHP projects 12 months to make sure that the current release is 100% on PHP5. As has been said else where php4 is not going to go away on that date, but next major releases of these products after this will only support 5 and beyond. Gordon. Ken Rickard wrote:
All-
I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public.
Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges.
Two problems with dropping PHP4 support:
1) Many hosts (including mine) only support 4.x 2) If one project (Drupal) drops it but the other doesn't (Joomla), the audience (both developers and users) may abandon the project that drops PHP4.
Jonah's modest proposal: An agreement to set a release version (or date) where major PHP-based projects drop PHP4 support.
Larry, always ambitious, suggested that we get WordPress and Galley involved, too.
I can very clearly see the advantage to projects setting an arbitrary date (say, January 1, 2008) after which we don't officially support PHP4. THis wouldn't say that we try to break PHP4, simply that new feature development (and patch support and security updates) require PHP 5.
So consider this a modest proposal to get folks thinking about how to move forward together. I already passed Larry on to Jonah to see who might make that decision on the Joomla side.
- Ken Rickard agentrickard
!DSPAM:1000,46539c9a107171804284693!
Yes, my thinking is along the lines of "any official feature-release after X date will assume PHP 5.x as a minimum." WHICH 5.x is an open question. (5.0.x was all sorts of nasty, from what I gather.) In my dream world we say 5.2, because 5.2 is where the really fun security features like input_filter and PDO come in as well as native JSON support, but I doubt we can get away with that because of RHEL. (As Ken said, ambitious. <g>) For the date itself, it couldn't be before 2008 sometime. I'm thinking 1 January or 1 April, but that depends on the other projects involved and how long it takes to agree on a date/version. TBD. On Tuesday 22 May 2007, Gordon Heydon wrote:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
I like the setting of the date for dropping PHP4 support, as it gives something to work towards, but I think that it needs to be at least 12 months into the future to be nice to all the Hosting companies. This also gives the PHP projects 12 months to make sure that the current release is 100% on PHP5.
As has been said else where php4 is not going to go away on that date, but next major releases of these products after this will only support 5 and beyond.
Gordon.
Ken Rickard wrote:
All-
I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public.
Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges.
Two problems with dropping PHP4 support:
1) Many hosts (including mine) only support 4.x 2) If one project (Drupal) drops it but the other doesn't (Joomla), the audience (both developers and users) may abandon the project that drops PHP4.
Jonah's modest proposal: An agreement to set a release version (or date) where major PHP-based projects drop PHP4 support.
Larry, always ambitious, suggested that we get WordPress and Galley involved, too.
I can very clearly see the advantage to projects setting an arbitrary date (say, January 1, 2008) after which we don't officially support PHP4. THis wouldn't say that we try to break PHP4, simply that new feature development (and patch support and security updates) require PHP 5.
So consider this a modest proposal to get folks thinking about how to move forward together. I already passed Larry on to Jonah to see who might make that decision on the Joomla side.
- Ken Rickard agentrickard
!DSPAM:1000,46539c9a107171804284693!
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
I like the setting of the date for dropping PHP4 support, as it gives something to work towards, but I think that it needs to be at least 12 months into the future to be nice to all the Hosting companies. This also gives the PHP projects 12 months to make sure that the current release is 100% on PHP5.
As has been said else where php4 is not going to go away on that date, but next major releases of these products after this will only support 5 and beyond.
Because of earlier conversation on this list, I've been trying to build the most recent of all third party software, Apache 2.2, php 5.2.1, etc. The problem I have is a PCRE issue in the unicode.inc file. I've tried reverting back to the earliest PCRE library that 5.2.1 supports to the most recent 7.1 release. The issue prevails (warning: preg_match() [function.preg-match]: Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0 in /home/webadmin/drupal5.progw.org/html/includes/unicode.inc on line 47. ) and you can see the result at http://drupal5.progw.org. Researching the issue with Google hasn't brought much help. I did find two d.o nodes where this issue was brought up http://drupal.org/node/97673 and http://drupal.org/node/40825. I made a comment in one of them that I thought it might be an issue between the ext/pcre in PHP and an upgraded version of PCRE library but I don't know that since I tried PCRE-6.6 and that failed to help. Let's agree on which node above to continue this discussion and duplicate the other one. I use the configure scripts rather than RPM because that is my preference. I can give the configuration parameters for each on request. Earnie
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point. Earnie
On 5/27/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Ubuntu server installs Apache 2.2 and PHP 5.2.1 by default. # php -v PHP 5.2.1 (cli) (built: May 22 2007 19:05:44) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.5.1, Copyright (c) 2004-2006 eAccelerator, by eAccelerator # apache2 -v Server version: Apache/2.2.3 Server built: Jan 15 2007 18:14:50 Haven't noticed any problem on my test server nor my live server, and I have lots of sites there, mostly 5.x. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
No problems here either. I'm running Apache 2.2.54, and PHP 5.2.6. (Not sure about the version numbers, but the latest of both of them.) This is using the latest stable of XAMPP (yes, a secured one) on a RHEL 3 VPS. Wim On May 27, 2007, at 16:56 , Khalid Baheyeldin wrote:
On 5/27/07, Earnie Boyd <earnie@users.sourceforge.net> wrote: Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Ubuntu server installs Apache 2.2 and PHP 5.2.1 by default.
# php -v PHP 5.2.1 (cli) (built: May 22 2007 19:05:44) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.5.1, Copyright (c) 2004-2006 eAccelerator, by eAccelerator # apache2 -v Server version: Apache/2.2.3 Server built: Jan 15 2007 18:14:50
Haven't noticed any problem on my test server nor my live server, and I have lots of sites there, mostly 5.x.
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Why I am not surprised that there is no issue URL.?
On 5/28/07, Karoly Negyesi <karoly@negyesi.net> wrote:
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Why I am not surprised that there is no issue URL.?
Because at this point, he is suspecting his own setup, not Drupal to be the issue. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Quoting Karoly Negyesi <karoly@negyesi.net>:
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Why I am not surprised that there is no issue URL.?
Why am I not surprised you didn't read the previous post where I gave two issues that were already existing? http://lists.drupal.org/pipermail/development/2007-May/024096.html Earnie
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Thanks to private conversation with Khalid and Wim I was able to determine the issue. PHP comes with its own version of PCRE and I had overridden the use of that version with --with-pcre-regex=/usr/local. After removing that configuration item the issue has been resolved. Earnie
Perhaps this tells us something about our ongoing discussion about whether to allow foreign code in our CVS. Clearly PHP has allowed it and has a version which is necessary for successful use. TinyMCE is likely to have similar properties if we have a slightly customized version in the Drupal CVS, namely someone who installs for the public repository is likely to have problems. This is an opportunity to do better and have a private copy and do enough version checking to insure that it is the one being used and complain with an obvious error message instead of an obscure failure message. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earnie Boyd Sent: Monday, May 28, 2007 11:15 AM To: development@drupal.org Subject: Re: [development] PHP5 going forward Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Gordon Heydon <gordon@heydon.com.au>:
Hi,
I like this idea, and getting as many of the major PHP projects involved as possible would be the best way to go.
Does anyone have a working configuration for Apache-2.2, PHP-5.2.x and Drupal? I've been trying but I keep getting an issue with PCRE and UNICODE as I have previously mentioned. Unless this issue is addressed then pushing for PHP5 is a mute point.
Thanks to private conversation with Khalid and Wim I was able to determine the issue. PHP comes with its own version of PCRE and I had overridden the use of that version with --with-pcre-regex=/usr/local. After removing that configuration item the issue has been resolved. Earnie -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.1/822 - Release Date: 5/28/2007 11:40 AM
On 5/28/07, Walt Daniels <wdlists@optonline.net> wrote:
Perhaps this tells us something about our ongoing discussion about whether to allow foreign code in our CVS. Clearly PHP has allowed it and has a version which is necessary for successful use.
Please do not "cross the streams" by bringing this up in this thread. The situation with PHP and libraries is vastly different. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
I agree the PHP libraries are very different issue, but PHP development faces the same problem Drupal has in whether to copy other projects or reference them. Clearly for PCRE they choose to copy and it lead to a problem. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Boris Mann Sent: Monday, May 28, 2007 11:58 AM To: development@drupal.org Subject: Re: [development] PHP5 going forward On 5/28/07, Walt Daniels <wdlists@optonline.net> wrote:
Perhaps this tells us something about our ongoing discussion about whether to allow foreign code in our CVS. Clearly PHP has allowed it and has a version which is necessary for successful use.
Please do not "cross the streams" by bringing this up in this thread. The situation with PHP and libraries is vastly different. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.1/822 - Release Date: 5/28/2007 11:40 AM
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walt Daniels schrieb:
I agree the PHP libraries are very different issue, but PHP development faces the same problem Drupal has in whether to copy other projects or reference them. Clearly for PCRE they choose to copy and it lead to a problem.
That's actually a very valid concern. There used to be a Drupal 4.5 Debian package which was included in Debian Sarge. Due to the long lifetime of Debian we kept getting support requests for this package when 4.5 was long dead and buried - from our point of view. I think the maintainers of e.g. tinymce might be very non-plussed if they'd get swamped support requests for a custom made Drupal-tinymce distribution which might have errors that their distribution doesn't. And don't tell me that people would be able to see the difference or I'll point you to the CVS applications of the lost souls who mistook our CVS application form for an application form for the pharmacy company... Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGWw3yfg6TFvELooQRAhpOAJ0Sbc7zOovYsFcYEghejrXeYPKr/ACgsCUw h3BWFoUmrQNdgHwNXZQTfkY= =zcDn -----END PGP SIGNATURE-----
Wrong thread yes, but vastly different no.
Hi, I've been developing on and off some modules for a client of mine. These are my first (so be gentle if I did something not a la the 'Drupal' way) Drupal modules and are only for the 4.7.x version and only for mySQL. We would like to share these with the rest of the Drupal community and we were wondering what the best way of doing this is? The plugins are documented using phpdoc for dev docs and include user documentation for the usage of the plugins. We tried to keep them multilingual although we haven't tested that (yet). At the moment the plugins are in English. A short description of the plugins: 1) Consultation module. Allows to consult registrated users either by web surveys or sms (needs a patched profile module and optionally the sms gateway module). Groups can be created based on profile parameters, these groups can be consulted using surveys either on the site or by sms. Surveys can be exported and imported. Consultations can be exported as CSV reports. Groups can be contacted by email or sms. 2) The Shicafe (SHow ICal FEeds) module Is a small Drupal module, which facilitates the display of off-site events published via iCal feeds. It allows you to add, update and remove iCal feeds and show the corresponding events in a block on your Drupal site. 3) The Gimme module Allowes a site owner to make news and/or events easily accessible via sms. One can send an sms keyword and receive a set number of node titles. It needs the smsgateway module installed. ps: Due to time constraints I cannot (yet) update them to version 5 nor version 6 Looking forward to hear from you guys, All the best, grtz BjornW
On 31/05/07, Burobjorn <burobjorn@gmail.com> wrote:
Hi,
I've been developing on and off some modules for a client of mine. These are my first (so be gentle if I did something not a la the 'Drupal' way) Drupal modules and are only for the 4.7.x version and only for mySQL.
We would like to share these with the rest of the Drupal community and we were wondering what the best way of doing this is?
Best place to start: http://drupal.org/node/7765 -- Cheers Anton (aka styro)
Hi Bjorn, Procedures for contributing modules are on the website. You will need a CVS account - which you can get by applying for one. Dan
Hi,
I've been developing on and off some modules for a client of mine. These are my first (so be gentle if I did something not a la the 'Drupal' way) Drupal modules and are only for the 4.7.x version and only for mySQL.
We would like to share these with the rest of the Drupal community and we were wondering what the best way of doing this is?
The plugins are documented using phpdoc for dev docs and include user documentation for the usage of the plugins. We tried to keep them multilingual although we haven't tested that (yet). At the moment the plugins are in English.
A short description of the plugins:
1) Consultation module.
Allows to consult registrated users either by web surveys or sms (needs a patched profile module and optionally the sms gateway module). Groups can be created based on profile parameters, these groups can be consulted using surveys either on the site or by sms. Surveys can be exported and imported. Consultations can be exported as CSV reports. Groups can be contacted by email or sms.
2) The Shicafe (SHow ICal FEeds) module
Is a small Drupal module, which facilitates the display of off-site events published via iCal feeds. It allows you to add, update and remove iCal feeds and show the corresponding events in a block on your Drupal site.
3) The Gimme module
Allowes a site owner to make news and/or events easily accessible via sms. One can send an sms keyword and receive a set number of node titles. It needs the smsgateway module installed.
ps: Due to time constraints I cannot (yet) update them to version 5 nor version 6
Looking forward to hear from you guys,
All the best,
grtz BjornW
Thanks Anton and Dan. I will apply for a CVS account. Dan Robinson wrote:
Hi Bjorn,
Procedures for contributing modules are on the website. You will need a CVS account - which you can get by applying for one.
Dan
Hi,
I've been developing on and off some modules for a client of mine. These are my first (so be gentle if I did something not a la the 'Drupal' way) Drupal modules and are only for the 4.7.x version and only for mySQL.
We would like to share these with the rest of the Drupal community and we were wondering what the best way of doing this is?
The plugins are documented using phpdoc for dev docs and include user documentation for the usage of the plugins. We tried to keep them multilingual although we haven't tested that (yet). At the moment the plugins are in English.
A short description of the plugins:
1) Consultation module.
Allows to consult registrated users either by web surveys or sms (needs a patched profile module and optionally the sms gateway module). Groups can be created based on profile parameters, these groups can be consulted using surveys either on the site or by sms. Surveys can be exported and imported. Consultations can be exported as CSV reports. Groups can be contacted by email or sms.
2) The Shicafe (SHow ICal FEeds) module
Is a small Drupal module, which facilitates the display of off-site events published via iCal feeds. It allows you to add, update and remove iCal feeds and show the corresponding events in a block on your Drupal site.
3) The Gimme module
Allowes a site owner to make news and/or events easily accessible via sms. One can send an sms keyword and receive a set number of node titles. It needs the smsgateway module installed.
ps: Due to time constraints I cannot (yet) update them to version 5 nor version 6
Looking forward to hear from you guys,
All the best,
grtz BjornW
participants (18)
-
Allie Micka -
Anton -
Bob -
Boris Mann -
Burobjorn -
Chris Johnson -
Dan Robinson -
Dries Buytaert -
Earnie Boyd -
Gerhard Killesreiter -
Gordon Heydon -
Karoly Negyesi -
Ken Rickard -
Khalid Baheyeldin -
Larry Garfield -
Marcelo Peñailillo Streb -
Walt Daniels -
Wim Leers