On 30 December 2014 at 03:05, Gilles <gil...@harfang.homelinux.org> wrote: > On Tue, 30 Dec 2014 02:12:51 +0000, sebb wrote: >> >> On 30 December 2014 at 02:06, Gilles <gil...@harfang.homelinux.org> wrote: >>> >>> On Tue, 30 Dec 2014 01:48:20 +0000, sebb wrote: >>>> >>>> >>>> On 30 December 2014 at 01:36, Bernd Eckenfels <e...@zusammenkunft.net> >>>> wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> Am Tue, 30 Dec 2014 02:29:38 +0100 >>>>> schrieb Gilles <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
