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 Tue, 03 Jun 2014 07:55:47 GMT
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




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


Mime
View raw message