On 08/19/2016 10:37 AM, Dennis E. Hamilton wrote: > > >> -----Original Message----- >> From: Kay Schenk [mailto:kay.sch...@gmail.com] >> Sent: Friday, August 19, 2016 09:09 >> To: dev@openoffice.apache.org >> Subject: Re: Ready to setup release build machines? >> >> >> >> On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote: >>> I thought that the basic requirement is that the release manager(s) do >> any builds on a machine under their [exclusive] individual control. >> That also means satisfying baseline requirements for release builds >> though. That pretty much requires use of a VM if the main development >> system of a release manager is aligned with different tools and >> dependencies. >> >> I don't find any requirement like this vis a vis building by the release >> manager per se. The release is voted on by the community. So, in a >> sense, building/testing is the responsibility of all who vote on a >> release. >> >> See: www.apache.org/dev/release-publishing.html > [orcmid] > > That page is rather obsolete. For example, we have two branches on > dist.apache.org, one of which is for dev (and where we put release > candidates) and the other is release where we move any approved candidates. > The dist ... release contents are automatically mirrored to > archive.apache.org which seems to be the proper place to refer to these > (although there is mirroring to consider, but not for 4.1.2-patch1). > > The release page does not address binaries. I saw the business about where > official binaries are to be built somewhere and must find it.
The Release Publishing page does address binaries: http://www.apache.org/dev/release-publishing.html It also discusses the importance of "distribution" of ASF releases on ASF servers but doesn't say anything about how that distribution, either source or binaries, is created with respect equipment ownership, etc. Publishing Releases is linked from the Release Policy page: http://www.apache.org/dev/release > > Since we put binaries through a form of this process (usually concurrently) > there does need to be some sort of provenance on those binaries. > > >> >>> >>> I am not so certain about putting up shared release-build VMs on non- >> ASF infrastructure though. >> >> Our "official", "required" release artifact is the source code for a >> release. >> >>> >>> One advantage to using ASF infrastructure is to bring code signing >> into the fold. That seems rather important down the road. >> >> We have been signing ALL release artifacts -- including all the binaries >> -- since AOO 3.4. So code signing of everything we release is already >> part of this process. > [orcmid] > > The use of PGP signatures on our release artifacts is a different matter than > code signing that is recognized by the operating system and is part of the > installer, not a detached signature that users must check manually. The > signatures I meant are *embedded* in the artifacts, including .msi, .dll, and > .exe files. > > I was thinking of this form of signed installs. That is a big deal for > Windows, where the OS will check them automatically, and they are also > reported in the Properties for the signed artifact. It also applies to all > of the DLLs and such that are loaded with the install. I believe that Andrea > has the private key that was issued for that but we have not managed to use > it to sign the code. This is usually done as part of building distributable > binaries. > > That private key is precious and is not to be shared. Ideally, it would > belong to root@ but I don't think we have a process for that. > > >> >> We require a production environment accessible by the release manager >> and helpers because producing distribution binaries in another location >> (seperate developer machine), signing and then uploading ALL the >> binaries to SourceForce by individuals is a horrendous undertaking. >> Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure >> he can attest to this. If we can set up a production environment under >> ASF infrastructure, of course this would be ideal. But, I see no reason >> why this environment couldn't have shell access by AOO developers who >> are likely to do code signing. >> >> > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Kay Schenk Apache OpenOffice ---------------------------------------- "Things work out best for those who make the best of the way things work out." -- John Wooden --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
