Hi Robert,
thanks for clarifying!
... It's an interesting read, if you have the time.
[2] is a 94 messages thread, impressive.
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 if we really want to get fancy, then we make Jenkins provide a docker
image (either for download or push it to a docker registry). That docker
image could then contain both the staged release artifacts and a sling
starter instance. "docker run" could
* check the artifacts (so basically run check_staged_release.sh, but
from within the docker image that contains all artifacts and all public
keys of the committers, you remember the PR to improve that behaviour
that is still open :) )
* compile the sources
* run a Sling instance with the released artifacts - this would be great
to have quickly an instance ready for local testing (I think making it
really easy for everyone to not only check the signatures but also the
functionality would definitely bring value)
Using this approach IMHO we would fulfil [1].
A cli tool would not really be needed for this, I'd rather put all this
code native to Jenkins. The big benefit of the "docker image+Jenkins"
approach would be that the release finish actions are completely done
automatically (e.g. performed automatically on Sunday without manual
intervention :))
WDYT?
-Georg
On 2019-04-01 15:13, Robert Munteanu wrote:
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].
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
