Fwd: Continuous release review

["seba.wagner@gmail.com" <se...@gmail.com>]

Maybe interesting
---------- Forwarded message ----------
From: "Jukka Zitting" <ju...@gmail.com>
Date: 29 May 2014 01:32
Subject: Continuous release review
To: "Legal Discuss" <le...@apache.org>
Cc:

Hi,

It looks like my recent tweet [1] is making more waves than I
expected, so I guess I should expand on it here instead of getting
caught up on too many private debates. I hope to avoid conflicting too
much with Marvin and others in the effort to clarify existing release
policy; as he pointed out, this should be considered a separate
discussion.

The reason behind my tweet is a worry about the overall direction of
the discussion that seems to end up treating a release as a
bureaucratic act guarded by high ceremony. For example, breaking down
the review requirements from the recent draft [2], we have:

    Before casting +1 binding votes, individuals are REQUIRED to
    a) download all signed source code packages onto their own hardware,
    b) verify that they meet all requirements of ASF policy on
       releases as described below,
    c) validate all cryptographic signatures,
    d) compile as provided, and
    e) test the result on their own platform.

Steps a, c, d and e are all things that would arguably be better and
more reliably done by a CI server. In Jackrabbit we use a release
checker script for these steps (see [3]), and our CI builds already do
steps a, d and e for each individual commit.

Step b is a complex task that, if done properly, would take hours or
days to complete if you don't take previous reviews into account. In
practice it makes more sense to consider only what changed since the
last reviewed release and see whether the policy implications (LICENSE
updates, etc.) of any of the changes have been implemented. Even
better if such policy implications are addressed directly in the same
commit that introduces the relevant chance (we try to do this in
Jackrabbit).

In summary all of the steps (apart from c which in any case is easy to
automate) can and in many ways should be done already for each commit
instead of just during the release vote.

Thus I question the focus we're putting on the release as the point
where all this review is supposed happens. Instead I'd rather see this
becoming more of an ongoing task to be done at the level of each
commit or push, with the release review more just a final confirmation
that such a process has been followed. Something like that would help
relax the somewhat awkward rules we now have on restricting access to
unreleased stuff. If everything we had was always ready for release,
such rules wouldn't be needed and it would be much easier for projects
to release early and often.

This idea has been raised in different forms by others on a few
occasions already earlier, but with all the focus on the existing
release policy and the associated ceremony it seems like many are
missing the point of the argument. I hope this post helps frame the
idea a bit better.

[1] https://twitter.com/jukkaz/status/471304315412705280
[2]
https://github.com/rectang/asfrelease/blob/6ad23f6909ccbe71080e4b6c36c5552f863e829f/release.md
[3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org