some names for the new release along with their rationale... - perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..) - valentine (date based) - cupid (date based) (i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
how about "Make Love not War" ? We had "Don't Panic" =). On Tue, Feb 3, 2009 at 2:30 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
On Tue, Feb 3, 2009 at 1:30 PM, Dieter Plaetinck <dieter@plaetinck.be>wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
serenity requiem 42 monolith roll your own or hand rolled or rollin' down the river
On Tue, Feb 03, 2009 at 08:30:28PM +0100, Dieter Plaetinck wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
Fatal Error
2009/2/3, Dieter Plaetinck <dieter@plaetinck.be>:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
- survival - loving - future - heart - brainstorming -- Arch Linux Developer (voidnull) AUR & Pacman Italian Translations Microdia Developer http://www.archlinux.it
On Tue, Feb 3, 2009 at 8:30 PM, Dieter Plaetinck <dieter@plaetinck.be>wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
I like "Perseverance" and "Rebirth", though the second one will be great when using AIF instead of the current installer. -- Alexander
"Its a trap" 2009/2/3 Alexander De Sousa <aphanic@archlinux.us>:
On Tue, Feb 3, 2009 at 8:30 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
I like "Perseverance" and "Rebirth", though the second one will be great when using AIF instead of the current installer.
-- Alexander
hi from the top of my head, i thought of: -algorithm -cotton -transient will try to think harder... :) 2009/2/3 Chris Bannister <c.bannister@gmail.com>
"Its a trap"
2009/2/3 Alexander De Sousa <aphanic@archlinux.us>:
On Tue, Feb 3, 2009 at 8:30 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
I like "Perseverance" and "Rebirth", though the second one will be great when using AIF instead of the current installer.
-- Alexander
-- 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة fsf member #5439 usuario linux #471966 <a href="www.invencaobrasileira.org.br/fcl.html">frente de conhecimentos livres</a> <a href="www.atelier-labs.org">atelier-labs</a>
Genesis - The beginning of the releng assisted releases... and the other 'firsts' mentioned. Venus - Valentines release? That's all I've got... 2009/2/3 farid abdelnour <snd.noise@gmail.com>
hi
from the top of my head, i thought of:
-algorithm -cotton -transient
will try to think harder...
:)
2009/2/3 Chris Bannister <c.bannister@gmail.com>
"Its a trap"
2009/2/3 Alexander De Sousa <aphanic@archlinux.us>:
On Tue, Feb 3, 2009 at 8:30 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
some names for the new release along with their rationale...
- perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..)
- valentine (date based) - cupid (date based)
(i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)
I like "Perseverance" and "Rebirth", though the second one will be great when using AIF instead of the current installer.
-- Alexander
-- 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة fsf member #5439 usuario linux #471966 <a href="www.invencaobrasileira.org.br/fcl.html">frente de conhecimentos livres</a> <a href="www.atelier-labs.org">atelier-labs</a>
I say we call it Bikeshed. Vladislav
How is a decision about the name going to be made? Is it a good idea to add the suggested names to a poll and start voting after a few days of suggesting names? -- Jeroen Maris
On Tue, Feb 3, 2009 at 3:03 PM, Jeroen Maris <jamaris@gmail.com> wrote:
How is a decision about the name going to be made? Is it a good idea to add the suggested names to a poll and start voting after a few days of suggesting names?
This is why I'm not fond of codenames.
2009/2/4 Thayer Williams <thayerw@gmail.com>:
This is why I'm not fond of codenames.
+1 for not having codenames at all... very difficult to understand which is more 'proper'. It'd also be more practical to use versioning for the ISOs which is not dependent on anything else at all; for example the current method uses dates which means if the ISO is not made within the month, the version has to be changed. If we use kernel versions, it is much better; however there's still the small (though unlikely) chance that a particular kernel cannot be released with an ISO due to some showstopper bug. So the older method of versioning (0.8, 0.9 ...) was better in that sense, since it was not tied to any specific component (spatial, temporal or package). -- Abhishek
2009/2/4 Thayer Williams <thayerw@gmail.com>:
This is why I'm not fond of codenames.
+1 for not having codenames at all... very difficult to understand which is more 'proper'. It'd also be more
I would prefer a mix of date-related an unrelated versioning like taking the year and then counting the versions in that year up like 2009.1 is the first one in 2009. Of course there is still the possibility that versioning won't fit and we'll have to change the version from 2009.4 to 2010.1 but this can only happen once a year so I think this would be a quite good method. Greetings Stephan Am Mittwoch 04 Februar 2009 05:25:01 schrieb Abhishek Dasgupta: practical
to use versioning for the ISOs which is not dependent on anything else at all; for example the current method uses dates which means if the ISO is not made within the month, the version has to be changed.
If we use kernel versions, it is much better; however there's still the small (though unlikely) chance that a particular kernel cannot be released with an ISO due to some showstopper bug. So the older method of versioning (0.8, 0.9 ...) was better in that sense, since it was not tied to any specific component (spatial, temporal or package).
After some deep thought, I guess spring-summer-fall-winter seems like it would work good, that wouldn't tie the devs to any exact date. I'm just throwing that out there, it's realy up to you, the heavy lifters around here ;)
I think it would be wise to stay with the version numbering that we have right now, for example 2009.02 for the release coming this month. If any bug is found in the 2009.02-1 release, there can come a 2009.02-2 release, and so forth. The development versions for the 2009.02 series would be called 2009.02-alpha1, 2009.02-beta and 2009.02-rc, etcetera. The final version would be 2009.02-1. This way we would never run out of version numbers, one can see in the blink of an eye when a release was made, and this way of version numbering is very consistent and logical. The only downside that I can find about this way of versioning is what Dieter Plaetinck said on 2 februari, that it could interfere with flyspray references, that need to be updated in case a release can't be made in a certain month. -- Jeroen Maris
On Wed, 4 Feb 2009 12:26:00 +0100 Jeroen Maris <jamaris@gmail.com> wrote:
I think it would be wise to stay with the version numbering that we have right now, for example 2009.02 for the release coming this month. If any bug is found in the 2009.02-1 release, there can come a 2009.02-2 release, and so forth. The development versions for the 2009.02 series would be called 2009.02-alpha1, 2009.02-beta and 2009.02-rc, etcetera. The final version would be 2009.02-1.
This way we would never run out of version numbers, one can see in the blink of an eye when a release was made, and this way of version numbering is very consistent and logical. The only downside that I can find about this way of versioning is what Dieter Plaetinck said on 2 februari, that it could interfere with flyspray references, that need to be updated in case a release can't be made in a certain month.
-- Jeroen Maris
Maybe we if miss the right month (like we did now) we should just say "fuck it" and release it as 2009-01 anyway. Less confusion, no problems like beta's being released in january and finals in februari, no need to change references after date, etc. Will people really care that much that in february we do a release called 2009-01 ? It would make everything a bit easier, so let's keep it simple! That said, I like Dan's 'winter/summer' proposal. Technically there's the same problem because seasons switch on specific dates, but no-one will be too pedantic about that. (just like we shouldn't be with date based releases) I think Abhishek explained it well (depend on nothing), but I think it's good to have some idea at which point in time/ along with which kernel version a release was done. We just shouldn't be 100% strict about it. About the question which name we will pick, I'll find some online polling thing tonight if I have time and put the proposals on it. then we can vote. if we can't reach a consensus maybe we can just.. take the one I or Gerhard prefer :)) I don't even know how we will technically add the names to the release.. Aaron? Dieter
Like mentioned before, /etc/release might be a good idea. And it would also be nice if gnome's system monitor showed that name in the system information tab. I don't know however where gnome's system monitor gets that information. -- Jeroen Maris On Wed, Feb 4, 2009 at 2:11 PM, Dieter Plaetinck <dieter@plaetinck.be>wrote:
On Wed, 4 Feb 2009 12:26:00 +0100 Jeroen Maris <jamaris@gmail.com> wrote:
I think it would be wise to stay with the version numbering that we have right now, for example 2009.02 for the release coming this month. If any bug is found in the 2009.02-1 release, there can come a 2009.02-2 release, and so forth. The development versions for the 2009.02 series would be called 2009.02-alpha1, 2009.02-beta and 2009.02-rc, etcetera. The final version would be 2009.02-1.
This way we would never run out of version numbers, one can see in the blink of an eye when a release was made, and this way of version numbering is very consistent and logical. The only downside that I can find about this way of versioning is what Dieter Plaetinck said on 2 februari, that it could interfere with flyspray references, that need to be updated in case a release can't be made in a certain month.
-- Jeroen Maris
Maybe we if miss the right month (like we did now) we should just say "fuck it" and release it as 2009-01 anyway. Less confusion, no problems like beta's being released in january and finals in februari, no need to change references after date, etc.
Will people really care that much that in february we do a release called 2009-01 ? It would make everything a bit easier, so let's keep it simple!
That said, I like Dan's 'winter/summer' proposal. Technically there's the same problem because seasons switch on specific dates, but no-one will be too pedantic about that. (just like we shouldn't be with date based releases)
I think Abhishek explained it well (depend on nothing), but I think it's good to have some idea at which point in time/ along with which kernel version a release was done. We just shouldn't be 100% strict about it.
About the question which name we will pick, I'll find some online polling thing tonight if I have time and put the proposals on it. then we can vote. if we can't reach a consensus maybe we can just.. take the one I or Gerhard prefer :)) I don't even know how we will technically add the names to the release.. Aaron?
Dieter
On Wed, Feb 4, 2009 at 7:11 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
About the question which name we will pick, I'll find some online polling thing tonight if I have time and put the proposals on it. then we can vote. if we can't reach a consensus maybe we can just.. take the one I or Gerhard prefer :)) I don't even know how we will technically add the names to the release.. Aaron?
In the past we've done it internally with the devs. The codename USED TO BE on the ISO, but I dislike that... if we ARE codenaming these, then we will just use the filename or something. In the future we can consider changing things to use codenames and versioning and the like.
On Wed, 4 Feb 2009 17:37:49 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Feb 4, 2009 at 7:11 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
About the question which name we will pick, I'll find some online polling thing tonight if I have time and put the proposals on it. then we can vote. if we can't reach a consensus maybe we can just.. take the one I or Gerhard prefer :)) I don't even know how we will technically add the names to the release.. Aaron?
In the past we've done it internally with the devs. The codename USED TO BE on the ISO, but I dislike that... if we ARE codenaming these, then we will just use the filename or something. In the future we can consider changing things to use codenames and versioning and the like.
What are your arguments against putting codenames "on" the iso's? hard to implement cleanly/maintain ? Dieter
Am Thu, 5 Feb 2009 13:10:56 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
On Wed, 4 Feb 2009 17:37:49 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What are your arguments against putting codenames "on" the iso's? hard to implement cleanly/maintain ?
IMHO yes. We have had this on the December 2008 ISOs (and there only on the isolinux splash msg-files). Text in this messages files are (for color things) escaped by control code, so editing in some editors could completely break them. On grub we have never used (iso) version numbers or codenames. On /etc/issue (in the LiveCD) AFAIK we used it last on Overlord (and the FrosCon). So we have to automate this to put the correct versions/codenames in several files. And this is something which would get forgotten often IMHO - so all laugh at us when in 2019 the ISOs tell: I'm 2009.04... I'm now (after thinking and reading the mails) against any "branding" the ISOs/Images. **Only** in /arch directory and in the iso9660 structure (where the sqfs files live) i like to see a release version scheme like 2009.02-1 - only to identify the ISO (if one have a problem to install so we could ask in forums etc: Do you use the latest ISO? Uh, how can i check this? Look at: cat /arch/release or mount the ISO and do a: cat /media/cd/release. I agree with Aaron that we demonstrate the Arch "rolling release" better when we don't use any things that offers somewhat: Hey, they have releases... So: -1 for versions/codenames in any splash or message file +1 for putting the release month/revision in above mentioned text files (if we automate this).
Dieter
Gerhard
On Fri, 6 Feb 2009 15:07:43 +0100 Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Thu, 5 Feb 2009 13:10:56 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
On Wed, 4 Feb 2009 17:37:49 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What are your arguments against putting codenames "on" the iso's? hard to implement cleanly/maintain ?
IMHO yes. We have had this on the December 2008 ISOs (and there only on the isolinux splash msg-files). Text in this messages files are (for color things) escaped by control code, so editing in some editors could completely break them.
We can always just stick to the default colors (eg no fancy control characters)
On grub we have never used (iso) version numbers or codenames. On /etc/issue (in the LiveCD) AFAIK we used it last on Overlord (and the FrosCon). So we have to automate this to put the correct versions/codenames in several files. And this is something which would get forgotten often IMHO - so all laugh at us when in 2019 the ISOs tell: I'm 2009.04...
I'm now (after thinking and reading the mails) against any "branding" the ISOs/Images. **Only** in /arch directory and in the iso9660 structure (where the sqfs files live) i like to see a release version scheme like 2009.02-1 - only to identify the ISO (if one have a problem to install so we could ask in forums etc: Do you use the latest ISO? Uh, how can i check this? Look at: cat /arch/release or mount the ISO and do a: cat /media/cd/release.
I agree with Aaron that we demonstrate the Arch "rolling release" better when we don't use any things that offers somewhat: Hey, they have releases...
So: -1 for versions/codenames in any splash or message file +1 for putting the release month/revision in above mentioned text files (if we automate this).
Dieter
Gerhard
hey what about (only on the livecd) putting a file /arch/release containing the version number, and then in /etc/rc.sysinit we can do cat /arch/release 2>/dev/null. so that will work on every release and won't be harmful on normal systems that don't have /arch/release. In the same way we could in aif look if /arch/release exists and if so, display it in the header or whatever. We could also do the same for codenames (a la 'overlord', "don't panic" etc): check if the file exists and if not don't do anything with it. this way we can use the same packages for the livecd and installed systems. Dieter
On Thu, Feb 5, 2009 at 10:24 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Fri, 6 Feb 2009 15:07:43 +0100 Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Thu, 5 Feb 2009 13:10:56 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
On Wed, 4 Feb 2009 17:37:49 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What are your arguments against putting codenames "on" the iso's? hard to implement cleanly/maintain ?
IMHO yes. We have had this on the December 2008 ISOs (and there only on the isolinux splash msg-files). Text in this messages files are (for color things) escaped by control code, so editing in some editors could completely break them.
We can always just stick to the default colors (eg no fancy control characters)
On grub we have never used (iso) version numbers or codenames. On /etc/issue (in the LiveCD) AFAIK we used it last on Overlord (and the FrosCon). So we have to automate this to put the correct versions/codenames in several files. And this is something which would get forgotten often IMHO - so all laugh at us when in 2019 the ISOs tell: I'm 2009.04...
I'm now (after thinking and reading the mails) against any "branding" the ISOs/Images. **Only** in /arch directory and in the iso9660 structure (where the sqfs files live) i like to see a release version scheme like 2009.02-1 - only to identify the ISO (if one have a problem to install so we could ask in forums etc: Do you use the latest ISO? Uh, how can i check this? Look at: cat /arch/release or mount the ISO and do a: cat /media/cd/release.
I agree with Aaron that we demonstrate the Arch "rolling release" better when we don't use any things that offers somewhat: Hey, they have releases...
So: -1 for versions/codenames in any splash or message file +1 for putting the release month/revision in above mentioned text files (if we automate this).
Dieter
Gerhard
hey what about (only on the livecd) putting a file /arch/release containing the version number, and then in /etc/rc.sysinit we can do cat /arch/release 2>/dev/null. so that will work on every release and won't be harmful on normal systems that don't have /arch/release.
In the same way we could in aif look if /arch/release exists and if so, display it in the header or whatever.
We could also do the same for codenames (a la 'overlord', "don't panic" etc): check if the file exists and if not don't do anything with it. this way we can use the same packages for the livecd and installed systems.
I guess my biggest qualm here is that it's kinda difficult to pepper the release version around every place. This seems like a fairly clean solution, but it we get into the habit of adding it to /etc/issue and things like that, it could get annoying (I envision bug reports about us missing a file or two, and needing to rebuild ISOs for something so minor) If we add a file (I like /etc/arch-release better, FYI) we could incorporate it into the initscripts somehow... and maybe into the installer itself.
On Thu, 5 Feb 2009 11:29:58 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Feb 5, 2009 at 10:24 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Fri, 6 Feb 2009 15:07:43 +0100 Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Thu, 5 Feb 2009 13:10:56 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
On Wed, 4 Feb 2009 17:37:49 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What are your arguments against putting codenames "on" the iso's? hard to implement cleanly/maintain ?
IMHO yes. We have had this on the December 2008 ISOs (and there only on the isolinux splash msg-files). Text in this messages files are (for color things) escaped by control code, so editing in some editors could completely break them.
We can always just stick to the default colors (eg no fancy control characters)
On grub we have never used (iso) version numbers or codenames. On /etc/issue (in the LiveCD) AFAIK we used it last on Overlord (and the FrosCon). So we have to automate this to put the correct versions/codenames in several files. And this is something which would get forgotten often IMHO - so all laugh at us when in 2019 the ISOs tell: I'm 2009.04...
I'm now (after thinking and reading the mails) against any "branding" the ISOs/Images. **Only** in /arch directory and in the iso9660 structure (where the sqfs files live) i like to see a release version scheme like 2009.02-1 - only to identify the ISO (if one have a problem to install so we could ask in forums etc: Do you use the latest ISO? Uh, how can i check this? Look at: cat /arch/release or mount the ISO and do a: cat /media/cd/release.
I agree with Aaron that we demonstrate the Arch "rolling release" better when we don't use any things that offers somewhat: Hey, they have releases...
So: -1 for versions/codenames in any splash or message file +1 for putting the release month/revision in above mentioned text files (if we automate this).
Dieter
Gerhard
hey what about (only on the livecd) putting a file /arch/release containing the version number, and then in /etc/rc.sysinit we can do cat /arch/release 2>/dev/null. so that will work on every release and won't be harmful on normal systems that don't have /arch/release.
In the same way we could in aif look if /arch/release exists and if so, display it in the header or whatever.
We could also do the same for codenames (a la 'overlord', "don't panic" etc): check if the file exists and if not don't do anything with it. this way we can use the same packages for the livecd and installed systems.
I guess my biggest qualm here is that it's kinda difficult to pepper the release version around every place. This seems like a fairly clean solution, but it we get into the habit of adding it to /etc/issue and things like that, it could get annoying (I envision bug reports about us missing a file or two, and needing to rebuild ISOs for something so minor)
If we add a file (I like /etc/arch-release better, FYI) we could incorporate it into the initscripts somehow... and maybe into the installer itself.
Okay. makes sense. technical excellence and simplicity above all. As for the "how to know which iso release you're running after booting the cd" problem: you can always just check the kernel version. Dieter
Am Thu, 5 Feb 2009 20:17:09 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
On Thu, 5 Feb 2009 11:29:58 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
If we add a file (I like /etc/arch-release better, FYI) we could incorporate it into the initscripts somehow... and maybe into the installer itself.
How about /etc/iso-release? Or iso-version? So we prevent anything which could be interpreted as: arch has releases.
As for the "how to know which iso release you're running after booting the cd" problem: you can always just check the kernel version.
But not on uname base. Remember, we eventually would make releases on kernel.org minor upgrades (2.6.28.2 -> 2.6.28.3), so the kernel version as uname provide it not usefull here.
Dieter
Gerhard
Hi people! I installed ArchLinux-2009 which by the way is very good, I just had a problem after setting all the X and Gnome when I manually install the driver for video card NVIDIA GeForce FX 5200, has generated an error on the kernel by be 2.4 or 2.6 and requests the path to the kernel. Anyway, I did install the nvidia driver by pacman-173-xx. If someone can tell me why this error? I am not very good in English, if it contains any error in writing, please tell me. _________________________________________________________________ Receba GRÁTIS as mensagens do Messenger no seu celular quando você estiver offline. Conheça o MSN Mobile! http://mobile.live.com/signup/signup2.aspx?lc=pt-br
On Thu, Feb 5, 2009 at 2:54 PM, Flavio Lira <flaviolira1@hotmail.com> wrote:
Hi people!
I installed ArchLinux-2009 which by the way is very good, I just had a problem after setting all the X and Gnome when I manually install the driver for video card NVIDIA GeForce FX 5200, has generated an error on the kernel by be 2.4 or 2.6 and requests the path to the kernel. Anyway, I did install the nvidia driver by pacman-173-xx. If someone can tell me why this error?
Hi Flavio, This list is intended for system installation related discussions only. Your issue appears to be _after_ the installation, or beyond the installation itself. This is most likely a packaging or kernel bug. I would suggest you use the arch-general mailing list or http://bugs.archlinux.org for issues related to the kernel and nvidia. Cheers, Aaron
participants (17)
-
Aaron Griffin
-
Abhishek Dasgupta
-
Alexander De Sousa
-
Anton Liubchenko
-
Chris Bannister
-
dan schill
-
Dieter Plaetinck
-
farid abdelnour
-
Flavio Lira
-
Gerhard Brauer
-
Giovanni Scafora
-
Jeroen Maris
-
Loui Chang
-
Raul Leal
-
Stephan Platz
-
Thayer Williams
-
栄治