How to update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<chris@simplistix.co.uk> wrote: ...
One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 <= some.egg < 1.1.0 ?
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated. We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need. - We need to create a test branch. - When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch. - We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6. - When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested. Thoughts? BTW, in my zopetoolkit dev branch, I've created a kgs directory to hold the ztk.cfg file and a ztk kgs buildout. If no one complains about this soon, I'll commit this to the trunk and this will become the official home of this info until we decide differently. Jim -- Jim Fulton
On Fri, Aug 14, 2009 at 1:20 PM, Jim Fulton<jim@zope.com> wrote:
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<chris@simplistix.co.uk> wrote: ...
One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 <= some.egg < 1.1.0 ?
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated.
+1
We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need.
The outlined approach sounds good to me. It will give us the opportunity to run tests on all supported platforms before changes hit the trunk of a particular package.
- When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch.
There is the minor concern that the test and trunk branches will get out of sync.
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
I assume we'd have OS X buildbots as well (if someone will volunteer them).
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
By "buildbot output" do you mean simply the fact that all tests passed on all platforms? -- Benji York Senior Software Engineer Zope Corporation
On Fri, Aug 14, 2009 at 1:58 PM, Benji York<benji@zope.com> wrote: ...
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
I assume we'd have OS X buildbots as well (if someone will volunteer them).
That would be a nice to have.
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
By "buildbot output" do you mean simply the fact that all tests passed on all platforms?
I'm being intentionally vague, but we need to know that the tests apply to the versions we're thinking of merging. At a minimum, the individual run outputs should contain the svn revision #. So, when merging changes, we make sure that the test branch changes being merged have been tested. Jim -- Jim Fulton
On Fri, Aug 14, 2009 at 2:13 PM, Jim Fulton<jim@zope.com> wrote:
On Fri, Aug 14, 2009 at 1:58 PM, Benji York<benji@zope.com> wrote:
By "buildbot output" do you mean simply the fact that all tests passed on all platforms?
I'm being intentionally vague, but we need to know that the tests apply to the versions we're thinking of merging. At a minimum, the individual run outputs should contain the svn revision #. So, when merging changes, we make sure that the test branch changes being merged have been tested.
I hesitate to suggest this (because it sounds like more work when we don't have enough volunteer's as-is), but how about if each branch had its tests run each time there was a commit made to it. That way we don't have to worry about mixing up changes in a single "test" branch and we'd also be able to tell -- by looking at the buildbot output for a particular branch -- if a branch that was being considered for merging to the trunk is actually passing on all platforms (OS and Python versions). I imagine that functionality would also be helpful to people developing on a branch. They could know if their changes cause tests to fail on platforms they might not have access to. -- Benji York Senior Software Engineer Zope Corporation
On Fri, Aug 14, 2009 at 2:29 PM, Benji York<benji@zope.com> wrote:
On Fri, Aug 14, 2009 at 2:13 PM, Jim Fulton<jim@zope.com> wrote:
On Fri, Aug 14, 2009 at 1:58 PM, Benji York<benji@zope.com> wrote:
By "buildbot output" do you mean simply the fact that all tests passed on all platforms?
I'm being intentionally vague, but we need to know that the tests apply to the versions we're thinking of merging. At a minimum, the individual run outputs should contain the svn revision #. So, when merging changes, we make sure that the test branch changes being merged have been tested.
I hesitate to suggest this (because it sounds like more work when we don't have enough volunteer's as-is), but how about if each branch had its tests run each time there was a commit made to it.
That way we don't have to worry about mixing up changes in a single "test" branch and we'd also be able to tell -- by looking at the buildbot output for a particular branch -- if a branch that was being considered for merging to the trunk is actually passing on all platforms (OS and Python versions).
I imagine that functionality would also be helpful to people developing on a branch. They could know if their changes cause tests to fail on platforms they might not have access to.
Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for? Jim -- Jim Fulton
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fulton<jim@zope.com> wrote:
Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for?
The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind. Beyond that there could be policies to take advantage of the infrastructure. A good policy might be that development is done on branches (as much development is done now) and a branch shouldn't be merged to the trunk unless all the tests pass (on all platforms). -- Benji York Senior Software Engineer Zope Corporation
On Fri, Aug 14, 2009 at 2:58 PM, Benji York<benji@zope.com> wrote:
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fulton<jim@zope.com> wrote:
Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for?
The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind.
Hm, that seems a bit to clever to me. There might be lots of checkins on branches before someone is ready to update the KGS.
Beyond that there could be policies to take advantage of the infrastructure. A good policy might be that development is done on branches (as much development is done now) and a branch shouldn't be merged to the trunk unless all the tests pass (on all platforms).
That seems pretty intrusive to me. I assume this would only apply to packages in the ZTK. I think I'd rather decouple management of individual projects from management of the KGS. I wonder what other people think. Jim -- Jim Fulton
On Fri, Aug 14, 2009 at 3:05 PM, Jim Fulton<jim@zope.com> wrote:
On Fri, Aug 14, 2009 at 2:58 PM, Benji York<benji@zope.com> wrote:
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fulton<jim@zope.com> wrote:
Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for?
The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind.
Hm, that seems a bit to clever to me. There might be lots of checkins on branches before someone is ready to update the KGS.
<shrug> Buildbots are machines, they can do lots of repetitive work without complaining.
Beyond that there could be policies to take advantage of the infrastructure. A good policy might be that development is done on branches (as much development is done now) and a branch shouldn't be merged to the trunk unless all the tests pass (on all platforms).
That seems pretty intrusive to me. I assume this would only apply to packages in the ZTK.
That's what I was thinking.
I think I'd rather decouple management of individual projects from management of the KGS. I wonder what other people think.
That's a reasonable stance. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fulton<jim@zope.com> wrote:
Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for?
The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind.
Ah, that's what my understanding was of Jim's term 'test branch', but now I realize I was wrong. Jim's "test branch" would be staging area for the trunk and only this staging area would get tested. Regards, Martijn
2009/8/14 Benji York <benji@zope.com>:
On Fri, Aug 14, 2009 at 1:20 PM, Jim Fulton<jim@zope.com> wrote:
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<chris@simplistix.co.uk> wrote: ...
One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 <= some.egg < 1.1.0 ?
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated.
+1
We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need.
The outlined approach sounds good to me. It will give us the opportunity to run tests on all supported platforms before changes hit the trunk of a particular package.
- When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch.
There is the minor concern that the test and trunk branches will get out of sync.
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
I assume we'd have OS X buildbots as well (if someone will volunteer them).
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
By "buildbot output" do you mean simply the fact that all tests passed on all platforms? -- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
I would like to volunteer OSX buildbot slaves, buildbot master if necessary. -- Jan-Jaap Driessen email: jdriessen@thehealthagency.com tel: +31 10 4445511 web: www.thehealthagency.com kvk: 24340866
Hello, * 2009-08-18 14:57, Jan-Jaap Driessen wrote:
I would like to volunteer OSX buildbot slaves, buildbot master if necessary.
I'm currently running a buildbot master with two salves (linux 32bit and 64bit): http://buildbot.tranchitella.it/ztk/ It is running the tests in the trunk for all the packages in the ZTK (as defined by Jim) as well as the ZTK KGS tests with compattest. Will we have an "official" buildbot instance somewhere under the zope.org domain? In this case, I'm willing to administer and maintain it, if nobody else steps in. Best regards, Fabio
Hi there, Fabio Tranchitella wrote: [snip]
Will we have an "official" buildbot instance somewhere under the zope.org domain? In this case, I'm willing to administer and maintain it, if nobody else steps in.
I'd be happy to see this. We can do this with a DNS thing (buildout.zope.org) or we can actually run something on zope.org if someone explains what should be done to Jens. (the minimal info of: this script needs to be run every n hours). Regards, Martijn
2009/8/25 Martijn Faassen <faassen@startifact.com>:
Hi there,
Fabio Tranchitella wrote: [snip]
Will we have an "official" buildbot instance somewhere under the zope.org domain? In this case, I'm willing to administer and maintain it, if nobody else steps in.
I'd be happy to see this. We can do this with a DNS thing (buildout.zope.org) or we can actually run something on zope.org if someone explains what should be done to Jens. (the minimal info of: this script needs to be run every n hours).
Regards,
Martijn
Hi Martijn, Fabio Tranchitella, Sebastien Douche and I are combining our efforts for a ztk-kgs buildbot. I set up a buildbot and 12 slaves for testing the kgs (svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs). The setup is still on my local machine, so I share the preliminary results through pastebin.com: python 2.4 on winxp : http://pastebin.com/m28ef94cc - zope.testing - zope.dottedname python 2.5 on winxp : http://pastebin.com/f48e61f38 - zope.testing - zope.app.twisted (may be related to running the tests inside a buildbot environment) - zope.dottedname python 2.6 on winxp : http://pastebin.com/f6286c78e - zope.testing - zope.app.dav - zope.dottedname python 2.4 and 2.5 on ubuntu 32bit, ubuntu 64bit and osx: no failures. python2.6 tests fail on ubuntu 32bit, ubuntu 64bit and osx: http://pastebin.com/m4302c60d - zope.testing We hope to bring the buildbot online soon. Kind regards, -- Jan-Jaap Driessen email: jdriessen@thehealthagency.com tel: +31 10 4445511 web: www.thehealthagency.com kvk: 24340866
Hello, That's great. I think if this works we should include some more mission critical packages, like zc.buildout. (Last time I checked zc.buildout had very bad test results on win32) Wednesday, August 26, 2009, 4:46:37 PM, you wrote: JJD> 2009/8/25 Martijn Faassen <faassen@startifact.com>:
Hi there,
Fabio Tranchitella wrote: [snip]
Will we have an "official" buildbot instance somewhere under the zope.org domain? In this case, I'm willing to administer and maintain it, if nobody else steps in.
I'd be happy to see this. We can do this with a DNS thing (buildout.zope.org) or we can actually run something on zope.org if someone explains what should be done to Jens. (the minimal info of: this script needs to be run every n hours).
Regards,
Martijn
JJD> Hi Martijn, JJD> Fabio Tranchitella, Sebastien Douche and I are combining our efforts JJD> for a ztk-kgs buildbot. JJD> I set up a buildbot and 12 slaves for testing the kgs JJD> (svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs). The JJD> setup is still on my local machine, so I share the preliminary results JJD> through pastebin.com: JJD> python 2.4 on winxp : http://pastebin.com/m28ef94cc JJD> - zope.testing JJD> - zope.dottedname JJD> python 2.5 on winxp : http://pastebin.com/f48e61f38 JJD> - zope.testing JJD> - zope.app.twisted (may be related to running the tests inside a JJD> buildbot environment) JJD> - zope.dottedname JJD> python 2.6 on winxp : http://pastebin.com/f6286c78e JJD> - zope.testing JJD> - zope.app.dav JJD> - zope.dottedname JJD> python 2.4 and 2.5 on ubuntu 32bit, ubuntu 64bit and osx: no failures. JJD> python2.6 tests fail on ubuntu 32bit, ubuntu 64bit and osx: JJD> http://pastebin.com/m4302c60d JJD> - zope.testing JJD> We hope to bring the buildbot online soon. JJD> Kind regards, -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Absence sharpens love, presence strengthens it. - Anonymous
On Friday 14 August 2009, Jim Fulton wrote:
Thoughts?
Sounds good to me.
BTW, in my zopetoolkit dev branch, I've created a kgs directory to hold the ztk.cfg file and a ztk kgs buildout. If no one complains about this soon, I'll commit this to the trunk and this will become the official home of this info until we decide differently.
Why did you start using a new format for the KGS? I had written a lot of tools for zope.kgs that are very handy when it comes to actually creating releases and other things. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Mon, Aug 17, 2009 at 8:38 AM, Stephan Richter<srichter@cosmos.phy.tufts.edu> wrote:
On Friday 14 August 2009, Jim Fulton wrote:
Thoughts?
Sounds good to me.
BTW, in my zopetoolkit dev branch, I've created a kgs directory to hold the ztk.cfg file and a ztk kgs buildout. If no one complains about this soon, I'll commit this to the trunk and this will become the official home of this info until we decide differently.
Why did you start using a new format for the KGS? I had written a lot of tools for zope.kgs that are very handy when it comes to actually creating releases and other things.
This is discussed in another thread. Basically, it boils down to being simpler, less repetitive, and easier to work with. Jim -- Jim Fulton
On Mon, Aug 17, 2009 at 8:43 AM, Jim Fulton<jim@zope.com> wrote:
On Mon, Aug 17, 2009 at 8:38 AM, Stephan Richter<srichter@cosmos.phy.tufts.edu> wrote:
On Friday 14 August 2009, Jim Fulton wrote:
Thoughts?
Sounds good to me.
BTW, in my zopetoolkit dev branch, I've created a kgs directory to hold the ztk.cfg file and a ztk kgs buildout. If no one complains about this soon, I'll commit this to the trunk and this will become the official home of this info until we decide differently.
Why did you start using a new format for the KGS? I had written a lot of tools for zope.kgs that are very handy when it comes to actually creating releases and other things.
This is discussed in another thread.
Basically, it boils down to being simpler, less repetitive, and easier to work with.
BTW, I should have noted that the only tool I really care about is a tool that correctly runs the KGS tests, which we haven't had until now. - Runs each projects as a separate process to avoid test interference and to catch missing dependencies. - Uses the same project versions for all tests. Jim -- Jim Fulton
On Fri, Aug 14, 2009 at 19:20, Jim Fulton<jim@zope.com> wrote: Hi Jim
- We need to create a test branch.
- When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch.
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
Thoughts?
1. When the new system will be the default way? 2. Can you list the steps needed by the new system? (co, bin/test,...) 3. Do you want Py2.4 buildbot for Zope 2.5? Nota: I don't have Windows buildbot. Cheers -- Sebastien Douche <sdouche@gmail.com> Twitter: http://bit.ly/afkrK (agile, python, open source)
On Mon, Aug 17, 2009 at 9:33 AM, Sebastien Douche<sdouche@gmail.com> wrote:
On Fri, Aug 14, 2009 at 19:20, Jim Fulton<jim@zope.com> wrote:
Hi Jim
- We need to create a test branch.
- When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch.
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
Thoughts?
1. When the new system will be the default way?
When we all agree on it and maybe when the tests pass on all platforms (or maybe sooner).
2. Can you list the steps needed by the new system? (co, bin/test,...)
Not until we finalize some things.
3. Do you want Py2.4 buildbot for Zope 2.5?
Huh? We'll want buildbots for Python 2.4, 2.5, and 2.6
Nota: I don't have Windows buildbot.
Hopefully, someone else can help with that. Jim -- Jim Fulton
Jim Fulton wrote:
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<chris@simplistix.co.uk> wrote: ...
One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 <= some.egg < 1.1.0 ?
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated.
+1. No ranges. If you want to update a version in your own app's buildout you should be able to override it, of course, but the KGS should be a fixed point.
We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need.
- We need to create a test branch.
- When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch.
- We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6.
- When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested.
Thoughts?
That sounds reasonable, as long as it is documented. I got confused at first about the term 'test branch', but you just mean a non-maintenance branch of a package to do some development on. The special thing is here that we'd wait for the buildbot to do the testing on different platforms. I wonder whether we couldn't use snakebite.org infrastructure for the testing. I'd be good if someone could manually trigger a cross-platform cross-interpreter test instead of having to wait for buildbots. Regards, Martijn
On Tue, Aug 25, 2009 at 12:21 PM, Martijn Faassen<faassen@startifact.com> wrote: ...
That sounds reasonable, as long as it is documented. I got confused at first about the term 'test branch', but you just mean a non-maintenance branch of a package to do some development on. The special thing is here that we'd wait for the buildbot to do the testing on different platforms.
No, I meant a dedicated staging branch. Basically, work would be done on a development branch, them merged to a stage branch and after all tests pass, merged to trunk.
I wonder whether we couldn't use snakebite.org infrastructure for the testing. I'd be good if someone could manually trigger a cross-platform cross-interpreter test instead of having to wait for buildbots.
Is snakebite real? That page has said "coming soon" for a long time. Jim -- Jim Fulton
Jim Fulton wrote:
On Tue, Aug 25, 2009 at 12:21 PM, Martijn Faassen<faassen@startifact.com> wrote: ...
That sounds reasonable, as long as it is documented. I got confused at first about the term 'test branch', but you just mean a non-maintenance branch of a package to do some development on. The special thing is here that we'd wait for the buildbot to do the testing on different platforms.
No, I meant a dedicated staging branch. Basically, work would be done on a development branch, them merged to a stage branch and after all tests pass, merged to trunk.
Understood (also from the context elsewhere).
I wonder whether we couldn't use snakebite.org infrastructure for the testing. I'd be good if someone could manually trigger a cross-platform cross-interpreter test instead of having to wait for buildbots.
Is snakebite real? That page has said "coming soon" for a long time.
Good question. I thought it was going for selected python projects, but checking their mailing list indicates they're having teething problems. So it doesn't appear to be ready yet, though there's still people working on it. Regards, Martijn
On Tue, Aug 25, 2009 at 18:21, Martijn Faassen<faassen@startifact.com> wrote:
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated.
+1. No ranges. If you want to update a version in your own app's buildout you should be able to override it, of course, but the KGS should be a fixed point.
Agree, but Buildout doesn't support ranges. -- Sebastien Douche <sdouche@gmail.com> Twitter: http://bit.ly/afkrK (agile, python, open source)
On Fri, Aug 28, 2009 at 5:35 AM, Sebastien Douche<sdouche@gmail.com> wrote:
On Tue, Aug 25, 2009 at 18:21, Martijn Faassen<faassen@startifact.com> wrote:
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated.
+1. No ranges. If you want to update a version in your own app's buildout you should be able to override it, of course, but the KGS should be a fixed point.
Agree, but Buildout doesn't support ranges.
Sure it does, just not as part of the versions section. Despite that, I don't know what your point is. Jim -- Jim Fulton
participants (8)
-
Adam GROSZER -
Benji York -
Fabio Tranchitella -
Jan-Jaap Driessen -
Jim Fulton -
Martijn Faassen -
Sebastien Douche -
Stephan Richter