On Tue, 30 Dec 2014 03:22:32 +0000, sebb wrote:
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.
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
