Theoretically this sounds right, but I don't think it's worth the extra effort. We have not historically done separate code reviews of each backport, and if there are unique variations to backport a trunk fix to 1.6.x, someone just does that as part of the backporting and comments on the ticket. I am not interested in now having to walk tickets through the workflows for each released version.
The point is to make it easier for someone who has reviewed code and approved it to indicate that in the ticket. And creating a linked quasi-duplicate issue is more work. (I could live with it if we could create a new "Backport" issue type with simpler transitions, and somehow make it take only 1-2 clicks to spawn Backport tickets for all the relevant fix versions.) -Darius On Fri, Feb 24, 2012 at 12:01 PM, Michael Downey <[email protected]>wrote: > I would recommend doing what Drupal (I believe) and others do -- > create a linked, quasi-duplicate issue for the backport, referencing > the original patch. This will allow the backports to be delayed if > necessary without tying up a release (i.e., allowing the original > issue which necessitated the patch to be closed). It will also > accomodate any other variations or unique changes that may be required > in order to backport a fix to an older version. > > Thoughts? > > Michael > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
