Hello,
I am to start packaging MariaDB for Fedora.
Is there anyone who wants to co-maintain?
This is just me wanting to post it for a package review.
On Sun, Oct 28, 2012 at 01:52:18PM -0600, Renich Bon Ciric wrote:
Hi,
I am to start packaging MariaDB for Fedora.
I've promised monty to get going with packaging MariaDB and I did create some local test packages which do work still need quite a few changes. I got busy with $dayjob for a while but I'm still eager to help move mariadb forward - so count me in.
Is there anyone who wants to co-maintain?
I'm interested in helping there.
This is just me wanting to post it for a package review.
The package review is probably going to be long and hard ;) - mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
On Sun, Oct 28, 2012 at 1:57 PM, Sven Lankes sven@lank.es wrote:
Hi,
I am to start packaging MariaDB for Fedora.
I've promised monty to get going with packaging MariaDB and I did create some local test packages which do work still need quite a few changes. I got busy with $dayjob for a while but I'm still eager to help move mariadb forward - so count me in.
Awesome! Thanks! ;=)
Is there anyone who wants to co-maintain?
I'm interested in helping there.
Ok.
This is just me wanting to post it for a package review.
The package review is probably going to be long and hard ;) - mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Yeah, I know. Let's see what comes out of this. I found this along the way: https://bugzilla.redhat.com/show_bug.cgi?id=753543
I don't know much about the "Alternatives" ... need to read a bit about it.
Anyway, I'd like to start from the bottom. Then, there're the tons of patches done to mysql; which I think we should drop for now and apply only if utterly necessary.
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Kevin Kofler
On Sun, Oct 28, 2012 at 4:31 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Keeping it simple and objective, IMHO, MariaDB is the natural choice. It has a community, it's GPL and it's not Oracle...
Besides, it is faster and nicer (It has some cool engines).
But that is just my opinion. Where should we take this to? Who can be an appropriate advocate for MariaDB?
On Sun, Oct 28, 2012 at 11:31:25PM +0100, Kevin Kofler wrote:
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
That may be the outcome of all of this. But that still means that we need MariaDB packaged first.
All forks of mysql are meant as a drop-in replacement. There is also at least PerconaDB with the same problem which would be interesting to package.
Sorry,I want to know why should we talk about MySQL....MariaDB team has already posted [1] about MariaDB10.0...They said they don't just want to become a 'brunch' of MySQL.
On 10/29/2012 04:36 AM, Sven Lankes wrote:
On Sun, Oct 28, 2012 at 11:31:25PM +0100, Kevin Kofler wrote:
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
That may be the outcome of all of this. But that still means that we need MariaDB packaged first.
On the one hand we could first prepare mariadb package (package review is frozen for a while, but I'll try to push that forward soon), but on the other hand we should know how we want to ship it -- and package it according to that.
This is why I'd like to refresh this topic, which froze too in a state with no resolution (at least I haven't noticed any).
What I'd like to achieve is to collect real risks (or pros & cons) of all possible solutions. Right now I see these options:
1. continue shipping only mysql 2. ship mysql + mariadb, that would conflict 3. ship mysql + mariadb with adjusted file-names and using alternatives 4. ship mysql + mariadb with adjusted file-names but not using alternatives 5. drop mysql and ship only mariadb 6. is there any other?
The following are notes I tried to summarized mainly from the thread started at http://lists.fedoraproject.org/pipermail/devel/2012-October/173089.html (+ some of my POVs)
ad 1. continue shipping only mysql:
PROS: * Admins would be happy (unless they care about early security updates, fixes and regression tests -- so probably not happy that much)
CONS: * No early (not only) security fixes * No new regression tests * It doesn't seem to me mysql upstream will ever become more open, the opposite is much more probable.
NOTE: Considering just changes made by Oracle during the last year made on mysql project I'd say we should only think about *how* and *when* switching to an alternative, not *if* anymore.
ad 2. ship mysql + mariadb, that would conflict:
PROS: * Probably the easiest way to do at least in the beginning.
CONS: * It would require twice much work to maintain two packages. * What message would we send to users - that we don't know what we want? * In a long term it doesn't look sustainable.
NOTE: It could be used in a transient period, e.g. during one release.
ad 3. ship mysql + mariadb with adjusted file-names and using alternatives
PROS: * To give an option to admins? I'm not really sure if this is even good.
CONS: * cons from 2. apply here * I don't think this is actually possible. Alternatives work fine with commands, but I haven't seen a usage of this tool for libraries and directories. * That would also require 100% API/ABI compatibility of libraries, which we can't depend on.
4. ship mysql + mariadb with adjusted file-names but not using alternatives
PROS: * We could provide both packages at the same time without conflicts
CONS: * cons from 2. apply here * We don't want to differ from upstream * What package depended packages would be built against?
ad 5: drop mysql and ship only mariadb
PROS: * We'll provide a package with active and open upstream, that cares about (not only) security bugs... * Some enhancements in comparison to mysql
CONS: * Transition could be harder, we would have to take this like a rebase (we probably can't depend on 100% API/ABI compatibility). * Admins would have to migrate.
NOTES: Similar will happen soon or later (at a time of rebasing to mysql-5.6). Right now my favorite one.
So what have I said wrong/omitted?
Regards, Honza
Le 13/12/2012 18:32, Honza Horak a écrit :
- continue shipping only mysql
- ship mysql + mariadb, that would conflict
Seems ok for 1 release.
- ship mysql + mariadb with adjusted file-names and using alternatives
- ship mysql + mariadb with adjusted file-names but not using alternatives
- drop mysql and ship only mariadb
For me, the good target.
- is there any other?
Remi
On Thu, 13 Dec 2012 19:52:17 +0100 Remi Collet Fedora@FamilleCollet.com wrote:
Le 13/12/2012 18:32, Honza Horak a écrit :
- continue shipping only mysql
- ship mysql + mariadb, that would conflict
Seems ok for 1 release.
- ship mysql + mariadb with adjusted file-names and using
alternatives 4. ship mysql + mariadb with adjusted file-names but not using alternatives 5. drop mysql and ship only mariadb
For me, the good target.
- is there any other?
I think I am with Remi on the above... shipping both for 1 release would be potentially helpful in seeing issues, we can ask people to migrate at that time and file bugs, if the bugs are stoppers they can go back to mysql until fixed. I guess it depends on the maintainer(s) involved if they feel this would be worthwhile.
Longer term I don't see too much advantage to continuing to ship both however, we should follow the better choice (as we did in cases like LibreOffice).
kevin
Kevin Fenzi kevin@scrye.com writes:
I think I am with Remi on the above... shipping both for 1 release would be potentially helpful in seeing issues, we can ask people to migrate at that time and file bugs, if the bugs are stoppers they can go back to mysql until fixed. I guess it depends on the maintainer(s) involved if they feel this would be worthwhile.
There will be very substantial costs to either of the schemes that allow mysql and mariadb to be installed in parallel. I'm pretty disinclined to expend the packaging effort, or the user-education effort, if the road map is that we're expecting to drop mysql altogether soon.
I'm OK with a ship-both-for-awhile plan as long as it's done by making the packages simply Conflict:. Otherwise I think we'll be doing too much throwaway work.
Personally, though, I lean to the just-do-it approach. Remember that mariadb is in the end a fork of mysql. It seems unlikely to me that there are bugs in it that are (a) not in mysql and (b) so catastrophic as to justify the work of dual-packaging, even in the stripped down form of just-make-them-conflict. So I'd rather just make the switch (early in a devel cycle) and fix any bugs we run into.
As an example of the sort of work I'd rather not do, if we want to have two packages then it'll be necessary to change BuildRequires in other packages if we want to build/test them against mariadb. If we go straight for the replacement approach, then we can say mariadb-devel Provides: mysql-devel, and no source changes are needed in other packages.
regards, tom lane
On Sun, 2012-10-28 at 23:31 +0100, Kevin Kofler wrote:
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other. It would be some packaging effort, but it would resolve the issue cleanly. This would fly so long as it's expected that there will be a long-term future for the 'MySQL-alike' world in which we have multiple competing implementations that are mutually compatible for many client apps. I'm not involved enough in the area to know if that's true.
Am 30.10.2012 01:08, schrieb Adam Williamson:
On Sun, 2012-10-28 at 23:31 +0100, Kevin Kofler wrote:
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other.
you can not compare a more or less standalone MTA with a package like mysql-libs where endless packages linked against!
i doubt MariaDb would be interface-compatible in most cases BUT not binary comatible as you can also not replace MySQL 5.1 against MySQL 5.5 without compat-packages (remi did outside fedora-packages) as long depending packages are linked against a specific version
PLEASE be careful to replace mysql distribution-wide i do not buy the 100% compatible argument in all cases
On Tue, 2012-10-30 at 01:20 +0100, Reindl Harald wrote:
Am 30.10.2012 01:08, schrieb Adam Williamson:
On Sun, 2012-10-28 at 23:31 +0100, Kevin Kofler wrote:
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other.
you can not compare a more or less standalone MTA with a package like mysql-libs where endless packages linked against!
I didn't compare anything. I suggested that the _mechanism_ we use in that case may also be appropriate in that case _if_ the circumstances merited it. I explicitly stated that I didn't know whether the circumstances actually do make it a sensible choice. I just floated the possibility.
I do wish you'd read with a bit more subtlety sometimes, Harald.
Am 30.10.2012 01:58, schrieb Adam Williamson:
On Tue, 2012-10-30 at 01:20 +0100, Reindl Harald wrote:
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other.
you can not compare a more or less standalone MTA with a package like mysql-libs where endless packages linked against!
I didn't compare anything. I suggested that the _mechanism_ we use in that case may also be appropriate in that case _if_ the circumstances merited it. I explicitly stated that I didn't know whether the circumstances actually do make it a sensible choice. I just floated the possibility.
I do wish you'd read with a bit more subtlety sometimes, Harald
don't get me wrong but where is subtlety necessary here?
* mysql-libs is a widely used and linked library * postfix/sendmail/exim is a binary with alternative symlinks
different worlds different implications
On Tue, 2012-10-30 at 02:03 +0100, Reindl Harald wrote:
Am 30.10.2012 01:58, schrieb Adam Williamson:
On Tue, 2012-10-30 at 01:20 +0100, Reindl Harald wrote:
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other.
you can not compare a more or less standalone MTA with a package like mysql-libs where endless packages linked against!
I didn't compare anything. I suggested that the _mechanism_ we use in that case may also be appropriate in that case _if_ the circumstances merited it. I explicitly stated that I didn't know whether the circumstances actually do make it a sensible choice. I just floated the possibility.
I do wish you'd read with a bit more subtlety sometimes, Harald
don't get me wrong but where is subtlety necessary here?
- mysql-libs is a widely used and linked library
- postfix/sendmail/exim is a binary with alternative symlinks
different worlds different implications
You're entirely missing the point.
I suggested a *packaging mechanism* that we use in another situation. Not a policy. The mechanism of having 'virtual provides' which multiple packages can each satisfy is proven to be an effective way of coping with a situation where multiple packages can provide a given function. I suggested that it could be used _if_ this case matches that description. Just because I mentioned sendmail and I mentioned mysql does not mean I am 'comparing' them.
Am 30.10.2012 02:08, schrieb Adam Williamson:
don't get me wrong but where is subtlety necessary here?
- mysql-libs is a widely used and linked library
- postfix/sendmail/exim is a binary with alternative symlinks
different worlds different implications
You're entirely missing the point.
I suggested a *packaging mechanism* that we use in another situation. Not a policy. The mechanism of having 'virtual provides' which multiple packages can each satisfy is proven to be an effective way of coping with a situation where multiple packages can provide a given function. I suggested that it could be used _if_ this case matches that description. Just because I mentioned sendmail and I mentioned mysql does not mean I am 'comparing' them
sorry, but you missed my point
there is *no* mechanism out there for dynmic linked libraries replaced with any other binary incomplatible format like alternatives, the application linked against a specific version will simply crash
for get the word 'compare'
it is not possible and if it would there would be no reason for mass-rebuilds after update to new so-versions of libs
On Tue, 2012-10-30 at 02:14 +0100, Reindl Harald wrote:
Am 30.10.2012 02:08, schrieb Adam Williamson:
don't get me wrong but where is subtlety necessary here?
- mysql-libs is a widely used and linked library
- postfix/sendmail/exim is a binary with alternative symlinks
different worlds different implications
You're entirely missing the point.
I suggested a *packaging mechanism* that we use in another situation. Not a policy. The mechanism of having 'virtual provides' which multiple packages can each satisfy is proven to be an effective way of coping with a situation where multiple packages can provide a given function. I suggested that it could be used _if_ this case matches that description. Just because I mentioned sendmail and I mentioned mysql does not mean I am 'comparing' them
sorry, but you missed my point
there is *no* mechanism out there for dynmic linked libraries replaced with any other binary incomplatible format like alternatives, the application linked against a specific version will simply crash
What? I'm not talking about anything like that.
Proper shared libraries aren't a problem in any case. We already have a perfectly adequate policy for that. By policy, so far as actual shared libraries are concerned, mysql-libs and mariadb-libs would have the exact same provides, if they were in fact providing ABI/API-compatible libraries, and would not have the same provides if they weren't.
it is not possible and if it would there would be no reason for mass-rebuilds after update to new so-versions of libs
You are assuming that mysql and mariadb's libraries will be API/ABI incompatible. I don't know if that's true or if it isn't, but in either case it's pretty irrelevant, because library provides are already specifically covered by a perfectly adequate policy.
Reindl Harald h.reindl@thelounge.net writes:
i doubt MariaDb would be interface-compatible in most cases BUT not binary comatible as you can also not replace MySQL 5.1 against MySQL 5.5 without compat-packages (remi did outside fedora-packages) as long depending packages are linked against a specific version
<facts> Just for the record, we *did* replace 5.1 with 5.5 without any compat package, back in Fedora 15. It seemed to go just fine; we had to rebuild dependent packages, but that was about it (and there weren't that many). I don't see any reason to think that replacing mysql with mariadb would be harder than the 5.1-to-5.5 transition was. </facts>
<opinion> And given Oracle's recent antics (refusal to release any information about security patches, not including new regression tests in releases, etc etc) we ought to be thinking very hard about doing just that. Reality is that mysql is now open source in name only. </opinion>
regards, tom lane
On Mon, 2012-10-29 at 21:21 -0400, Tom Lane wrote:
Reindl Harald h.reindl@thelounge.net writes:
i doubt MariaDb would be interface-compatible in most cases BUT not binary comatible as you can also not replace MySQL 5.1 against MySQL 5.5 without compat-packages (remi did outside fedora-packages) as long depending packages are linked against a specific version
<facts> Just for the record, we *did* replace 5.1 with 5.5 without any compat package, back in Fedora 15. It seemed to go just fine; we had to rebuild dependent packages, but that was about it (and there weren't that many). I don't see any reason to think that replacing mysql with mariadb would be harder than the 5.1-to-5.5 transition was. </facts>
<opinion> And given Oracle's recent antics (refusal to release any information about security patches, not including new regression tests in releases, etc etc) we ought to be thinking very hard about doing just that. Reality is that mysql is now open source in name only. </opinion>
regards, tom lane
Given oracle's "unkind" attitude, perhaps this should be a discussion of how to replace MySQL with MariaDB outright for say F19?
Am 30.10.2012 02:21, schrieb Tom Lane:
Reindl Harald h.reindl@thelounge.net writes:
i doubt MariaDb would be interface-compatible in most cases BUT not binary comatible as you can also not replace MySQL 5.1 against MySQL 5.5 without compat-packages (remi did outside fedora-packages) as long depending packages are linked against a specific version
<facts> Just for the record, we *did* replace 5.1 with 5.5 without any compat package, back in Fedora 15. It seemed to go just fine; we had to rebuild dependent packages, but that was about it (and there weren't that many). I don't see any reason to think that replacing mysql with mariadb would be harder than the 5.1-to-5.5 transition was. </facts>
and how do you rebuild all this packages against mysql-5.x AND mariadb to switch between both at runtime if one says "i use mariadb" and installs it by replacing mysql/mysql-libs?
in F15 you pushed 5.5 and so there was done a rebuild remi provided 5.5 for F14 and that is why he had to provide compat-libs to solve depencencies with official fedora packages
BTW: there was even a ABI-break between the first 5.5 releases that said to imagine how binary compatible mysql/mariadb will be over the long
On Mon, Oct 29, 2012 at 05:08:03PM -0700, Adam Williamson wrote:
On Sun, 2012-10-28 at 23:31 +0100, Kevin Kofler wrote:
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other. It would be some packaging effort, but it would resolve the issue cleanly. This would fly so long as it's expected that there will be a long-term future for the 'MySQL-alike' world in which we have multiple competing implementations that are mutually compatible for many client apps. I'm not involved enough in the area to know if that's true.
Actually... the MTAs don't conflict with each other.
-Toshio
On Mon, 2012-10-29 at 19:03 -0700, Toshio Kuratomi wrote:
On Mon, Oct 29, 2012 at 05:08:03PM -0700, Adam Williamson wrote:
On Sun, 2012-10-28 at 23:31 +0100, Kevin Kofler wrote:
Sven Lankes wrote:
mariadb will need to conflict with the default mysql packages which is usually not allowed in fedora. So this is going to be interesting.
Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it.
Well, we could also take the approach we take with MTAs; have a set of generic virtual Provides for MySQL-alikes and have all the MySQL-alikes we package Provide these, as well as Providing their own specific name, and conflict with each other. Just like postfix, qmail and sendmail all Provide: smtpd and conflict with each other. It would be some packaging effort, but it would resolve the issue cleanly. This would fly so long as it's expected that there will be a long-term future for the 'MySQL-alike' world in which we have multiple competing implementations that are mutually compatible for many client apps. I'm not involved enough in the area to know if that's true.
Actually... the MTAs don't conflict with each other.
oh, they use alternatives? My bad, I never actually tried installing multiple ones.
https://bugzilla.redhat.com/show_bug.cgi?id=875150
Spec URL: http://renich.fedorapeople.org/SPECS/mariadb.spec SRPM URL: http://renich.fedorapeople.org/SRPMS/
-- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric
On Mon, Nov 12, 2012 at 8:06 PM, Christopher Meng cickumqt@gmail.com wrote:
I just found this.
Nice find. Are you suggesting anything?
-- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric
So IMO I think now that we can accept different database tools into repo,it's available for us to include mariadb.Official says they will try to become a independent software but not a mod based on MySQL...
Maybe easy for review? I don't know exactly...
On Mon, Nov 12, 2012 at 8:45 PM, Christopher Meng cickumqt@gmail.com wrote:
So IMO I think now that we can accept different database tools into repo,it's available for us to include mariadb.Official says they will try to become a independent software but not a mod based on MySQL...
Maybe easy for review? I don't know exactly...
Thank you for that.
I will try to contact upstream today in order to seek guidance for the future and present.
-- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Christopher Meng -
Honza Horak -
Kevin Fenzi -
Kevin Kofler -
Reindl Harald -
Remi Collet -
Renich Bon Ciric -
Sven Lankes -
Tom Lane -
Toshio Kuratomi -
William