Den tors 13 jan. 2022 kl 11:36 skrev Johan Corveleyn <jcor...@gmail.com>:
> 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). > Full disclosure: I'm on Windows too. If and when I'm RMing, I will probably do all this work in a WSL-based virtual machine running on top Win11. I don't suppose that will be an issue (since WSL is basically a wrapper around Hyper-V, even running a proper Linux kernel) but I thought I should mention. 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've got a long outstanding promise to Alexandr to check a patch for the build script on Windows, and I will renew my effort to get a working build environment to be able to help signing on Windows. > 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 > > Kind regards, Daniel
