Hi,
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
I'm attaching a Bugzilla patch which I think does this. I'm not submitting to wine-patches yet because I'm not able to test this. Also, I don't know if people think it's a good idea, so I thought I'd ask first.
-Ken
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
On Feb 9, 2014, at 7:27 PM, Dmitry Timoshkov wrote:
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
-Ken
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time.
On Feb 9, 2014, at 7:43 PM, Dmitry Timoshkov wrote:
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time.
The problem is that users retest with new releases of Wine and then update the Version field when they shouldn't. The desired behavior is for them to leave it at the earliest one where they found the problem. And if somebody happens to test an earlier version and finds that the bug existed back then, they should update the Version field to show that earlier version. Or, at least, that's what I've seen experienced bug wranglers do.
-Ken
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time.
The problem is that users retest with new releases of Wine and then update the Version field when they shouldn't. The desired behavior is for them to leave it at the earliest one where they found the problem. And if somebody happens to test an earlier version and finds that the bug existed back then, they should update the Version field to show that earlier version. Or, at least, that's what I've seen experienced bug wranglers do.
Version field should be never changed and left at the original version that the user had reported the problem for. There is no point in changing it to an earlier or a later one IMHO.
On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote:
Version field should be never changed and left at the original version that the user had reported the problem for. There is no point in changing it to an earlier or a later one IMHO.
Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.)
-Ken
On Feb 9, 2014 6:11 PM, "Ken Thomases" ken@codeweavers.com wrote:
On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote:
Version field should be never changed and left at the original version that the user had reported the problem for. There is no point in
changing
it to an earlier or a later one IMHO.
Well, if that's the consensus that develops, then perhaps we could
either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.)
I'd vote for b).
On Sun, 9 Feb 2014 18:14:35 -0800
Well, if that's the consensus that develops, then perhaps we could
either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.)
I'd vote for b).
Me, too. Especially the part about disabling setting the Severity field for non-admin users--that's an even worse problem than the Version field.
On Mon, Feb 10, 2014 at 3:10 AM, Ken Thomases ken@codeweavers.com wrote:
On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote:
Version field should be never changed and left at the original version that the user had reported the problem for. There is no point in changing it to an earlier or a later one IMHO.
Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.)
(b) would be best IMO.
BTW the Version field explanation can be found when hovering the "Version" field in bug creation form ("The version field defines the version of the software the bug was found in"). That sentence seems clear enough, although one could maybe replace "software" by "Wine".
On Mon, Feb 10, 2014 at 1:43 AM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Ken Thomases ken@codeweavers.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time.
-- Dmitry.
What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing? As it stands the version field is only useful for a split second at report time to tell users "The version you're using is too old". This could be automated with a bit of javascript and prevent unnecessary reports.
J. Leclanche
Jerome Leclanche adys.wh@gmail.com wrote:
I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field.
Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :)
Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people.
In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time.
-- Dmitry.
What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing?
One need to be a developer to comment on this I'd guess, but telling an exact used Wine version in the bug report is already a very good start.
As it stands the version field is only useful for a split second at report time to tell users "The version you're using is too old". This could be automated with a bit of javascript and prevent unnecessary reports.
Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade.
On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade.
I'd be in favour of dropping old versions, unfortunately I believe this involves thousands of existing bugs losing their current version field. Then again, I hate bugzilla and the new bug page is a UX disaster. The minuscule scroll areas for component/version, the attachment size limit which gives no warning at that point (and simply disappears once the bug is filed)... While we're talking about changes to the new bug UI, I'd like to suggest dropping Component from there altogether and put it in advanced fields (if editable by users at all - you need a pretty deep understanding of wine/windows APIs to pick one).
J. Leclanche
On 02/10/2014 08:47 AM, Jerome Leclanche wrote:
On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade.
I'd be in favour of dropping old versions, unfortunately I believe this involves thousands of existing bugs losing their current version field.
The best solution would be to keep the old versions but filter them out from the drop down that is presented to the users.
Then again, I hate bugzilla and the new bug page is a UX disaster. The minuscule scroll areas for component/version, the attachment size limit which gives no warning at that point (and simply disappears once the bug is filed)... While we're talking about changes to the new bug UI, I'd like to suggest dropping Component from there altogether and put it in advanced fields (if editable by users at all - you need a pretty deep understanding of wine/windows APIs to pick one).
The Component field is useful though I would prefer if we could drop the "directx-" prefix from the components that have it. The "Comp" field in the bug listings is too short and shows only "directx-".
bye michael
Jerome Leclanche adys.wh@gmail.com wrote:
Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade.
I'd be in favour of dropping old versions, unfortunately I believe this involves thousands of existing bugs losing their current version field.
Not listing old Wine versions at the bug reporting time and actually removing those versions from bugzilla altogether are two separate things.
Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade.
--
The AppDB already does that, so I can tell you from experience that users who cannot find their version on the list will simply choose one arbitrarily and then explain in a comment that they are really using version x, but it wasn't on the list.
On Mon, Feb 10, 2014 at 04:28:48PM +0900, Dmitry Timoshkov wrote:
Jerome Leclanche adys.wh@gmail.com wrote:
What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing?
One need to be a developer to comment on this I'd guess, but telling an exact used Wine version in the bug report is already a very good start.
I don't know. As a developer, I've never used that field for anything, and I find the "user changed version, admin changed it back" dance to be a distraction in my Bugs mailbox.
I'd be fine if we just eliminated the field entirely.
Andrew
Andrew Eikum aeikum@codeweavers.com wrote:
Jerome Leclanche adys.wh@gmail.com wrote:
What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing?
One need to be a developer to comment on this I'd guess, but telling an exact used Wine version in the bug report is already a very good start.
I don't know. As a developer, I've never used that field for anything, and I find the "user changed version, admin changed it back" dance to be a distraction in my Bugs mailbox.
Just add a e-mail filter?
I'd be fine if we just eliminated the field entirely.
You probably don't follow bugzilla close enough if the version field is not important to you. Quite often precise Wine version could be a sign of a known bug/fix/regression.
On Mon, Feb 10, 2014 at 11:18 AM, Andrew Eikum aeikum@codeweavers.com wrote:
On Mon, Feb 10, 2014 at 04:28:48PM +0900, Dmitry Timoshkov wrote:
Jerome Leclanche adys.wh@gmail.com wrote:
What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing?
One need to be a developer to comment on this I'd guess, but telling an exact used Wine version in the bug report is already a very good start.
I don't know. As a developer, I've never used that field for anything, and I find the "user changed version, admin changed it back" dance to be a distraction in my Bugs mailbox.
IMO that field is important for testing bugs in the correct or at least a close wine version in order to reproduce the issue.
I vote for setting the field as admin only, and maybe a "set once" for users when they report the bug, it then can be reset by admins later.
Regards, Bruno
IMO that field is important for testing bugs in the correct or at least a close wine version in order to reproduce the issue.
But it should be equally useful for this as long as it's a version where the bug is present. It doesn't matter whether it was the originally reported version. I've not seen any explanation in this thread of when any affected version is not good enough, and you really need to know the version the reporter was using. I believe there is no situation where that is important, and people changing it back are just adding noise to the bug for no good reason.
In fact, I would like to propose that we change the field's definition to be the LATEST WINE VERSION in which the bug is known to be present. This way, people retesting bugs won't have to flood them with comments of "still present in version x.y.x", and one can quickly search to find e.g. download bugs that weren't tested recently.
On Mon, Feb 10, 2014 at 5:32 PM, Vincent Povirk madewokherd@gmail.com wrote:
IMO that field is important for testing bugs in the correct or at least a close wine version in order to reproduce the issue.
But it should be equally useful for this as long as it's a version where the bug is present. It doesn't matter whether it was the originally reported version. I've not seen any explanation in this thread of when any affected version is not good enough, and you really need to know the version the reporter was using. I believe there is no situation where that is important, and people changing it back are just adding noise to the bug for no good reason.
In fact, I would like to propose that we change the field's definition to be the LATEST WINE VERSION in which the bug is known to be present. This way, people retesting bugs won't have to flood them with comments of "still present in version x.y.x", and one can quickly search to find e.g. download bugs that weren't tested recently.
As a bugzilla triager, I am extremely highly in favour of that. It makes a lot more sense for users, is a lot more easily explained and won't cause so much meta-drama. But then again, it's whatever is most useful to the devs that really matters.
J. Leclanche
On Mon, Feb 10, 2014 at 5:32 PM, Vincent Povirk madewokherd@gmail.com wrote:
I've not seen any explanation in this thread of when any affected version is not good enough, and you really need to know the version the reporter was using.
The only situation I can think of where this would be important is when the bug reporter claims it is a regression, but does not do a regression test. Someone who comes along later and is willing to run the regression test will want to know the first bad version. However, presumably that info would still be available in the bug's history field, so changing it in the version field shouldn't be a problem.
On Mon, Feb 10, 2014 at 6:32 PM, Vincent Povirk madewokherd@gmail.com wrote:
In fact, I would like to propose that we change the field's definition to be the LATEST WINE VERSION in which the bug is known to be present. This way, people retesting bugs won't have to flood them with comments of "still present in version x.y.x", and one can quickly search to find e.g. download bugs that weren't tested recently.
That's a bad idea IMO. Version field as "version where the bug was found" provides useful information as an "upper bound", i.e. for v_N, the bug appeared in V_i...V_N-1, V_N If you change the meaning of the field, you'd have to examine the bug history to find that info.
That's a bad idea IMO. Version field as "version where the bug was found" provides useful information as an "upper bound", i.e. for v_N, the bug appeared in V_i...V_N-1, V_N If you change the meaning of the field, you'd have to examine the bug history to find that info.
When would that information be useful apart from regressions? If it's only useful for regressions, aren't we optimizing for an uncommon case?
Generally, regressions will have that information in a comment anyway, and indirectly in the Regression SHA1 field.
On Mon, Feb 10, 2014 at 10:14 PM, Vincent Povirk madewokherd@gmail.com wrote:
That's a bad idea IMO. Version field as "version where the bug was found" provides useful information as an "upper bound", i.e. for v_N, the bug appeared in V_i...V_N-1, V_N If you change the meaning of the field, you'd have to examine the bug history to find that info.
When would that information be useful apart from regressions? If it's only useful for regressions, aren't we optimizing for an uncommon case?
The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays).
Bruno
The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays).
Why is the original version better for this purpose than a later version that was tested and known to be affected by the bug?
Vincent Povirk madewokherd@gmail.com wrote:
The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays).
Why is the original version better for this purpose than a later version that was tested and known to be affected by the bug?
It's always better to test using exact version that the user had in order to avoid any side effects of patches applied after that point, possible another regression, something else that may happen after that (like introducing new compiler optimization in default flags, changed config.h dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.)
Testing using a later Wine version may reproduce something that looks like an original bug but be not the same thing in reality.
On Mon, Feb 10, 2014 at 4:40 PM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Vincent Povirk madewokherd@gmail.com wrote:
The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays).
Why is the original version better for this purpose than a later version that was tested and known to be affected by the bug?
It's always better to test using exact version that the user had in order to avoid any side effects of patches applied after that point, possible another regression, something else that may happen after that (like introducing new compiler optimization in default flags, changed config.h dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.)
Testing using a later Wine version may reproduce something that looks like an original bug but be not the same thing in reality.
-- Dmitry
I think the number of cases where this would matter is trivial (compared to the overall problem of what the version field means/keeping that value meaningful).
Austin English austinenglish@gmail.com wrote:
The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays).
Why is the original version better for this purpose than a later version that was tested and known to be affected by the bug?
It's always better to test using exact version that the user had in order to avoid any side effects of patches applied after that point, possible another regression, something else that may happen after that (like introducing new compiler optimization in default flags, changed config.h dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.)
Testing using a later Wine version may reproduce something that looks like an original bug but be not the same thing in reality.
-- Dmitry
I think the number of cases where this would matter is trivial (compared to the overall problem of what the version field means/keeping that value meaningful).
Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find out an exact version that an original reporter had used. There are bug reports where somebody comes and says "The bug is back!", so in order to test whether this is a regression or the bug was never fixed one needs to test using an original Wine version.
Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find out an exact version that an original reporter had used. There are bug reports where somebody comes and says "The bug is back!", so in order to test whether this is a regression or the bug was never fixed one needs to test using an original Wine version.
In a situation like that you should be inspecting the comments anyway. The only difference if we change the version field is that you have to open the bug history, search for Version, and read the first entry to find out what the original reported version was (if that first entry is wrong, there will be a comment explaining what it actually is and why). And inspecting the comments will be faster because they won't be cluttered with "still present in x.y.z".
Vincent Povirk madewokherd@gmail.com wrote:
Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find out an exact version that an original reporter had used. There are bug reports where somebody comes and says "The bug is back!", so in order to test whether this is a regression or the bug was never fixed one needs to test using an original Wine version.
In a situation like that you should be inspecting the comments anyway. The only difference if we change the version field is that you have to open the bug history, search for Version, and read the first entry to find out what the original reported version was (if that first entry is wrong, there will be a comment explaining what it actually is and why).
For instance the Regression SHA1 field was introduced exactly to avoid searching through all the comments and filtering the wrong ones.
And inspecting the comments will be faster because they won't be cluttered with "still present in x.y.z".
I wouldn't be so sure about both of these statements :).
On Mon, Feb 10, 2014 at 9:35 PM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Vincent Povirk madewokherd@gmail.com wrote:
Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find
out
an exact version that an original reporter had used. There are bug
reports
where somebody comes and says "The bug is back!", so in order to test
whether
this is a regression or the bug was never fixed one needs to test using an original Wine version.
In a situation like that you should be inspecting the comments anyway. The only difference if we change the version field is that you have to open the bug history, search for Version, and read the first entry to find out what the original reported version was (if that first entry is wrong, there will be a comment explaining what it actually is and why).
For instance the Regression SHA1 field was introduced exactly to avoid searching through all the comments and filtering the wrong ones.
And inspecting the comments will be faster because they won't be cluttered with "still present in x.y.z".
I wouldn't be so sure about both of these statements :).
-- Dmitry.
A potential other option..two fields: First known buggy version: Last tested version:
(not necessarily a fan of it, just brainstorming)
A potential other option..two fields: First known buggy version: Last tested version:
(not necessarily a fan of it, just brainstorming)
I don't think there's a need for a compromise that makes it even more complicated. If we're not going to change the policy, making the version field write-once for most users is fine for enforcing it imo, and as long as we have the original reported version I don't think it's worth adding a field for the last tested one.
On Tue, 11 Feb 2014 01:03:52 -0600 Vincent Povirk madewokherd@gmail.com wrote:
I don't think there's a need for a compromise that makes it even more complicated. If we're not going to change the policy, making the version field write-once for most users is fine for enforcing it imo, and as long as we have the original reported version I don't think it's worth adding a field for the last tested one.
I agree.
As for whether the policy should be changed, I can think of one argument against it that hasn't been mentioned: we have a large body of experienced users who are accustomed to doing it the current way, no way to effectively communicate such an abrupt change in policy to all of them, and getting people to change their habits is far more difficult than changing the permissions on a field. In the short term, at least, such a change would lead to more noise in bugzilla as triagers have to explain to experienced users that we've suddenly decided to handle this in a way that is completely opposite to the way we've been doing it for years.
On Tue, Feb 11, 2014 at 11:51 AM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Tue, 11 Feb 2014 01:03:52 -0600 Vincent Povirk madewokherd@gmail.com wrote:
I don't think there's a need for a compromise that makes it even more complicated. If we're not going to change the policy, making the version field write-once for most users is fine for enforcing it imo, and as long as we have the original reported version I don't think it's worth adding a field for the last tested one.
I agree.
As for whether the policy should be changed, I can think of one argument against it that hasn't been mentioned: we have a large body of experienced users who are accustomed to doing it the current way, no way to effectively communicate such an abrupt change in policy to all of them, and getting people to change their habits is far more difficult than changing the permissions on a field. In the short term, at least, such a change would lead to more noise in bugzilla as triagers have to explain to experienced users that we've suddenly decided to handle this in a way that is completely opposite to the way we've been doing it for years.
What if the field is only editable by users when it's in the "unspecified" state, this way it would work as before. When changed from unspecified to any other the field would turn read only for users.
On Tue, Feb 11, 2014 at 5:13 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
On Tue, Feb 11, 2014 at 11:51 AM, Rosanne DiMesio dimesio@earthlink.net wrote:
What if the field is only editable by users when it's in the "unspecified" state, this way it would work as before. When changed from unspecified to any other the field would turn read only for users.
Simplest solution would be to make version field editable - upon bug creation for standard users - by admin users all the time
Frédéric
-
Andrew Eikum -
Austin English -
Bruno Jesus -
Dmitry Timoshkov -
Frédéric Delanoy -
Jerome Leclanche -
Ken Thomases -
Michael Stefaniuc -
Rosanne DiMesio -
Vincent Povirk