On Tue, Jan 11, 2022 at 5:12 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > Den tis 11 jan. 2022 15:34Julian Foad <julianf...@apache.org> skrev: >> >> Johan Corveleyn wrote: >> > Thanks for starting to get this ball rolling, Daniel. >> >> Seconded. >> >> >> I have been pondering the question of which release(s) and in what >> >> order. I think 1.14.2 and 1.10.8 first, then 1.15.x later. >> >> Sounds good. >> >> As mentioned in another thread just now, I'm now able to work on issue #525 >> (pristines-on-demand) so we might consider if it's going to fit into the >> 1.15.0 time scale. I'm just starting today so if we could consider this in a >> few days once we've got some summary/plan/idea of how it might progress that >> would be good. > > I see several votes for releasing 1.15 "later". Nathan (I think) at one point > suggested that 1.15 might be "the performance release" with the "streaming > checkouts" from last summer so I think it makes sense to also bring this to > completion. So: Later = +1 for me. > >> >> As for release management, I can volunteer at least a little support to a >> release manager, based on what I learnt and can remember from doing it a few >> times in the last few years. > > > Agree it is good if more hands know the skills. For me January and February > are quite busy and I hope we can find someone to do 1.10.8 and 1.14.2 during > that timeframe. I might be able to free some time for a 1.15 release in > March/April.
In principle I could volunteer for RM, but there are at least 3 things holding me back: 1. Lack of time, but I guess that goes for a lot of us around here. 2. I'm on Windows, and AFAIU our current release process requires *nix (at least our docs refer to a lot of unix-specific build tools that are needed [1]). I could in theory do all those things on another machine, for instance our own svn-qavm (though I guess I'd need enough permissions on such a machine to install tools etc), or set up a temporary (virtual?) machine on my own, but I'm not sure I want to go through all the hassle (given my previous point). And given the previous point, I certainly don't have the time to investigate and update our release process to make it work on Windows (though that would definitely be useful). 3. I'm on Windows, and am usually the only one who provides a binding release-vote for the Windows platform, and traditionally we don't count the RM's own vote among the three required (and at least one per major platform [2]). I know that's not really required (the RM's vote is just as valid as any other from a PMC member), but we seem to have been able to do it this way until now (I think). I suppose number 3 is not a very big issue, so let's say I have 2.5 reasons :-). Number 2 (unix required) is the big one. [1] https://subversion.apache.org/docs/community-guide/releasing.html#before-release [2] https://subversion.apache.org/docs/community-guide/releasing.html#releasing-votes -- Johan
