Thanks for the feedback, Krisztián! Lots of good insights on the current release process.
I can see that you were already taking actions towards the process I was describing. I will write some notes to update the current process to reflect that on the Release documentation [1] and will share. I still think there is some value in standardising the "feature freeze" on new release candidates once a first release candidate has been created and only add required fixes for the follow up RCs. What I would like to avoid with that is rushing big new features at the end that might be added between release candidates. >> PROBLEM 1: Rush period before the release: > > The only proposal I can think of around this is that I will try and share the release schedule earlier. I sent an email [2] with a ~1.5/~2 weeks notice, maybe if all of us start being more aware that a release is coming with a little more time (1 month) we can plan better. > >> PROBLEM 3: Lack of interest in nightly builds despite their importance > I have added more visibility to them by publishing them on Zulip [3] and I am planning to work towards improving them further. [1] https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide [2] https://lists.apache.org/thread/zk8hhynvy0bqvqpxk0868n5g0nmzbzbn [3] https://ursalabs.zulipchat.com/#narrow/stream/181017-nightlies/topic/report
