I am replying to this thread although I do not have skin in this particular game, and my receiving these is some glitch in my subscriptions. This is also a topic of interest for me.
The TL;DR: It is extremely valuable that build details be part of a release distribution. That means under release source control, not some Wiki. Whether there is something less detailed and useful as a guide on the Wiki is a different matter. It would then be good for a Wiki guide to provide information on how to rely on a particular release's build details, to be clarified asynchronously until there are changes to building that requires alignment of the guide. Rationale below the fold. -----Original Message----- From: Arrigo Marchiori <ard...@yahoo.it.INVALID> Sent: Monday, January 4, 2021 06:33 To: doc@openoffice.apache.org Subject: Re: [PROPOSAL] restructuring build documentation Hello Keith, On Sat, Jan 02, 2021 at 12:55:07PM -0500, Keith N. McKenna wrote: > On 1/2/2021 4:48 AM, Arrigo Marchiori wrote: [orcmid] [ ... ] > > The problem, IMHO, is exactly that they are generic. Because > > everything changes, like the linked tools (dmake, EPM), the build > > system itself may evolve, and even the source repositories have > > changed, it becomes more and more difficult to reproduce the _exact_ > > build of a past release. > > > > I expect such builds to become useful for hunting regression bugs. > > > Hi rigio; > I understand what you are saying,but those detailed instructions are > already in the per OS section and seem to me to be superfluous in the > basic setup section. Also there is already a procedure defined in > Section 9 on how to build older versions specifically aimed at > regression testing.We never release from trunk. It is only used by the > build bots for our nightly and weekly builds. We *only* Release from > the current branch. > > I hope this makes my position more understandable. Even though I do > not currently build the software, I could setup a build environment > and build without the per branch instructions [orcmid] [ ... ] As an example: the release builds are IMHO the most interesting ones, and I am going to rerrange the chapters into the step-by-step building guide to list them before other platforms and experimental setups. [orcmid] [ ... ] [orcmid] RATIONALE: * Reproducibility is Important. And an easy to way replicate a specific build is important, although limited by tools that do not provide bit-for-bit reproducibility of operation. This must be easy to do once the dependencies can be satisfied. * Customization is important. That is a matter of indicating what should change to provide a different (possibly "branded") build that is not to be confused with the one provided by the main development team. This says something about how builds, and their origins, are made visible to end-users. Code signing of distributions figures in here. * Auditability is Important. Dependencies on tools and components can be very important, especially when verifying whether or not a security vulnerability or plain defect is involved. In the past there were version-control systems that addressed this, although they seem to have fallen by the wayside with the rise of open-source tooling. * Training and learning, onboarding of new developers, is also a factor that is supported by such documentation, including the release-level details and also a good Guide. [orcmid] LIMITATIONS: * Architecture is Required. Addressing these matter seems to require that such concerns be addressed from the very beginning. The build, test, customize, and deployment structures need to be designed for this from the beginning. Retrofitting of a large code base with an incredible variety of options seems doomed because of * Developer Discipline. This is probably at least as difficult as strong attention to threat models and countering discovery of vulnerabilities. In a self-selected open-source undertaking where scratching an itch is far different than a commitment to non-developer users, heroic efforts tend to have little traction and do not impact the development culture much. That includes quality on-boarding information for developers. * Continuous Integration may be problematic. Also, not providing updates and requiring complete replacements is easier but a way to ship and install patches would make it easier for end-users to stay current and safe. This might or might not make it easier for platform-specific forking and how that is documented somehow, at least from a single team's platform targets. - end of brain dump - Dennis E. Hamilton --------------------------------------------------------------------- To unsubscribe, e-mail: doc-unsubscr...@openoffice.apache.org For additional commands, e-mail: doc-h...@openoffice.apache.org
