On Wed, Feb 9, 2022 at 7:51 AM Stefan Sperling <s...@elego.de> wrote: > > On Wed, Feb 09, 2022 at 07:23:55AM -0500, Mark Phippard wrote: > > 2. We need a RM to produce the release. Only a handful of people have > > done this and I am not one of them so I cannot comment on how hard > > this is. It does feel like this entire process could be completely > > automated though. As in, someone creates a tag or pushes a button in > > Jenkins and the rest just happens. > > I think our main problem is that not enough people have gone through > this process, and it may seem more intimidating than it should be. > It is not actually a lot of work. The process is well documented and > already automated for the most part. The RM mostly runs release.py in > a series of steps, by following our docs. > > Anyone on the PMC can do this. If you've made a commit to the project or > to the website, have reviewed fixes in STATUS and have communicated with > people in this project via mailing list and IRC, then you already know > everything you need to know to become the RM! > > The main burden is to guess a future date for the release and then keep > track of our progress until the release is done. The RM should ensure we > don't miss the prospected date by a large margin. This requires constant > attention to the project for a while. If you cannot afford to spend roughly > half an hour per day on it for a week or two, you don't have enough time. > > During this time, the RM mostly keeps track of things in STATUS and keeps > poking people to help with reviewing, testing, and signing. > The actual releasing is done by doing a few SVN commits, again via release.py. > And the RM writes release announcements, which is also automated by > release.py. > > There is a one-time effort to ensure that sending mail via your apache.org > account works; the ASF has an SMTP relay you can use for this purpose and > this needs to be configured in your mail client. > > And you need a Linux system, which as we know is a show-stopper for some > of our developers. Anyone who wants to RM on Windows would need to port > the release.py process over first, which is probably a good chunk of work. > I would recommend setting up a Linux VM instead.
Thanks Stefan, this is more or less what I thought. I do wonder if we could somewhat easily switch to doing the entire process via Docker? This would make it possible to do it from MacOS or Windows and it would probably have some benefits for Linux users as well? Anyway, my feeling has been that one of the blockers to being RM is motivation. My feeling has been that it is a fair amount of work that might not go anywhere because we do not have enough interest in reviewing and signing the release. So why put in the effort to do this when the votes are not going to happen? We have also always had what I thought was a peculiar policy that the RM's votes did not "count". So often the most motivated member of our community steps forward to do the RM work, and now we have lost the one sure thing vote we would have had for the release. I guess if we could automate away the need for a RM or change the role to be purely the steps that need to occur after the voting happens, then that could solve some of these problems. In theory ... we could do a release as long as we have 2 motivated people right? Or does it require 3? One to nominate a fix and 2 to vote? If the RM process were automated, we get the votes we need and then just 1 of those people that voted need to do some final step to publish the release? I think this sort of math is what we need to focus on. What is the smallest number of people we must have to make a release and then how can we make that work. If we get more votes, great, but there is a minimum bar we need to reach that currently we cannot do very easily. Mark
