Re: branching 1.14.x

>
> Nobody is trying to hold up anything. The common goal is to get 1.14
> shipped ASAP. At least I haven't seen anyone saying otherwise.

I know that no one is actively trying to hold up the release, on the contrary we are trying to get it wrapped. I am speaking to the extent these items are still blockers.

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?

> 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.

> 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 do have a more pressing project imminent that will be pulling him back. But if the release process starts soon, we would be more likely to allow him to finish so that we will be able to adopt the release once it is official.

Mark
Received on 2020-03-14 15:12:54 CET