On 24/05/12 19:15, Jody Garnett wrote: > 2) Leave it open while waiting for confirmation from user list; and > close the issue if you get confirmation
No, no, (2) is the bit Justin wants to prevent. What if you tag an upcoming fixVersion of 2.2-beta3 and we skip straight to 2.2-rc1? Now some poor release manager has to re-open the issue and re-resolve it to change the fixVersion. What Justin wants to do (and I support) is that issues are only closed when a release is made. We are giving up the ability to use issue closed state to indicate confirmation that the problem is fixed. We can either wait for this before resolving or resolve if we are pretty sure and go back to open/in-progress if the problem is re-raised. The proposed workflow is your (0), (1), and then (3) when all the stable and trunk releases affected by the change are complete. (2) is way out: http://www.youtube.com/watch?v=xOrgLj9lOwk Kind regards, -- Ben Caradoc-Davies <[email protected]> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
