www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: Continuous release review
Date Mon, 02 Jun 2014 08:34:22 GMT

Jukka's two examples of how projects can manage releases, quoted
below, are excellent examples of why it doesn't make sense to force
the same *process* on all projects.

What's needed is to agree on the *invariants* for releasing software
at the ASF, something like:

0) The ASF releases source code
1) Each line of code is traceable, we know who committed it when
2) All code (and additional files like NOTICE etc.) is reviewed to
comply with the ASF's legal requirements
3) Release packages are signed in a way that allows users to check
their integrity
4) The PMC votes to make the release an act of the foundation
5) All PMC members are given a fair chance to take part in release votes

I might be missing a few things but those are the main points -
agreeing on such a list and making it a hard requirement is what we
need, the details of how each PMC implements it are not a foundation's


On Fri, May 30, 2014 at 4:32 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> ...For the sake of the argument, assume that a project adopts a strict
> RTC policy where each commit is reviewed and voted on not just for
> it's technical content but also as if a new release was cut from that
> point. An audit trail of the review results and all votes cast are
> stored in each commit message. The project would then, after reaching
> consensus that it's time to release, just tag the release and have a
> build server take care of automatically verifying the audit trail and
> then packaging, signing, building, testing and deploying the release.
> There would be no manual review of the release package itself and no
> need for the "72 hours" or "3 +1s" rules, as all those things would
> already have been taken care of earlier in the process.
> Or as a simpler alternative, assume a project that identifies a
> specific revision as a release candidate and runs a normal release
> review and vote against that revision instead of a pre-built release
> candidate. If the vote passes, the revision would be tagged and a
> build server would again take care of verifying the vote results and
> then packaging, signing, building, testing and deploying the release.
> Such a process could even produce "official" binary packages, as there
> would be no need to double-guess what actually went into building
> those packages.

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

View raw message