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 Tue, 03 Jun 2014 11:20:56 GMT
On 3 June 2014 11:52, Emmanuel Lécharny <elecharny@gmail.com> wrote:

> Le 03/06/2014 11:56, Stephen Connolly a écrit :
> > On 3 June 2014 08:55, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> >
> >>
> >>> This is why I believe that RC votes need to include the SCM tags (and
> >>> hashes/revisions) to clearly associate them with the release artifacts
> >>> and the votes. That way the history of the review is preserved in the
> >>> archives.
> >> +1
> >>
> > Well how does that work if there is an SCM migration?
> >
> > Suppose the ASF decided to move *all* projects from SVN to GIT?
> Hopefully, we don't destroy the previous repos when we do the migration.
> For instance, MINA has migrated to GIT 16 months ago, but you can still
> pull an old tag from SVN :
> http://svn.apache.org/viewvc/mina/
And that works because there are some projects who are quite happy with SVN
and we use one big subversion repo... but if there was a foundation
mandated migration then the SVN server could well cease to exist and your
tags would be very much like the dodo... (similarly *if* we had used the
one subversion repo per project model then your old repo could very well
have ceased to exist a couple of months after your migration completed.)

Do I think this scenario is likely?

Not really.

Do I think the scenario being unlikely means we can ignore it when drafting
a release *policy* for the ASF?

I think we cannot ignore it when drafting an ASF wide *policy*. Our policy
should be principle based. Mandating a specific way of meeting those
principles will force us to modify the policy as technology changes.

The simple fact that it is easier to verify provenance of files if they all
come from a precisely defined single revision in source control is
sufficient pressure to get projects verifying their source bundles against
source control. We should not mandate a specific technical means to an end.

Policy should reflect the desired end state and not enforce any specific
path to that end state

So to my mind:

* Policy should not dictate 72h minimum for votes. The board can issue
guidance to the effect that 72h minimum votes are presumed to have taken
into account the need for community inclusion. If a project wants to run
shorter votes they would then need to demonstrate how their shorter vote
period preserves the values we wish to retain such as community

* Policy should not dictate how PMC members decide to vote on a release. It
can state minimum criteria for a +1 vote. The board could issue guidance on
some pre-vetted processes. If a project wants to deviate from one of those
pre-vetted processes they would need to demonstrate how their alternative
process meets the policy requirements.

* etc

At least the above fits with how I see the core principles of the ASF,
namely let projects find their own solutions so that we can innovate.

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

View raw message