Lots of regressions in games in last few versions
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted. Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch. Bugs: 13120, 13110, 13101, 13086 and on and on and on. Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI? If the whole point of wine-1.0 is to have photoshop working - then we might as well call it 'wine-photoshop' get it into a separate tree and don't let any changes not related to photoshop there. Vitaliy.
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
Ya know there is a way to handle this. Bashing developers is not one of them. Regression testing is. Some of our 'users' are not savvy enough to figure out how to do this. We need to help them. Since I run a Mac and don't have access to some of these games and don't want to introduce the world to Apple's 'broken' X11, I cannot fill this need. However, others can and should. Now, are you going to be a part of the problem, or are you going to go out and find the culprit and fix it? Think about this and go forth and do great things. I expect nothing less from a person of your experience and abilities. In other word: Quit whining, and fix it. James McKenzie
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
Ya know there is a way to handle this. Bashing developers is not one of them. Regression testing is. Some of our 'users' are not savvy enough Oh really? So how many regression testing do you need to fix say... bug 11584 Multiple games crash with stack overflow error? 10? 20? 100 (look all the bugs marked as dups of it)? Unless some one actually starts fixing the bug, doing regression testing is pointless. Besides lots of new regressions have regression testing done on them.
In other word: Quit whining, and fix it. I'd love to but I can't. I don't have free several months to understand how d3d works. All the shaders, surfaces, textures, pixel formats, all the rules for choosing all the pixel formats, etc.
I'd like to trust all developers to make right decisions about what patches are low risk and which have to be tested with loads of apps. But it seems I can't. And no one saying what might break if some patch gets committed. And of course I understand that most things can't be tested with conformance tests there. But at least a minimum of several major titles have to be tested for regressions. Vitaliy.
Vitaliy Margolen wrote:
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
I'd like to trust all developers to make right decisions about what patches are low risk and which have to be tested with loads of apps. But it seems I can't. And no one saying what might break if some patch gets committed. And of course I understand that most things can't be tested with conformance tests there. But at least a minimum of several major titles have to be tested for regressions.
Vitaliy.
Vitaliy, I mostly use wine for games, and I agree with you that regressions with games regularly appear (not that it's so different from any other area whenever there's active development) and it sucks. To some extent, tests may help, but, unfortunately, even with tests things are still rather fragile. One reason is many different codepaths and variables that affect how wined3d works. To give an example, with an old game like Starcraft, you would have this: 1) DirectDrawRenderer: gdi or opengl if opengl, then 2) EXT_paletted_texture offered by driver or not 3) ARB_fragment_program offered or not 4) PBO available or not 5) various RenderTargetLockMode settings 6) various OffscreenRenderingMode settings Running tests on one machine may miss many breakages because of so many variables. On top of that, add the hazard of buggy and broken drivers. If we want to guarantee no regressions in major game titles, we must have a list of these titles and probably also volunteers who care about games to regularly test them with current git on different types of hardware and preferably also playing with the above mentioned settings while doing so. There is so much to test with these things a single person can't handle it, unless he has several computers with all kinds of popular hardware and many hours a day for this (and also many games, which nowadays tend to take gigabytes even for a demo). Basically this means making some titles part of either official or at least unofficial / "voluntary" release criteria. You are welcome to propose ideas about possible list of such titles. Regularly running conformance tests on specific hardware is also good, but in this case testers must be aware of known issues - failing tests sometimes mean known bugs in drivers, whereas if a game worked in the past but regressed it's definitely a wine problem. As for low risk, it's unfortunately difficult to assess, as, for example, it often happens that a relatively obvious, simple and correct fix breaks things because it exposes previously hidden bugs. Just my 0.02 € :).
On Sun, May 11, 2008 at 10:58 AM, Alexander Dorofeyev <alexd4(a)inbox.lv> wrote:
Vitaliy Margolen wrote:
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
I'd like to trust all developers to make right decisions about what patches are low risk and which have to be tested with loads of apps. But it seems I can't. And no one saying what might break if some patch gets committed. And of course I understand that most things can't be tested with conformance tests there. But at least a minimum of several major titles have to be tested for regressions.
Vitaliy.
Vitaliy,
I mostly use wine for games, and I agree with you that regressions with games regularly appear (not that it's so different from any other area whenever there's active development) and it sucks. To some extent, tests may help, but, unfortunately, even with tests things are still rather fragile. One reason is many different codepaths and variables that affect how wined3d works. To give an example, with an old game like Starcraft, you would have this:
1) DirectDrawRenderer: gdi or opengl
if opengl, then
2) EXT_paletted_texture offered by driver or not 3) ARB_fragment_program offered or not 4) PBO available or not 5) various RenderTargetLockMode settings 6) various OffscreenRenderingMode settings
Running tests on one machine may miss many breakages because of so many variables. On top of that, add the hazard of buggy and broken drivers.
If we want to guarantee no regressions in major game titles, we must have a list of these titles and probably also volunteers who care about games to regularly test them with current git on different types of hardware and preferably also playing with the above mentioned settings while doing so. There is so much to test with these things a single person can't handle it, unless he has several computers with all kinds of popular hardware and many hours a day for this (and also many games, which nowadays tend to take gigabytes even for a demo). Basically this means making some titles part of either official or at least unofficial / "voluntary" release criteria. You are welcome to propose ideas about possible list of such titles. Regularly running conformance tests on specific hardware is also good, but in this case testers must be aware of known issues - failing tests sometimes mean known bugs in drivers, whereas if a game worked in the past but regressed it's definitely a wine problem.
As for low risk, it's unfortunately difficult to assess, as, for example, it often happens that a relatively obvious, simple and correct fix breaks things because it exposes previously hidden bugs.
Just my 0.02 € :).
I think most of the participants in this thread thus far recognize the complexity of Wine and the difficulty of the task at hand. I do believe however, that Vitaliy's original arguement still stands. Are we working to make Wine 1.0 be the best at running applications that Wine has ever been? If so then reverting recent patches which break things is a good idea. If we're _only_ concerned about those 4 listed applications and those still work and the status of other regressions isn't as important then we continue and leave in the regressions. So it comes down to: Ship with known regressions, or ship with as few regressions as possible, even if it means reverting patches which may fix some things but break others. I think for the sake of 1.0 we _should_ revert known breakages, and reapply them after 1.0 and attempt to properly fix them. I'd love to see a Wine 1.0 that is, as Linus calls them, one of those 'magical releases' that just works and has almost no regressions. -Zach
"Zachary Goldberg" <zgs(a)seas.upenn.edu> writes:
I think most of the participants in this thread thus far recognize the complexity of Wine and the difficulty of the task at hand. I do believe however, that Vitaliy's original arguement still stands. Are we working to make Wine 1.0 be the best at running applications that Wine has ever been? If so then reverting recent patches which break things is a good idea. If we're _only_ concerned about those 4 listed applications and those still work and the status of other regressions isn't as important then we continue and leave in the regressions.
The goal is to ship with as few bugs as possible, whether they are regressions or not doesn't matter for users affected by the bug. I see no evidence that Wine as of two months ago was so wonderfully stable that going back to it would magically yield a bug-free 1.0. So yes, recent changes have caused regressions, just like about any other change in Wine. That's what code freeze is all about: try to fix the existing problems (including regressions) without introducing new ones. We've been in a code freeze for only a week now, I think it's a bit early to admit defeat and decide that we can't fix things without blindly reverting patches. -- Alexandre Julliard julliard(a)winehq.org
Alexandre, On Sun, May 11, 2008 at 11:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
"Zachary Goldberg" <zgs(a)seas.upenn.edu> writes:
I think most of the participants in this thread thus far recognize the complexity of Wine and the difficulty of the task at hand. I do believe however, that Vitaliy's original arguement still stands. Are we working to make Wine 1.0 be the best at running applications that Wine has ever been? If so then reverting recent patches which break things is a good idea. If we're _only_ concerned about those 4 listed applications and those still work and the status of other regressions isn't as important then we continue and leave in the regressions.
The goal is to ship with as few bugs as possible, whether they are regressions or not doesn't matter for users affected by the bug. I see no evidence that Wine as of two months ago was so wonderfully stable that going back to it would magically yield a bug-free 1.0.
I agree, and I'm of course not talking about reverting the entire tree. Vitaliy has mentioned a few specific patches though (mostly in d3d I think) which have caused some noise in the gaming realm. Those kinds of things are what I'm talking about and...
So yes, recent changes have caused regressions, just like about any other change in Wine. That's what code freeze is all about: try to fix the existing problems (including regressions) without introducing new ones. We've been in a code freeze for only a week now, I think it's a bit early to admit defeat and decide that we can't fix things without blindly reverting patches.
I think we're on the same page here. If we can narrow down regressions which require large changes (too large to go in during a code freeze or not enough time before release) the proper course of action for the sake of having as few bugs as possible in 1.0 is to revert those specific regression-introducing patches. You're right though, it has only been a week. These kinds of things may be best done in another week or two.
-- Alexandre Julliard julliard(a)winehq.org
--Zach
"Zachary Goldberg" <zgs(a)seas.upenn.edu> writes:
I agree, and I'm of course not talking about reverting the entire tree. Vitaliy has mentioned a few specific patches though (mostly in d3d I think) which have caused some noise in the gaming realm.
If Vitaliy or anybody else think a patch must be reverted, they need to point out the exact patch, explain why it can't be fixed properly for 1.0, and what other bugs will be reintroduced by reverting it. Reverting a patch is not a magical cure, and it can be just as risky as adding one, so it's not something we can do during code freeze without a detailed understanding of the consequences. -- Alexandre Julliard julliard(a)winehq.org
On Sun, May 11, 2008 at 1:15 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
"Zachary Goldberg" <zgs(a)seas.upenn.edu> writes:
I agree, and I'm of course not talking about reverting the entire tree. Vitaliy has mentioned a few specific patches though (mostly in d3d I think) which have caused some noise in the gaming realm.
If Vitaliy or anybody else think a patch must be reverted, they need to point out the exact patch, explain why it can't be fixed properly for 1.0, and what other bugs will be reintroduced by reverting it.
Reverting a patch is not a magical cure, and it can be just as risky as adding one, so it's not something we can do during code freeze without a detailed understanding of the consequences.
-- Alexandre Julliard julliard(a)winehq.org
Fair enough. I'll go through bugzilla on Tuesday (when finals end) and see if I can narrow down some problem patches. -- Zachary Goldberg Computer Science & Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania
Alexander Dorofeyev wrote:
Vitaliy Margolen wrote:
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
I'd like to trust all developers to make right decisions about what patches are low risk and which have to be tested with loads of apps. But it seems I can't. And no one saying what might break if some patch gets committed. And of course I understand that most things can't be tested with conformance tests there. But at least a minimum of several major titles have to be tested for regressions.
Vitaliy.
Vitaliy,
I mostly use wine for games, and I agree with you that regressions with games regularly appear (not that it's so different from any other area whenever there's active development) and it sucks. To some extent, tests may help, but, unfortunately, even with tests things are still rather fragile. One reason is many different codepaths and variables that affect how wined3d works. To give an example, with an old game like Starcraft, you would have this:
1) DirectDrawRenderer: gdi or opengl
if opengl, then
2) EXT_paletted_texture offered by driver or not 3) ARB_fragment_program offered or not 4) PBO available or not 5) various RenderTargetLockMode settings 6) various OffscreenRenderingMode settings
Running tests on one machine may miss many breakages because of so many variables. On top of that, add the hazard of buggy and broken drivers.
I understand that. However the person making a change should know which path is it. And have a hardware that can use this path. If not, then this patch should be tested by others with such hardware.
If we want to guarantee no regressions in major game titles, we must have a list of these titles and probably also volunteers who care about games to regularly We already have lots of people who using latest GIT. I'm talking about regressions that were introduced several versions ago and still not fixed.
As for low risk, it's unfortunately difficult to assess, as, for example, it often happens that a relatively obvious, simple and correct fix breaks things because it exposes previously hidden bugs. If developer can not tell if this is a hi risk or not, then such patch have to be marked as hi risk and should not be accepted while we are in the code freeze. Unless number of people test this patch on different hardware with different software and verify it's functionality.
We add more and more features to d3d which is wrong. This is exact point of code-freeze to accept low rusk fixes only. Vitaliy
Vitaliy Margolen wrote:
If developer can not tell if this is a hi risk or not, then such patch have to be marked as hi risk and should not be accepted while we are in the code freeze. Unless number of people test this patch on different hardware with different software and verify it's functionality.
We add more and more features to d3d which is wrong. This is exact point of code-freeze to accept low rusk fixes only. Some of those changes that date back to 0.9.58 or so obviously happened before the commitment to code freeze.
But I think that testing and reverting any patches submitted during code freeze that cause d3d regressions and can't be fixed real quick is a good idea.
Alexander Dorofeyev wrote:
Vitaliy Margolen wrote:
If developer can not tell if this is a hi risk or not, then such patch have to be marked as hi risk and should not be accepted while we are in the code freeze. Unless number of people test this patch on different hardware with different software and verify it's functionality.
We add more and more features to d3d which is wrong. This is exact point of code-freeze to accept low rusk fixes only. Some of those changes that date back to 0.9.58 or so obviously happened before the commitment to code freeze.
But I think that testing and reverting any patches submitted during code freeze that cause d3d regressions and can't be fixed real quick is a good idea.
They have to be fixed. That's the point. And if it takes big changes to fix it, then those patches have to be reverted. Again I'm not talking about what should have been done or that some one missed something pretty big. That's the way development goes. I'm talking about the same thing Alexandre said - if we have a regression that can not be easily fixed the patch that caused the regression have to be taken out. Also no more additional features that open up a can of worms! No more additional caps that all games starting to use! (until after 1.0) Vitaliy.
Well its not only Games, if you install office 2007 NOTHING works with RC-1! You have to revert back to 0.9.59 for it to work the best it ever did, then it's all down hill from each release forward ......As it looks Wine 1.0 will be a huge POS...... Just my $0.02 Tom On Sat, May 10, 2008 at 9:07 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
If the whole point of wine-1.0 is to have photoshop working - then we might as well call it 'wine-photoshop' get it into a separate tree and don't let any changes not related to photoshop there.
Vitaliy.
2008/5/11 Tom Wickline <twickline(a)gmail.com>:
Well its not only Games, if you install office 2007 NOTHING works with RC-1! You have to revert back to 0.9.59 for it to work the best it ever did, then it's all down hill from each release forward ......As it looks Wine 1.0 will be a huge POS......
That's unfair. To start with, the CodeWeavers team has been working on getting Office 2007 working, but that work is still *in progress*. What would be bad is if older versions of Office stopped working, as they have been working for a long time, and are part of CodeWeavers core business model. Also, Photoshop CS1 and CS2 were made to work on Wine. going further back, there was the latest ITunes (current reports on the AppDB are rating it Gold or Bronze, so it appears to still be functional with recent Wine versions). The problem is that as Wine gets closer to Windows, implementing more functionality, applications running on it are going to start to try and do new things (e.g. if they QueryInterface for an interface that Wine adds stubs for, the application is going to start calling that interface). Don't forget that as it stands, Wine is not (yet!) a complete Windows clone. Newer versions of applications tend to be more demanding on their API requirements, needing .NET or GDIPlus, or some other MS API that is not fully implemented by Wine. And the more recent a game is, the higher the DirectX version it needs, and the more they push the graphics card drivers. Note also with the games that IIRC, bugs in graphics card drivers are not being worked around, so some of the crashes may be due to driver bugs. On Vista, I have had a bad experience with the NVidia drivers, so that is not limited to Linux/Wine. As well as this, there are still various fixmes that may (or may not) contribute to some of the game crashes. DirectX is a complicated API which games can often abuse (I remember Stephan mention that some games have DirectX bugs in them), and the fact that games run *at all* is an incredible feat; Kudos to the wined3d developers. So while Wine is not perfect (it is definitely a work in progress) it has a good set of features and is long overdue for a 1.0 release. There is a balance between keeping code stable and improving it. This is especially true when reworking code to better support new functionality. I suspect that the improved DIB engine work will have a few regressions, but that work still needs to be done for performance reasons. If something is not working for you, file a bug. That is the only way to get the bugs fixed. Especially if something has regressed. Now is the time to be testing and filing bug reports. And to some extend, I agree with Vitality: every bug (unless there is a really good reason not to) should have an associated regression test so that it will not reappear in the future, but reverting any patch going that far back is too drastic and may be reverting a patch (or patches) that fix another bug. - Reece
Tom Wickline schrieb:
Well its not only Games, if you install office 2007 NOTHING works with RC-1! You have to revert back to 0.9.59 for it to work the best it ever did, then it's all down hill from each release forward ......As it looks Wine 1.0 will be a huge POS...... i don't even see the point of a 1.0 release at this point in time. This project has been a work in progress since 15 years. Why the heck has it been decided to do a 'gold' release *now* anyways? This actually resembles microsoft's own release policy: set a target date and deliver at that time, whatever reasons might speak against that. Why rush 1.0 out of the door? Me personally does not see any advantages to name it 1.0 (instead of f.e. 0.9.71), except that development has 'stabilized' (i.e. slowed down) - which obviously has not resulted in a more stable product. Anyone in the knows, please enlighten me on the motivations behind a release date in June 2008 for v1.0, i simply don't get it. regards marcel.
13120 - I'll run the test tomorrow if I can reproduce/no one has by then. 13110 - no one requested a regression test. I've requested it now. 13101 - not a regression 13086 - not sure if it's always existed or a regression. I asked for clarification. If anyone can identify regressions that haven't been bisected, shoot me an e-mail. I've got plenty of CPU/time to kill.
Austin English wrote:
13120 - I'll run the test tomorrow if I can reproduce/no one has by then. 13110 - no one requested a regression test. I've requested it now. 13101 - not a regression 13086 - not sure if it's always existed or a regression. I asked for clarification.
If anyone can identify regressions that haven't been bisected, shoot me an e-mail. I've got plenty of CPU/time to kill. I'd appreciate it if you can do a regression testing for bug 12272? Game blood 2 with demo. Between wine-0.9.44 and wine-0.9.45. You will need to use native dinput.dll. Start the game (enter, enter, enter) and move the mouse around. You should see that with .45 it's really jumpy and in .44 it's nice and smooth.
I think it's either ddraw or d3d. But might be some other place. Vitaliy
On Sun, May 11, 2008 at 11:31 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Austin English wrote:
13120 - I'll run the test tomorrow if I can reproduce/no one has by then. 13110 - no one requested a regression test. I've requested it now. 13101 - not a regression 13086 - not sure if it's always existed or a regression. I asked for clarification.
If anyone can identify regressions that haven't been bisected, shoot me an e-mail. I've got plenty of CPU/time to kill.
I'd appreciate it if you can do a regression testing for bug 12272? Game blood 2 with demo. Between wine-0.9.44 and wine-0.9.45. You will need to use native dinput.dll. Start the game (enter, enter, enter) and move the mouse around. You should see that with .45 it's really jumpy and in .44 it's nice and smooth.
I think it's either ddraw or d3d. But might be some other place.
Vitaliy
Just got back from vacation this weekend, and right when I start, you had already done it :-P. Oh well, if you get more in the future Vitaliy or anyone else, send me an e-mail/cc me on the bug. Most of the regressions you pointed out have already been run. -Austin
Austin English wrote:
On Sun, May 11, 2008 at 11:31 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Austin English wrote:
13120 - I'll run the test tomorrow if I can reproduce/no one has by then. 13110 - no one requested a regression test. I've requested it now. 13101 - not a regression 13086 - not sure if it's always existed or a regression. I asked for clarification.
If anyone can identify regressions that haven't been bisected, shoot me an e-mail. I've got plenty of CPU/time to kill.
I'd appreciate it if you can do a regression testing for bug 12272? Game blood 2 with demo. Between wine-0.9.44 and wine-0.9.45. You will need to use native dinput.dll. Start the game (enter, enter, enter) and move the mouse around. You should see that with .45 it's really jumpy and in .44 it's nice and smooth.
I think it's either ddraw or d3d. But might be some other place.
Vitaliy
Just got back from vacation this weekend, and right when I start, you had already done it :-P. Oh well, if you get more in the future Vitaliy or anyone else, send me an e-mail/cc me on the bug. Most of the regressions you pointed out have already been run.
Was kind of interested in it myself and had some idle CPU cycles <g> That bug is exactly the kind of problems we should try to avoid. I'm not entirely sure what it suppose to fix I can't see any difference with/without the patch. However it makes mouse pretty unusable - it gets really jerky like with < 5 FPS. Vitaliy.
participants (9)
-
Alexander Dorofeyev -
Alexandre Julliard -
Austin English -
James McKenzie -
Marcel Partap -
Reece Dunn -
Tom Wickline -
Vitaliy Margolen -
Zachary Goldberg