On 11/27/14, 6:54 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>No worries. The 4.14 release will have my name - or rather, my >computer account name - all over any stack traces that a user might >see. Better make sure there are as few as possible ;-) On this topic, I recently saw in this document [1], the following: "Must releases be built on hardware owned and controlled by the committer? Strictly speaking, releases must be verified on hardware owned and controlled by the committer. That means hardware the committer has physical possession and control of and exclusively full administrative/superuser access to. That's because only such hardware is qualified to hold a PGP private key, and the release should be verified on the machine the private key lives on or on a machine as trusted as that. 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". Note: This answer refers to the process used to produce a release artifact from a source control tag. It does not refer to testing that artifact for technical quality." I don’t think the SDK release is a simple tar ball of a tag because we exclude several files, especially the mustella tests, but it made me wonder what generated files are in the package, and how close we are to having the release artifact produced by Jenkins. Then the stack trace would be the same from release to release and not contain any of our names. The RM would have to download the artifacts from the CI server, validate via MD5, then do some verification before PGP signing and posting the artifacts on dist.a.o. Thoughts? -Alex [1] http://www.apache.org/dev/release.html#owned-controlled-hardware
