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 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?
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. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
