I'm sorry I was wrong. Thanks Allen for the detailed information.


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 

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.



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


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 

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: mapreduce-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org

Reply via email to