Skip to content

Conversation

@marqh
Copy link
Member

@marqh marqh commented Aug 31, 2016

No description provided.

@QuLogic
Copy link
Member

QuLogic commented Aug 31, 2016

No way it's that easy 😛

@marqh
Copy link
Member Author

marqh commented Sep 1, 2016

indeed :/

@djkirkham
Copy link
Contributor

Going to start looking at the TypeError: data type "i16" not understood errors.

@djkirkham
Copy link
Contributor

PR: #2127

@djkirkham
Copy link
Contributor

Now looking at TypeError: Cannot cast ufunc add output from dtype('float64') to dtype('int64') with casting rule 'same_kind'

@djkirkham
Copy link
Contributor

PR: #2128

@djkirkham
Copy link
Contributor

Now working on datetime rounding errors.

@marqh
Copy link
Member Author

marqh commented Sep 7, 2016

I am working on testCDL failures linked to ncdump output

@marqh
Copy link
Member Author

marqh commented Sep 7, 2016

I am working on testCDL failures linked to ncdump output

#2133

@djkirkham
Copy link
Contributor

PR for datetime rounding errors: #2134

@djkirkham
Copy link
Contributor

Now looking into PANDAS errors

@djkirkham
Copy link
Contributor

pandas PR: #2136

@marqh
Copy link
Member Author

marqh commented Sep 8, 2016

#2135 is a step into matplotlib check_graphic tests space
it is not a solution by a long way

@marqh
Copy link
Member Author

marqh commented Sep 12, 2016

#2139 has more check_graphic updates

@marqh
Copy link
Member Author

marqh commented Sep 14, 2016

#2141 has a whole swathe of check_graphic removals, whilst attempting to maintain test coverage

@djkirkham
Copy link
Contributor

another PR related to pandas tests: #2142

@marqh
Copy link
Member Author

marqh commented Sep 27, 2016

@bjlittle tests rerunning

@DPeterK
Copy link
Member

DPeterK commented Sep 28, 2016

Note that the datetime rounding errors fix (#2134) was moved to a cf_units change (SciTools/cf-units#66).

@DPeterK
Copy link
Member

DPeterK commented Sep 28, 2016

I have proposed a different approach for dealing with the failing graphics tests, which is captured in #2150.

@DPeterK
Copy link
Member

DPeterK commented Sep 28, 2016

@marqh the only test that's now failing was due to changes in cf_units. I just merged the fix for this in #2144, so I've restarted the tests once more and then they should pass.

@marqh marqh changed the base branch from v1.10.x to master October 3, 2016 08:40
@marqh
Copy link
Member Author

marqh commented Oct 3, 2016

Outstanding test failures, as of
f53fc6f

@bjlittle

@QuLogic
Copy link
Member

QuLogic commented Oct 7, 2016

So how imminent is 1.11? I ask because I basically cannot build 1.10 with tests because of all of the above compatibility issues with the latest packages. I'd vote for there to be a release as soon as these compatibility issues are corrected, without regard to any other outstanding features, whether that be 1.10.1 or 1.11.0.

@marqh marqh added this to the 1.11 milestone Oct 7, 2016
@pelson
Copy link
Member

pelson commented Oct 7, 2016

So how imminent is 1.11? I ask because I basically cannot build 1.10 with tests because of all of the above compatibility issues with the latest packages.

Same story here. A release needs to happen, ideally in the next 10 days, that can be said to support newer dependency versions (i.e. can be tested with them). Looking at the changes that are coming out of the woodwork, it is a healthier thing to call it v1.11 than v1.10.1 IMO (there are some behaviour changes needed). We are fortunate in that there is no social/political drive to release a v1.10.1 vs v1.11, so let's call a duck a duck and aim for v1.11.0.

You are right to be concerned (in another comment) by the time it took to get v1.10 out. My sole aspiration for v1.11 is to be able to claim "support" for unpinned dependency versions, and anything else represents a distraction from this extremely important aim. I have updated the v1.11 milestone with some dates, as well as a clear goal - as a group, we need to learn the lesson of release little and often and it is my hope that we are turning the corner in that direction.

Ping @SciTools/iris-devs - please be aware once this PR is merged, we will be extremely close to releasing Iris v1.11.

@ajdawson
Copy link
Member

ajdawson commented Oct 7, 2016

please be aware once this PR is merged, we will be extremely close to releasing Iris v1.11

Sounds like a good plan. There are/will be some commits on v1.10.x that need to be merged into master before cutting v1.11.x branch, just a heads up so we can avoid a headache.

@marqh
Copy link
Member Author

marqh commented Oct 10, 2016

Sounds like a good plan. There are/will be some commits on v1.10.x that need to be merged into master before cutting v1.11.x branch, just a heads up so we can avoid a headache.

#2177

@marqh
Copy link
Member Author

marqh commented Oct 12, 2016

QuLogic commented on 31 Aug

No way it's that easy 😛

as easy as six weeks hard labour

/me points at a travis green tick \o/

@bjlittle
Copy link
Member

@marqh Really, really? 😲

@corinnebosley
Copy link
Member

@bjlittle Don't be asking that question Bill, especially not twice. If the big green tick says it's OK, then it must be OK.

@bjlittle
Copy link
Member

@marqh and @corinnebosley whoop! 🎉 😄

@bjlittle bjlittle merged commit 5645de0 into SciTools:master Oct 13, 2016
@marqh marqh mentioned this pull request Oct 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants