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 09:56:56 GMT
On 3 June 2014 08:55, Emmanuel Lécharny <elecharny@gmail.com> wrote:

> Le 03/06/2014 01:58, sebb a écrit :
> > On 2 June 2014 21:51, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> >> Le 02/06/2014 22:37, Jukka Zitting a écrit :
> >>> Hi,
> >>>
> >>> On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <
> elecharny@gmail.com> wrote:
> >>>> Le 02/06/2014 17:18, Jukka Zitting a écrit :
> >>>>> For example, if you review and vote on releasing a specific revision
> >>>>> in the SCM, what's the added benefit of repeating the process on
the
> >>>>> source bundle produced from that revision?
> >>>> AFAIU, there are two different things. As the bundle is produced by
a
> >>>> automated tool (can be the maven packaging phase), the result can be
> >>>> *very* different from what we get when pulling the revision from the
> >>>> repository.
> >>> I personally don't see any compelling reasons why a source release
> >>> should be anything more than a packaged export of a tag, and some very
> >>> good reasons reasons (like the ability to verify that the sources
> >>> actually came from the scm) for why it should be just that. But I
> >>> recognize that others disagree.
> >> I don't disagree. The thing is that most of the Java projects are
> >> depending on Maven to generate the jar, which should be the same than
> >> what you get when doing a svn co/git clone followed by a tar cvf. Except
> >> that if you have made a mistake when configuring maven, you may and with
> >> a difference. Been there...
> > It's not only Maven config errors that can cause issues.
> > Maven creates the source archive from a local copy of the SCM, not
> > directly from the SCM tag.
> > This copy can be altered by the process of building the release -
> > additional files can be added, or files can be deleted.
> >
> > Note that Maven is not alone in this; any packaging procedure that
> > uses a local workspace can be subject to the same issues, especially
> > if the same workspace is used to build and test the release candidate.
> Absolutely.
> >
> >> Checking both should mitigate this risk.
> >>> Anyway, this doesn't affect my main premise. As long as there is a
> >>> deterministic process that produces the source bundle from a given scm
> >>> revision (or revisions) and the steps of verifying the correctness and
> >>> quality of that bundle can be automated (given the assumption that the
> >>> correctness and quality of original source has already been reviewed),
> >>> from the "policy invariant" perspective there should be little
> >>> difference in whether the manual review is done on the input or the
> >>> output of the process.
> >> +1
> >>
> > There needs to be a check that the source release contents is entirely
> > derived from the SCM input.
> > If these are the same, then I agree it does not matter which is
> > manually reviewed.
> Yes. We would need a tool to do that...
> >
> > There is another aspect of the using SCM tags or equivalent: I believe
> > that it should be possible to recreate the source release at any later
> > stage. One way to do this is to ensure that the source release is only
> > created from an immutable SCM 'tag'.
> Yes.
> > 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?

All those peg revision tags in the email record are now useless...

Suppose then a while later the ASF decides to move all projects from GIT to
FooMachuWhizbang as it has a better data model for N-way merges or some
such thing...

Now not only are the SVN peg revisions useless, so are the git tag hashes.

We vote on the source bundles, so I agree that the source bundle hashes
should be required to be in the vote email record (I don't see the need to
mandate it in the VOTE, it could be that a PMC wants each PMC member to
specify the hash of what they are voting on, in which case the RE: VOTE
emails would have "+1 Hash")

But peg revisions or commit hashes are not guaranteed to have permanence...
so if you are arguing that they should be present FTR then we would need to
put some sort of persistence mechanism in place so that in the event of us
migrating to a different SCM then that information remains usable (this is
the same reason why we have s.apache.org as an URL shortener to my mind)

Just to clarify my point: It should not be ASF policy to *require* commit
hashes or tag peg revisions in vote emails... they are very useful to have,
but they should not be required by policy

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

Mime
View raw message