search

aodn / geoserver-build

Configures a GeoServer war containing extensions and configuration required by AODN instances
Other
2 stars 4 forks source link

JavaDuck on CARS without geographic subset #231

Closed ggalibert closed 7 years ago

ggalibert commented 7 years ago

When downloading the full CARS monthly on step 3 (no temporal or geographical subset applied), the file produced only contains longitude values from 0 to 180 while the original file includes values from 0 to 360!

screenshot from 2017-05-22 17-18-06

ggalibert commented 7 years ago

BTW, I'm not able to assign anyone nor put any label (bug in this case).

ggalibert commented 7 years ago

@pblain It's a bit of a pity I didn't get to be involved in the testing of this fix before closing the issue. It might be good practice to involve whoever lodged an issue in the testing of a fix for this issue.

I have just had a look on the portal and it doesn't seem the problem is fixed. Is this because the fix hasn't been deployed yet?

jonescc commented 7 years ago

Hasn't been systested or deployed to production yet.

pblain commented 7 years ago

@ggalibert - This workflow is something we've discussed at length in the past - but it's been a few years so I'll remind everyone how it works:

When a developer has finished working on a bug, and after it's been peer reviewed (dodded) by another developer, the issue is closed.

Your chance to review the work is in the testing week - after the review. Prior to each review I send out a list of all bugs that were worked on. If your bug is on the list, or if you see that it's been closed, you should take a look in systest (after it's deployed to systest) and make sure you're happy with the fix. You can also ask for a demo in the review - or for a private demo after the review if you prefer. If there's still a problem, reopen the bug.

Just because a bug is closed in Github doesn't mean the issue is resolved. It means the bug fix is ready to be tested. If testing fails, either through Kate, or through the person who logged the bug, it gets reopened.

I'll also note that it's important to define the bug unambiguously in Github. i.e. Please use the format "Steps to Reproduce", "What Happened", "What I Expected to Happen". This allows us to understand the problem, plan the fix, and get on with fixing it so that it's ready for you to review at the end of the iteration.

This is how we've always worked - and I've documented this workflow a few times over the years. But as I say, it's been a while since I've explained it - so worth reiterating. Hope that makes sense.