Hi,
looking into jira it's evident we still have a ton of patches
scheduled for 1.6.x and 1.7.x.
Now, the 1.6.x ones won't be surely addressed in any 1.6.x release,
since that series is long dead, and the 1.7.x ones are unlikely
to be fixed in any real 1.7.x either.
What we should do? Just blindly mass move all of them to 2.0.x?
A better way would be to scan each of them, see if it's still
applicable, and if not close it. E.g., many UI related ones
might be unapplicable now that we have the Wicket UI, or might
need to be modified in the report a little
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I was actually going to propose a jira cleanup / issue triage at foss4g but, but i have heard through the grapevine that their is going to be a geotools sprint, which works ok for me as well.
But yeah, cleanup++. For 1.7.x issues I would say any that are applicable to 2.x, we move forward into the 2.0.x void. For ones that are not applicable to 2.x like UI bug reports, I say we just close as won't fix. That or just keep them in the 1.7.x void.
Once we agree shall we divide and conquer?
Andrea Aime wrote:
Hi,
looking into jira it's evident we still have a ton of patches
scheduled for 1.6.x and 1.7.x.
Now, the 1.6.x ones won't be surely addressed in any 1.6.x release,
since that series is long dead, and the 1.7.x ones are unlikely
to be fixed in any real 1.7.x either.
What we should do? Just blindly mass move all of them to 2.0.x?
A better way would be to scan each of them, see if it's still
applicable, and if not close it. E.g., many UI related ones
might be unapplicable now that we have the Wicket UI, or might
need to be modified in the report a little
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Andrea Aime wrote:
Hi,
looking into jira it's evident we still have a ton of patches
scheduled for 1.6.x and 1.7.x.
Now, the 1.6.x ones won't be surely addressed in any 1.6.x release,
since that series is long dead, and the 1.7.x ones are unlikely
to be fixed in any real 1.7.x either.
What we should do? Just blindly mass move all of them to 2.0.x?
A better way would be to scan each of them, see if it's still
applicable, and if not close it. E.g., many UI related ones
might be unapplicable now that we have the Wicket UI, or might
need to be modified in the report a little
Cheers
Andrea
My 2 cents:
Projects of this size will always have a ton of issues that will never be addressed, if we move them all to 2.0.x we'll only end up drowning issues that have been reported more recently.
So I'd definitely not do a mass move. I think it's fine to leave most of them where they are, move up the ones we think are really important. Can also crowd source by sending a request to the -users list to make them bump any issues that they're still waiting to have resolved.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Justin Deoliveira ha scritto:
I was actually going to propose a jira cleanup / issue triage at foss4g but, but i have heard through the grapevine that their is going to be a geotools sprint, which works ok for me as well.
But yeah, cleanup++. For 1.7.x issues I would say any that are applicable to 2.x, we move forward into the 2.0.x void. For ones that are not applicable to 2.x like UI bug reports, I say we just close as won't fix. That or just keep them in the 1.7.x void.
Once we agree shall we divide and conquer?
I like that. Wondering how we do divide them thought.
Maybe by paging, or by issue number slots?
Like, someone all those between GEOS-1 and GEOS-1000, someone else
GEOT-1000 -> 1500, and so on. We should list all the open ones
assigned to older releases, sort, and assign an equal number
of issues to each of those that do volounteer to make the
triage
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Arne Kepp ha scritto:
Projects of this size will always have a ton of issues that will never be addressed, if we move them all to 2.0.x we'll only end up drowning issues that have been reported more recently.
2.0.x is really just another black hole, in my experience issues that
have not been assigned to a specific release tend to just stay
there unloved for a long long time.
Usually we move them to a specific release when it's clear they
are serious or enough people are complaining about them.
So I'd definitely not do a mass move. I think it's fine to leave most of them where they are, move up the ones we think are really important. Can also crowd source by sending a request to the -users list to make them bump any issues that they're still waiting to have resolved.
Sounds like a good idea. Actually users cannot move issues around, but
they can vote for them. So we could ask people to vote for the issues
for some time (maybe all august) and then we move out of the black
hole those that have high vote count?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Arne Kepp ha scritto:
So I'd definitely not do a mass move. I think it's fine to leave most of them where they are, move up the ones we think are really important. Can also crowd source by sending a request to the -users list to make them bump any issues that they're still waiting to have resolved.
Sounds like a good idea. Actually users cannot move issues around, but
they can vote for them. So we could ask people to vote for the issues
for some time (maybe all august) and then we move out of the black
hole those that have high vote count?
Sure, or just have them use the comment field. I'd be surprised if we even get 20 bumps, so on that assumption it should be okay to update the version manually.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
good idea involving the users... wonder if we could just ask them to vote for the ones they think are important, then we can filter by votes and assign them a release... even if it's "unspecified", then close the non relevant ones as won't fix?
Andrea Aime wrote:
Justin Deoliveira ha scritto:
I was actually going to propose a jira cleanup / issue triage at foss4g but, but i have heard through the grapevine that their is going to be a geotools sprint, which works ok for me as well.
But yeah, cleanup++. For 1.7.x issues I would say any that are applicable to 2.x, we move forward into the 2.0.x void. For ones that are not applicable to 2.x like UI bug reports, I say we just close as won't fix. That or just keep them in the 1.7.x void.
Once we agree shall we divide and conquer?
I like that. Wondering how we do divide them thought.
Maybe by paging, or by issue number slots?
Like, someone all those between GEOS-1 and GEOS-1000, someone else
GEOT-1000 -> 1500, and so on. We should list all the open ones
assigned to older releases, sort, and assign an equal number
of issues to each of those that do volounteer to make the
triage
Cheers
Andrea
Gabriel Roldan ha scritto:
good idea involving the users... wonder if we could just ask them to vote for the ones they think are important, then we can filter by votes and assign them a release... even if it's "unspecified", then close the non relevant ones as won't fix?
Yup. By close the non relevant ones you mean we hand check all the
remaining issue and close the non reproducable/no more applicable ones?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Gabriel Roldan ha scritto:
good idea involving the users... wonder if we could just ask them to vote for the ones they think are important, then we can filter by votes and assign them a release... even if it's "unspecified", then close the non relevant ones as won't fix?
Yup. By close the non relevant ones you mean we hand check all the
remaining issue and close the non reproducable/no more applicable ones?
yes. Though I don't see how to filter by votes now that I look at the find issues form?...
Cheers
Andrea
Gabriel Roldan ha scritto:
Andrea Aime wrote:
Gabriel Roldan ha scritto:
good idea involving the users... wonder if we could just ask them to vote for the ones they think are important, then we can filter by votes and assign them a release... even if it's "unspecified", then close the non relevant ones as won't fix?
Yup. By close the non relevant ones you mean we hand check all the
remaining issue and close the non reproducable/no more applicable ones?
yes. Though I don't see how to filter by votes now that I look at the find issues form?...
I think you cannot filter them, but you can sort them by vote number
(maybe the vote column is not visible in your profile, I know I modified
mine to show extra columns).
This should work:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10311&status=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=votes&sorter/order=DESC
(all open issues sorted by vote)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Gabriel Roldan ha scritto:
Andrea Aime wrote:
Gabriel Roldan ha scritto:
good idea involving the users... wonder if we could just ask them to vote for the ones they think are important, then we can filter by votes and assign them a release... even if it's "unspecified", then close the non relevant ones as won't fix?
Yup. By close the non relevant ones you mean we hand check all the
remaining issue and close the non reproducable/no more applicable ones?
yes. Though I don't see how to filter by votes now that I look at the find issues form?...
I think you cannot filter them, but you can sort them by vote number
(maybe the vote column is not visible in your profile, I know I modified
mine to show extra columns).
This should work:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10311&status=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=votes&sorter/order=DESC
(all open issues sorted by vote)
cool then!
so if you all agree we should call for elections 
users list message and a blog post may be?
Cheers,
Gabriel
Cheers
Andrea
I am strongly opposed to any mass changes of Jira issues.
In my view, the most useful piece of information we have on many community-reported issue is the last-updated field. This is a direct measure of the liveness of the issue. Gratuitous tagging destroys this information, not to mention making work for yourself. I propose that we retag an issue only when it is reconfirmed as affecting that release or branch. This will occur naturally when users search for existing bugs before reporting new ones (or Andrea cleans up after them). I fear that any Jira cleanup is an indication that we are not being lazy enough.
http://www.hhhh.org/wiml/virtues.html
Let sleeping issues lie.
--
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