I'm sorry I was wrong. Thanks Allen for the detailed information.
-Akira
On 10/7/16 15:04, Allen Wittenauer wrote:
On Oct 6, 2016, at 1:39 PM, Akira Ajisaka <ajisa...@oss.nttdata.co.jp> wrote:
It wasn't 'renamed' to jenkins, prior releases were actually built by and on
the Jenkins infrastructure. Which was a very very bad idea: it's insecure and
pretty much against ASF policy.
Sorry for the confusion. I should not have used the word 'rename'.
What I meant is that "would you change the name to 'jenkins' by using the Jenkins
infra?"
To re-iterate, building on the jenkins servers is a violation of ASF release
policy and the PMC pretty much has a duty to vote -1 on any such release.
http://www.apache.org/dev/release.html#owned-controlled-hardware
--snip--
Must releases be built on hardware owned and controlled by the committer?
....
Practically speaking, when a release consists of anything beyond an archive (e.g.,
tarball or zip file) of a source control tag, the only practical way to validate that
archive is to build it locally; manually inspecting generated files (especially binary
files) is not feasible. So, basically, "Yes".
--snip--
The ASF build servers are multi-user and run many many many untested code
bases. It would be extremely easy to inject class files into any running
compile (Docker-ized or otherwise). This means that any build that comes from
those servers should be considered untrusted, especially from a release
perspective.
For 3.x releases, I rewrote create-release and added the --asfrelease option to
specifically provide a way for us to get consistent release candidates
regardless of who builds it. It should also speed up the release process since
it also does a lot of the previously manually steps, such as signing.
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
