Description Sebastien Dubois 2012-02-20 11:24:00 EST

A new feature is suggested to be able to transfer anomalies from a Review Item that includes given versions of files to another one that contains more recent version of the same files.  This could be used e.g. during rework of anomalies raised in a given review.  See email thread below for more details:

-------------------------------------

The compare editor will compare the previous version of the file with the actual one i.e. in your example you will have version 4 as target file on the left side and version 3 as base file on the right side.  The cursor will be positionned at the anomaly position on the base file, since this is the one on which the anomaly was reported.
 
/Sebas



--------------------------------------------------------------------------------
From: David Hatton 
Sent: February-17-12 5:11 AM
To: Sebastien Dubois; 'r4e@mailman.lmera.ericsson.se'
Subject: RE: Possibility to Resubmit Changes for Re-Review


Hi Sebastien,
 
This looks to be a perfectly acceptable solution.
 
One minor question: in step (7) below, will the compare edtor compare versions 4 and 3 of the file, i.e. will the reviewer see the changes made since the anomaly was fixed, not the total changes since the review started?? If so, that would be perfect! If not, it is not a major issue.
 
/David
 
 

--------------------------------------------------------------------------------
From: Sebastien Dubois
Sent: 17 February 2012 00:16
To: David Hatton; 'r4e@mailman.lmera.ericsson.se'
Subject: RE: Possibility to Resubmit Changes for Re-Review


Hi David,
 
  That's actually a very good idea.  We had a discussion among the team and here's how this could be done
 
1) Author creates review, adds git commit to review which adds (e.g.) version 3 of a file.
2) Reviewer adds an anomaly on this file.
3) Review requires follow up.
4) Author updates file, commits in git, version 4 of the file has his fix.
5) Author marks anomaly as FIXED
6) Author creates a new review item, based on the latest commit.  R4E detects that the file that has been changed has a previous version in an already existing Review item for this review, so it links the new Review item with the original one and imports the anomalies written on the old version to the new review item (under a new element "updated anomalies").
7) Reviewer checks that the anomaly has been fixed by clicking on the updated anomaly in the new review item, the compare editor then opens and points to the location of the original anomaly in the base file (because we do not know where to point in the modified target file), sees the updated code in the target side of the compare editor, is happy, sets the anomaly to VERIFIED.
 
This is slightly different than what you propose but should be much easier to implement.  We just need to add the concept of linked review items and code to import anomalies written on the first version of the file to the current version.  The reason why we need a new Review Item is because each commit/query is its own review item, so we cannot put two versions of the same file included in the same Review Item.  
 
If you are OK with this approach, then we will put this in our backlog.
 
Regards, 
/Sebastien
 
PS:  BTW the modifications that you proposed and that we discussed a few weeks back regarding the properties view linking is implemented in the next Open R4E release, which should be out very soon (in a few days).



--------------------------------------------------------------------------------
From: r4e-bounces@mailman.lmera.ericsson.se [mailto:r4e-bounces@mailman.lmera.ericsson.se] On Behalf Of David Hatton
Sent: February-16-12 11:18 AM
To: 'r4e@mailman.lmera.ericsson.se'
Subject: [R4E] Possibility to Resubmit Changes for Re-Review


Hi,
 
Is there any possibility to include functionality like this to R4E:
 
1) Author creates review, adds git commit to review which adds (e.g.) version 3 of a file.
2) Reviewer adds an anomaly on this file.
3) Review requires follow up.
4) Author updates file, commits in git, version 4 of the file has his fix.
5) Author updates the file in review based on his latest commit, so version 4 of file now replaces version 3 in the review.
6) Author marks anomaly as FIXED
7) Reviewer checks anomaly, sees the updated code, is happy, sets the anomaly to VERIFIED.
 
I know we can maybe do something similar, but adding the commit changes in step 5 results in new review items which are not tracked to the original item or anomaly.
 
It would be good to allow the author re-submit a review items which overloads his original one, which would be aligned with the anomaly.
 
Maybe this is not possible, but would be a very nice feature.
 
/David