Hi List, for contributed modules, what is the prefered policy for setting issues to 'fixed' that have reviewed (!) patches attached: 1. when patch has been committed (providing the commit id) 2. when patch has been committed and is part of new release (providing release number) I have observed both ways, I believe. Thanks, Eric
When the patch has been committed. The issue should be referenced in the release notes of the next release. On Nov 18, 2008, at 2:05 PM, Eric-Alexander Schaefer wrote:
Hi List,
for contributed modules, what is the prefered policy for setting issues to 'fixed' that have reviewed (!) patches attached: 1. when patch has been committed (providing the commit id) 2. when patch has been committed and is part of new release (providing release number)
I have observed both ways, I believe.
Thanks, Eric
I agree with Darren on this - by definition, an issue can't be fixed in the 'current' release - because that's frozen, so it will always be fixed in the next one. And it seems like a lot of unnecessary work to go back marking issues as fixed when you actually roll a release. This does bring up an issue I've noticed a lot though - many users re-open issues which are marked fixed, because the bug is still present in whichever version of the module they're currently using. Also - if something gets fixed, and the next version of the module isn't released for some time, then the 'fixed' issue gets marked closed, drops out of the main issue view, and results in lots and lots of duplicates being posted because people don't see it. Would be worth considering ways to make these fixed issues more visible to those trying to report bugs. Nat
Maybe an extra state around the words of "Fix Released"? "Fixed" would be renamed to something like "Fix Committed", and only "Fix Released" would be auto-closed? I've had no problems as a contrib maintainer convincing users that they just needed to wait for the release. But I also admit that I release fixes for non-trivial bugs on a quick schedule of only a few days after the initial commit if no other problems are reported. -Aran On 18.11.2008 20:23, Nathaniel Catchpole wrote:
I agree with Darren on this - by definition, an issue can't be fixed in the 'current' release - because that's frozen, so it will always be fixed in the next one. And it seems like a lot of unnecessary work to go back marking issues as fixed when you actually roll a release.
This does bring up an issue I've noticed a lot though - many users re-open issues which are marked fixed, because the bug is still present in whichever version of the module they're currently using. Also - if something gets fixed, and the next version of the module isn't released for some time, then the 'fixed' issue gets marked closed, drops out of the main issue view, and results in lots and lots of duplicates being posted because people don't see it. Would be worth considering ways to make these fixed issues more visible to those trying to report bugs.
Nat
-- Nothing beside remains. Round the decay Of that colossal wreck, boundless and bare, The lone and level sands stretch far away. --------------------------------------------- AOL: realarancaytar / 282026638 XMPP: arancaytar.ilyaran@gmail.com PGP: http://ermarian.net/downloads/0x27CA5C74
Nathaniel Catchpole schrieb:
I agree with Darren on this - by definition, an issue can't be fixed in the 'current' release - because that's frozen, so it will always be fixed in the next one. And it seems like a lot of unnecessary work to go back marking issues as fixed when you actually roll a release.
Sounds reasonable. Thanks, Eric
participants (5)
-
Andrew Berry -
Arancaytar -
Darren Oh -
Eric-Alexander Schaefer -
Nathaniel Catchpole