commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] What's in a release
Date Tue, 30 Dec 2014 03:47:29 GMT
On Tue, 30 Dec 2014 03:22:32 +0000, sebb wrote:
> 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.

So it's either that or point (2).
[Both check the signature of the source code.]

>> (2)
>> git tag -v tag_name
>>
>
> No idea what that does.

Cf. previous paragraph.

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

I contend that there should be a big fat warning that those files 
should
not be modified lightly. And if they are, an issue _must_ be opened on
the bug-tracking system with the rationale for the new contents, or a
request that knwoledgeable people examine the situation.


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

How is this not true with source-only release?


Gilles


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


Mime
View raw message