www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Continuous release review
Date Fri, 30 May 2014 15:45:53 GMT
Le 30/05/2014 16:32, Jukka Zitting a écrit :
> 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.

+1
>
> 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?

+1
>
> 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.

+1
>
> 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?
I let other respond to that question. My answer is : it's likely that
another process (like our current one) will (is) produce (ing) worse
release.


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


Mime
View raw message