flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Stack trace names (was Re: [TLF] merge 'tables' into 'develop')
Date Thu, 27 Nov 2014 15:49:52 GMT

On 11/27/14, 6:54 AM, "Erik de Bruin" <erik@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.


[1] http://www.apache.org/dev/release.html#owned-controlled-hardware

View raw message