www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Continuous release review
Date Wed, 28 May 2014 16:01:29 GMT
+1

I made this same point in the discussion about what is required. Marvin
made the valid observation that he doesn't want to get bogged down in
policy changes while trying to clarify what the existing policy is. He
Didn't explicitly say it but I believe his intention is to separate the two
discussions - what is current policy and what should the policy be.

As I have stated elsewhere I have always believed the right thing is
to (and always asked podling to) review on an ongoing basis and only vote
+1 if you have conducted the agreed checks with legal review being the most
important.

I agree that checking the NOTICE files etc. is easier if you work with
diffs.

For me, voting +1 on a release is no more than an hour or two review. I
don't work full time on any one project so I know I will have missed some
commits along the way.

If I were working on code daily (and thus reviewing every commit) then that
time would drop to 15 minutes or so (around 1-2 hours for the PMC per
release).

We do not require every volunteer to review every commit. We should require
our volunteers to do proper reviews before voting +1 on a release. A proper
review should not include meaningless steps that can be automated.

Ross









On 28 May 2014 08:32, Jukka Zitting <jukka.zitting@gmail.com> wrote:

> 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
>
>

Mime
View raw message