Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNaqACY-JXUesx-V0PnsiCCkfVo_xKdEMO-N5Nt7Y_JTFQ@mail.gmail.com>
References: 
 <CAOFYJNaqACY-JXUesx-V0PnsiCCkfVo_xKdEMO-N5Nt7Y_JTFQ@mail.gmail.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Fri, 30 May 2014 10:32:03 -0400
Message-ID: 
 <CAOFYJNbBK4rdBFrfz5fG-fTg=2US_OJ5g0iGJz4ozknJa-QxPA@mail.gmail.com>
Subject: Re: Continuous release review
To: Legal Discuss <legal-discuss@apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Let me try to refocus this discussion.

First of all, I'm not trying to argue that projects should be free to
ignore or replace parts of existing policy, they shouldn't. Instead
I'm looking for ways to *change* the policy to enable new ways to make
releases.

Second, I think we all agree that underlying goals (legal, social,
technical, etc.) of the current policy are sound and shouldn't be
abandoned. I only question the specific mechanisms we currently use to
meet those goals. If there are alternative ways of meeting the same
goals, shouldn't we consider adjusting the policy to allow such
mechanisms if projects would like to use them?

Finally, I believe there's an opening for us to allow radically new
ways of cutting releases without abandoning any of those goals. I'll
explain:

On Wed, May 28, 2014 at 11:32 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

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.

How would such imaginary processes produce releases that are any worse
than those governed by current policy? Are there any legal, social or
other aspects that such processes would fail to address as well as we
now do?

BR,

Jukka Zitting

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