www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Continuous release review
Date Mon, 02 Jun 2014 09:02:16 GMT
+1000

On Monday, 2 June 2014, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:

> Hi,
>
> 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
> concern.
>
> -Bertrand
>
>
> On Fri, May 30, 2014 at 4:32 PM, Jukka Zitting <jukka.zitting@gmail.com
> <javascript:;>> 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
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>

-- 
Sent from my phone

Mime
View raw message