hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@effectivemachines.com>
Subject Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)
Date Fri, 07 Oct 2016 06:04:18 GMT

> On Oct 6, 2016, at 1:39 PM, Akira Ajisaka <ajisakaa@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.  



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 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

View raw message