www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Continuous release review
Date Mon, 02 Jun 2014 23:58:55 GMT
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.

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

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'.
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

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

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

View raw message