commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Math] What's in a release
Date Tue, 30 Dec 2014 03:22:32 GMT
On 30 December 2014 at 03:05, Gilles <gilles@harfang.homelinux.org> wrote:
> On Tue, 30 Dec 2014 02:12:51 +0000, sebb wrote:
>>
>> On 30 December 2014 at 02:06, Gilles <gilles@harfang.homelinux.org> wrote:
>>>
>>> On Tue, 30 Dec 2014 01:48:20 +0000, sebb wrote:
>>>>
>>>>
>>>> On 30 December 2014 at 01:36, Bernd Eckenfels <ecki@zusammenkunft.net>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Am Tue, 30 Dec 2014 02:29:38 +0100
>>>>> schrieb Gilles <gilles@harfang.homelinux.org>:
>>>>>
>>>>>> On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote:
>>>>>> > That thread gets deep. :)
>>>>>> >
>>>>>> > I just wanted to comment on "releasing only
>>>>>> > source is faster because of less checks". I disagree with that,
most
>>>>>> > release delay/time is due to preparation work. Failed (binary)
>>>>>> > checks are typically for a reason which would also be present
in
>>>>>> > the source (especially the POM), so it does not really reduce
the
>>>>>> > number of rework.
>>>>>>
>>>>>> RM is a streamlined procedure: so, if you do (say) 10 steps rather
>>>>>> than 15, it will objectively take less time, and this is compounded
>>>>>> by the additional tests which should (ideally) be performed by the
>>>>>> reviewers. [Thus delaying the release.]
>>>>>
>>>>>
>>>>>
>>>>> The problem is not the small additional time for the last 5 steps but
>>>>> the large time for redoing all steps (on veto).
>>>>>
>>>>>
>>>>>> > (At least not in most cases, so two votes will actually make
us
>>>>>> > more work not less).
>>>>>>
>>>>>> The additional work exactly amounts to sending _one_ additional mail.
>>>>>
>>>>>
>>>>>
>>>>> The actual work is not the vote mail but the people doing the
>>>>> preparation and the review.
>>>>>
>>>>>>
>>>>>> Then, as I noted,
>>>>>>   * some releases will be done as before (same work)
>>>>>>   * some releases will be "source only" (less work)
>>>>>
>>>>>
>>>>>
>>>>> Not much, you still have to check if the source actually works and can
>>>>> be build, produces sane archives and so on.
>>>>>
>>>>>>   * some releases will be two-steps, possibly performed by two
>>>>>> different people (i.e. less work for each RM)
>>>>>
>>>>>
>>>>>
>>>>> And more work in sum, not only for the RMs but also the reviewers. (and
>>>>> the users which want to use the source release with maven like anybody
>>>>> there days)
>>>>>
>>>>> But I dont mind, if a project wants to do a source release only, thats
>>>>> fine with me, I just don't see the advantage.
>>>>
>>>>
>>>>
>>>> How many end users just want a source release anyway?
>>>>
>>>> I would expect most users to use the Maven jars, some will use the ASF
>>>> binaries, and a few will use the ASF source (AIUI Linux distros often
>>>> build from source).
>>>
>>>
>>>
>>> So, you answered your own question.
>>>
>>>>
>>>> Even if only the source is released, it's still necessary for the RM
>>>> and reviewers to build and test it.
>>>
>>>
>>>
>>> Never said otherwise.
>>> [Testing the sources is one git command and one maven command.
>>
>>
>> Not so.
>>
>> The source archive has to be downloaded, and its sigs and hashes checked.
>> It also has to be compared against the SCM tag, and the N&L files checked.
>
>
> (1)
> download == git clone tag_url
> --> No download of a signed archive.

But the signed archive is what is released.
The ASF releases open source which is distributed from the ASF mirror system.

So the signed archive is a fundamental part of the RC vote.

> (2)
> git tag -v tag_name
>

No idea what that does.

> (3)
> build == maven test site
>
> [Sorry: that was 3 commands.]
>
> Then maybe people in the know can examine the license issues, like you did.
> But I hardly count that every reviewer would do it. [Besides, it should
> have been done at the time the code was introduced. And, as I said in the
> other thread, we might seriously need to consider requesting an actual legal
> review if the matter is so sensitive: Submit to a lawyer when the contents
> is changed; no need to check when the contents is left untouched.]

The contents is potentially changed with every commit.
Yes, the N&L files should be kept up to date as each commit is added.

However, this is not always done, so it's important to check them
before release.

>>> Testing
>>> the binaries requires downloading each of them and check the signatures
>>> and/or checksums, each a separate command.]
>>
>>
>> The files can be downloaded as a single bunch, especially if one uses
>> the SVN dist/dev staging area.
>>
>> It's easy enough to write shell scripts to check all hashes and sigs
>> in a single directory.
>
>
> When I've asked at this thread's start (under subject "Git question"),
> the answer was that this does not strictly prove the link between source
> code and binaries.

> Hence the attempt to segregate what can be proved from what cannot.
> Back to square one.

Provable provenance is only part of what the vote should be about.

It's not possible in general to prove that a binary is derived from a source.
However, it is possible to document the source tag and release
artifacts in the vote such that a release artifact downloaded from the
ASF mirror system can be proved to have been voted on.

>
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message