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.
Received on 2020-03-14 15:26:58 CET