Hi Georg, On Fri, 2019-03-29 at 22:40 +0100, Georg Henzler wrote: > Sorry for the late feedback, in general I really like the idea to > improve the release process! > > The wiki states: > > > Many of these must be run by the release manager, since by > > definition > > releases are individual acts in the Apache Software Foundation. > > Isn't pushing a button in Jenkins when you are logged in an > individual > act? IMHO it would be best to just have one pipeline that you start > in > Jenkins on master, builds (it's easy with git to have Jenkins commit > as > a certain user) and stages the release (the private GPG key might be > problem, but I'm sure that can be solved somehow) and then sends the > [VOTE] email to the mailing list. The votes can be done by simple > input > elements (that send an email to the mailing list if +1 is voted, -1 > can > be another button that would also sent that email and abort the > pipeline).
I 100% agree that Jenkins is an ever higher level of automation and that it can streamline releases even more. The worflow you outlined would be great. (snip) > There are probably reasons why this is not allowed (e.g. the release > has > to be built on a computer of an individual), but personally (if it is > a > problem) I think it could even be worthwhile to question these > requirements with the ASF board. The current ASF release policy is at [1], and it states that Before casting +1 binding votes, individuals are REQUIRED to download all signed source code packages onto their own hardware, verify that they meet all requirements of ASF policy on releases as described below, validate all cryptographic signatures, compile as provided, and test the result on their own platform. So to implement your change we'd have to change the ASF release policy. I am aware of a related discussion from 2014 [2]. It's an interesting read, if you have the time. I am not saying it's not possible, but it's something that will not be easy to push through. I would suggest that we work on the CLI tooling, since it's highly reusable and it will be easy to make it work in a Jenkins environment as well, when/if the ASF release policy changes. Thanks, Robert [1]: http://www.apache.org/legal/release-policy.html#release-approval [2]: https://markmail.org/message/jyicon7nkmfnf322
