Hi all,
Any objection to adding a note in the release guide that instructs to turn off mail notification for the batch update of pushing back open issues? Rationale is that it is a lot of issues to go through for those who watch jira closely. I do this when I release but realized I never added it to the guide.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi all,
Any objection to adding a note in the release guide that instructs to turn off mail notification for the batch update of pushing back open issues? Rationale is that it is a lot of issues to go through for those who watch jira closely. I do this when I release but realized I never added it to the guide.
Not sure... reporters might want to know that their issues are being
pushed back
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Any objection to adding a note in the release guide that instructs to turn off mail notification for the batch update of pushing back open issues? Rationale is that it is a lot of issues to go through for those who watch jira closely. I do this when I release but realized I never added it to the guide.
Not sure... reporters might want to know that their issues are being
pushed back
Mass Jira spam is an indication that the labelling system is broken (or at least, cracked). Until it is fixed, I think Justin is doing the right thing, and it should be documented.
Perhaps we should encourage labelling with branches rather than tags? When someone sets fix-version 1.7.6, do they mean fix on 1.7.x? The problem is that when a patch is submitted, setting fix-version on a tag is speculation. The problem with dropping tags for fix-version is that end users will have trouble converting svn revisions back to release tags, so they won't know which release contains the fix.
Ideas?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Any objection to adding a note in the release guide that instructs to turn off mail notification for the batch update of pushing back open issues? Rationale is that it is a lot of issues to go through for those who watch jira closely. I do this when I release but realized I never added it to the guide.
Not sure... reporters might want to know that their issues are being
pushed backMass Jira spam is an indication that the labelling system is broken (or at least, cracked). Until it is fixed, I think Justin is doing the right thing, and it should be documented.
Perhaps we should encourage labelling with branches rather than tags? When someone sets fix-version 1.7.6, do they mean fix on 1.7.x? The problem is that when a patch is submitted, setting fix-version on a tag is speculation. The problem with dropping tags for fix-version is that end users will have trouble converting svn revisions back to release tags, so they won't know which release contains the fix.
Ideas?
Yeah, you're onto something there. The current behavior for labeling
has the following meaning (sort of, not formalized, it's more
the result of looking at the practice):
- if something is labeled for 1.7.5, it means it will be taken into
consideration for 1.7.5, but no guarantee it will be done
- if something is labeled for 1.7.x or 2.0.x... well, good luck having
that fixed, those two labels have historically acted as black holes,
once anything goes in there it's unlikely to be picked up by devs
which are already too busy with release tags
In an ideal world all issues should be fixed, in practice there are
too many, many cover corner cases or new features that no one has
resources to develop, so having quite a bit of open issues is
going to be a fact for the foreseeable future (813 open issues today:
http://jira.codehaus.org/browse/GEOS). For the causal reader, not
all of them are bugs, in jira we schedule also new features,
improvements, and tasks such as documenting something.
To avoid the issue of mass changing we could keep everything into 1.7.x
and cherry pick the issues we're going to fix at the beginning
of each cycle. However, who's going to go through 800 issues
to pick the ones to be fixed?
Ideally priorities could come in handy, but as you can see
from here: http://jira.codehaus.org/browse/GEOS
72% of the open issues have the default priority.
I'm also pretty sure that among those open issues there are quite
a bit that are duplicates, or issues that have been solved already.
Some cleanup in jira would be very much appreciated... but it's
going to be quite a task, and requires someone quite familiar
with the system (or ready to re-test every single report...)
I'm open to suggestions
Cheers
Anedrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.