www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Mattmann <mattm...@apache.org>
Subject Re: Continuous release review
Date Wed, 28 May 2014 15:46:38 GMT
So, I got about halfway through this thread and I was about to
stop reading and type a reply to the effect of:

"why wait for the release to make sure b) is done?"

And then..you beat me to it.

+1 for being ready, during each and every commit, to release.
That's what we have version control for to go back and look
through and verify this type of thing, and this is one of
the purposes of a PMC. Use automated tooling as much and
wherever possible to take care of everything else and then
amortize the grand cost of b) (and I agree it's grand) over
time by doing it continuously, and with those human beings
around you. 

My 2c.


-----Original Message-----
From: Jukka Zitting <jukka.zitting@gmail.com>
Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Date: Wednesday, May 28, 2014 8:32 AM
To: Legal Discuss <legal-discuss@apache.org>
Subject: Continuous release review

>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
>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
>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
>[3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh
>Jukka Zitting
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org

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

View raw message