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