On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote: > I do not fully understand where we are at on shelving. I believe ideas were > proposed to make it a compile time feature that would be off by default or > something. I am fine with that. You raised it as being a blocker still so I > am going off what you wrote. If it was merged and not a blocker then were you > just looking for Julian or Daniel or someone else to officially say it is no > longer a blocker?
The 'decouple-shelving-cli' branch was not merged to trunk yet when I started this thread. So progress has been made. And yes, knowing Daniel's and Julian's assessment of the current state of things would be good. > > At a minimum the test failures on Windows would need to be fixed. > > > > The easiest path forward we would be to revert the entire change, > > and then ship 1.14 with a known problem. I still hope that we'll > > manage to get enough support somehow to actually fix the problem, > > though I don't know how. I am not going to fix Window-specific bugs > > myself because I lack a dev environment and don't have any experience > > with developing on this platform. > > My only advice would be to reach a point where we accept no one is going to > step up and fix this on Windows and then decide accordingly. If we can fix it > for Linux without making Windows any worse, then I would think we should do > that. I do not see why we cannot leave the tests failing on Windows. Again, > as long as we have not made Windows any worse, if some future APR update were > to make the tests pass that sounds like a good thing. > > As long as we know why the tests fail, that seems acceptable to me. If we > cannot fix Linux without making Windows worse than it is with 1.13 then that > is different and more complicated for sure. I cannot really judge the impact on Windows. Apparently, the change breaks things on Windows because APR's code doesn't work properly there. Let's wait a bit and see if developers involved will speak up. > > Sounds like we need to coordinate timing? I am handling the RM side > > of this, and it would help if I knew at which point in time Mike would > > no longer be available to help out. Having more people around while we > > are preparing this release would be great. Fortunately, I am flexible > > and won't have a problem with moving the date forwards or backwards if > > that helps. > > Sooner is better. I would guess the main area Mike would be able to help > would be in confirming or improving the Python 3 bindings. As he is updating > ViewVC and other internal stuff to work with the Py3 bindings he might find > bugs that he can address. We also need people to test and sign the releases across OS platforms. At a minimum there will be 1.14.0-rc1 and 1.14.0 releases to test and sign. The more people we have around for this, the faster the release can happen.