You are viewing a plain text version of this content. The canonical link for it is here.
Posted to doc@openoffice.apache.org by Arrigo Marchiori <ar...@yahoo.it.INVALID> on 2020/12/17 13:05:58 UTC
[PROPOSAL] restructuring build documentation
Dear All,
I am cross-posting to dev@ and doc@ because... I am not sure which one
fits best. Please excuse me if this is wrong, and only reply on the
correct list.
I personally find building OpenOffice a bit too difficult today, in
terms of _understanding_ what needs to be done. We have build
instructions on the Wiki, build scripts on a SVN repository, but IMHO
a little ``integration'' among these pieces would help every newcomers
(like me) to get a big picture, complete the first successful build
and start helping with the code.
Here are my ideas. I don't know if these topics were already discussed
before my subscription to this list; if so, kindly send me a pointer
so I can avoid you repeating ideas that are already consolidated.
I would like to propose the following layout on the Wiki:
- build instructions for trunk (currently
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
that needs some updating anyway, such as removing SVN)
- specialized build instructions for trunk on individual
O.S. (Linux, Windows, BSD etc)
- build instructions for the latest release (4.1.8)
- specialized build instructions for the latest release on
individual O.S.
The distinction between trunk and release is IMHO necessary. For
example, Jim is doing a very good work of updating core parts of the
build system, and this changes for one the initial call to the
configure script. In addition, deprecated information such as the SVN
repository could be deleted from the trunk build instructions, and
only remain in the once-applicable instructions.
The current build scripts on SVN should be explicitly indicated in the
instructions, so that everyone will be able to get (almost) the exact
same release build, as what they can download from the web site.
Moreover, having very clear instructions could make DevOps experience
useful, if we ever need it. For those subscribed to the recruitment
mailing list: yes, I am referring to a recent email received
there. :-)
When a new release is out, a ``snapshot'' of the trunk build
instructions will become the release's build instructions. Similarly
to a git or SVN branch. The trunk instructions always document... the
trunk.
If the above is approved, I will be willing to help achieving it. The
roadmap I can think of is the following:
1- copy the current build instructions to a "release" build
instructions page.
2- fix the "release" build pages (starting from going back in the
page history) so that they contain the actual steps to build AOO
4.1.8.
3- remove outdated parts from the trunk build instructions (such as
the SVN repository)
Thank you in advance for your feedback and comments!
Best regards,
--
rigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Peter Kovacs <pe...@apache.org>.
sure, try what you have in mind.
We wont loose anything by trying.
On 17.12.20 14:05, Arrigo Marchiori wrote:
> Dear All,
>
> I am cross-posting to dev@ and doc@ because... I am not sure which one
> fits best. Please excuse me if this is wrong, and only reply on the
> correct list.
>
> I personally find building OpenOffice a bit too difficult today, in
> terms of _understanding_ what needs to be done. We have build
> instructions on the Wiki, build scripts on a SVN repository, but IMHO
> a little ``integration'' among these pieces would help every newcomers
> (like me) to get a big picture, complete the first successful build
> and start helping with the code.
>
> Here are my ideas. I don't know if these topics were already discussed
> before my subscription to this list; if so, kindly send me a pointer
> so I can avoid you repeating ideas that are already consolidated.
>
> I would like to propose the following layout on the Wiki:
>
> - build instructions for trunk (currently
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> that needs some updating anyway, such as removing SVN)
>
> - specialized build instructions for trunk on individual
> O.S. (Linux, Windows, BSD etc)
>
> - build instructions for the latest release (4.1.8)
>
> - specialized build instructions for the latest release on
> individual O.S.
>
> The distinction between trunk and release is IMHO necessary. For
> example, Jim is doing a very good work of updating core parts of the
> build system, and this changes for one the initial call to the
> configure script. In addition, deprecated information such as the SVN
> repository could be deleted from the trunk build instructions, and
> only remain in the once-applicable instructions.
>
> The current build scripts on SVN should be explicitly indicated in the
> instructions, so that everyone will be able to get (almost) the exact
> same release build, as what they can download from the web site.
>
> Moreover, having very clear instructions could make DevOps experience
> useful, if we ever need it. For those subscribed to the recruitment
> mailing list: yes, I am referring to a recent email received
> there. :-)
>
> When a new release is out, a ``snapshot'' of the trunk build
> instructions will become the release's build instructions. Similarly
> to a git or SVN branch. The trunk instructions always document... the
> trunk.
>
> If the above is approved, I will be willing to help achieving it. The
> roadmap I can think of is the following:
>
> 1- copy the current build instructions to a "release" build
> instructions page.
>
> 2- fix the "release" build pages (starting from going back in the
> page history) so that they contain the actual steps to build AOO
> 4.1.8.
>
> 3- remove outdated parts from the trunk build instructions (such as
> the SVN repository)
>
> Thank you in advance for your feedback and comments!
>
> Best regards,
> --
> rigo
>
> http://rigo.altervista.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
This is the Way! http://www.apache.org/theapacheway/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Request for wiki account [Was: [PROPOSAL] restructuring build documentation]
Posted by Jean Weber <je...@gmail.com>.
To unsubscribe, send email to
doc-unsubscribe@openoffice.apache.org
On Sun, 27 Dec 2020 at 08:24 Valerie Clark <va...@yahoo.com.invalid>
wrote:
> Can someone please remove me from this list? Thank you.Valerie Clark
>
>
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by Valerie Clark <va...@yahoo.com.INVALID>.
Can someone please remove me from this list? Thank you.Valerie Clark
Sent from Yahoo Mail on Android
On Sat, Dec 26, 2020 at 5:23 PM, Keith N. McKenna<ke...@comcast.net> wrote: On 12/26/2020 9:15 AM, Arrigo Marchiori wrote:
> Hello Keith,
>
> On Sun, Dec 20, 2020 at 06:26:42PM -0000, Keith N. McKenna wrote:
>
>> On Sun, 20 Dec 2020 15:41:04 +0100, Arrigo Marchiori wrote:
>>
>>> Hello Keith,
>>>
>>> On Fri, Dec 18, 2020 at 11:07:19PM -0000, Keith N. McKenna wrote:
>>>
>>>> On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
>>>>
>>>>> Dear doc@ list,
>>>>>
>>>>> even if my proposal will not be accepted, I would be glad to
>>>>> contribute to the Wiki, at least updating some outdated instructions
>>>>> or re-organizing in a ``lighter'' way the existing data.
>>>>>
>>>>> If this is acceptable, can someone please grant me write access to
>>>>> the Wiki? Please contact me directly to settle down the username --
>>>>> or just use my email address.
>>>>>
>>>>> Thank you in advance,
>>>>
>>>> Arrigio;
>>>>
>>>> just reply with your preferred user name and I will add the accout as
>>>> soon as possible.
>>>
>>> My preferred user name is "ardovm".
>>>
>>> Thank you in advance and best regards,
>> Accont has been created and a rndom password has been generated and sent
>> under seperate cove. The e-mail shold give instructions to change it but
>> in case it doesn't you can do so here: https://wiki.openoffice.org/wiki/
>> Special:PasswordReset
>
> I have still received nothing, and even if I try to reset my password,
> the wiki says that there is no user named "ardovm".
>
> Could you kindly double-check?
>
> Thank you in advance and best regards,
>
Sorry about the mix-up rigio. Account created and e-mail sent. If you do
not see it, check your spam folder as often this type of message gets
flagged as spam.
Regards
Keith
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On 12/27/2020 3:51 PM, Arrigo Marchiori wrote:
> Hello Keith,
>
> I am very sorry, but I am not receiving any emails, even after
> requesting for a password reset. I did check the SPAM folder.
>
> May be it is a problem with Yahoo? Could you please try dido at quipo
> dot it?
>
> Thank you in advance and best regards.
>
> On Sat, Dec 26, 2020 at 05:22:59PM -0500, Keith N. McKenna wrote:
>
Rigio;
I believe that you are right and that has to do with your @yahoo
address. There is a way that I can send the reset link to me as well as
you. Unfortunately only one reset request in a 24 hour period can be
sent and I will be have to wait until tomorrow afternoon some time to do
that.I will let you know hot it works out via private mail.
Regards
Keith
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Hello Keith,
I am very sorry, but I am not receiving any emails, even after
requesting for a password reset. I did check the SPAM folder.
May be it is a problem with Yahoo? Could you please try dido at quipo
dot it?
Thank you in advance and best regards.
On Sat, Dec 26, 2020 at 05:22:59PM -0500, Keith N. McKenna wrote:
[...]
> Sorry about the mix-up rigio. Account created and e-mail sent. If you do
> not see it, check your spam folder as often this type of message gets
> flagged as spam.
>
> Regards
> Keith
>
>
--
Arrigo
http://rigo.altervista.org
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On 12/26/2020 9:15 AM, Arrigo Marchiori wrote:
> Hello Keith,
>
> On Sun, Dec 20, 2020 at 06:26:42PM -0000, Keith N. McKenna wrote:
>
>> On Sun, 20 Dec 2020 15:41:04 +0100, Arrigo Marchiori wrote:
>>
>>> Hello Keith,
>>>
>>> On Fri, Dec 18, 2020 at 11:07:19PM -0000, Keith N. McKenna wrote:
>>>
>>>> On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
>>>>
>>>>> Dear doc@ list,
>>>>>
>>>>> even if my proposal will not be accepted, I would be glad to
>>>>> contribute to the Wiki, at least updating some outdated instructions
>>>>> or re-organizing in a ``lighter'' way the existing data.
>>>>>
>>>>> If this is acceptable, can someone please grant me write access to
>>>>> the Wiki? Please contact me directly to settle down the username --
>>>>> or just use my email address.
>>>>>
>>>>> Thank you in advance,
>>>>
>>>> Arrigio;
>>>>
>>>> just reply with your preferred user name and I will add the accout as
>>>> soon as possible.
>>>
>>> My preferred user name is "ardovm".
>>>
>>> Thank you in advance and best regards,
>> Accont has been created and a rndom password has been generated and sent
>> under seperate cove. The e-mail shold give instructions to change it but
>> in case it doesn't you can do so here: https://wiki.openoffice.org/wiki/
>> Special:PasswordReset
>
> I have still received nothing, and even if I try to reset my password,
> the wiki says that there is no user named "ardovm".
>
> Could you kindly double-check?
>
> Thank you in advance and best regards,
>
Sorry about the mix-up rigio. Account created and e-mail sent. If you do
not see it, check your spam folder as often this type of message gets
flagged as spam.
Regards
Keith
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Hello Keith,
On Sun, Dec 20, 2020 at 06:26:42PM -0000, Keith N. McKenna wrote:
> On Sun, 20 Dec 2020 15:41:04 +0100, Arrigo Marchiori wrote:
>
> > Hello Keith,
> >
> > On Fri, Dec 18, 2020 at 11:07:19PM -0000, Keith N. McKenna wrote:
> >
> >> On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
> >>
> >> > Dear doc@ list,
> >> >
> >> > even if my proposal will not be accepted, I would be glad to
> >> > contribute to the Wiki, at least updating some outdated instructions
> >> > or re-organizing in a ``lighter'' way the existing data.
> >> >
> >> > If this is acceptable, can someone please grant me write access to
> >> > the Wiki? Please contact me directly to settle down the username --
> >> > or just use my email address.
> >> >
> >> > Thank you in advance,
> >>
> >> Arrigio;
> >>
> >> just reply with your preferred user name and I will add the accout as
> >> soon as possible.
> >
> > My preferred user name is "ardovm".
> >
> > Thank you in advance and best regards,
> Accont has been created and a rndom password has been generated and sent
> under seperate cove. The e-mail shold give instructions to change it but
> in case it doesn't you can do so here: https://wiki.openoffice.org/wiki/
> Special:PasswordReset
I have still received nothing, and even if I try to reset my password,
the wiki says that there is no user named "ardovm".
Could you kindly double-check?
Thank you in advance and best regards,
--
Arrigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On Sun, 20 Dec 2020 15:41:04 +0100, Arrigo Marchiori wrote:
> Hello Keith,
>
> On Fri, Dec 18, 2020 at 11:07:19PM -0000, Keith N. McKenna wrote:
>
>> On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
>>
>> > Dear doc@ list,
>> >
>> > even if my proposal will not be accepted, I would be glad to
>> > contribute to the Wiki, at least updating some outdated instructions
>> > or re-organizing in a ``lighter'' way the existing data.
>> >
>> > If this is acceptable, can someone please grant me write access to
>> > the Wiki? Please contact me directly to settle down the username --
>> > or just use my email address.
>> >
>> > Thank you in advance,
>>
>> Arrigio;
>>
>> just reply with your preferred user name and I will add the accout as
>> soon as possible.
>
> My preferred user name is "ardovm".
>
> Thank you in advance and best regards,
Accont has been created and a rndom password has been generated and sent
under seperate cove. The e-mail shold give instructions to change it but
in case it doesn't you can do so here: https://wiki.openoffice.org/wiki/
Special:PasswordReset
Regards
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Hello Keith,
On Fri, Dec 18, 2020 at 11:07:19PM -0000, Keith N. McKenna wrote:
> On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
>
> > Dear doc@ list,
> >
> > even if my proposal will not be accepted, I would be glad to contribute
> > to the Wiki, at least updating some outdated instructions or
> > re-organizing in a ``lighter'' way the existing data.
> >
> > If this is acceptable, can someone please grant me write access to the
> > Wiki? Please contact me directly to settle down the username -- or just
> > use my email address.
> >
> > Thank you in advance,
>
> Arrigio;
>
> just reply with your preferred user name and I will add the accout as soon
> as possible.
My preferred user name is "ardovm".
Thank you in advance and best regards,
--
rigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On Thu, 17 Dec 2020 21:31:51 +0100, Arrigo Marchiori wrote:
> Dear doc@ list,
>
> even if my proposal will not be accepted, I would be glad to contribute
> to the Wiki, at least updating some outdated instructions or
> re-organizing in a ``lighter'' way the existing data.
>
> If this is acceptable, can someone please grant me write access to the
> Wiki? Please contact me directly to settle down the username -- or just
> use my email address.
>
> Thank you in advance,
Arrigio;
just reply with your preferred user name and I will add the accout as soon
as possible.
Regards
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Request for wiki account [Was: [PROPOSAL] restructuring build
documentation]
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Dear doc@ list,
even if my proposal will not be accepted, I would be glad to
contribute to the Wiki, at least updating some outdated instructions
or re-organizing in a ``lighter'' way the existing data.
If this is acceptable, can someone please grant me write access to the
Wiki? Please contact me directly to settle down the username -- or
just use my email address.
Thank you in advance,
--
rigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Mechtilde <oo...@mechtilde.de>.
Hello Arrigo,
a very big ++1
so far I had the problem how to begin with the restructure.
After you start I can try to put in my description how to build under
Debian 9 (Stretch) and (if it works) under Debian 10 (buster) with java 11.
Regards
Am 17.12.20 um 14:05 schrieb Arrigo Marchiori:
> Dear All,
>
> I am cross-posting to dev@ and doc@ because... I am not sure which one
> fits best. Please excuse me if this is wrong, and only reply on the
> correct list.
>
> I personally find building OpenOffice a bit too difficult today, in
> terms of _understanding_ what needs to be done. We have build
> instructions on the Wiki, build scripts on a SVN repository, but IMHO
> a little ``integration'' among these pieces would help every newcomers
> (like me) to get a big picture, complete the first successful build
> and start helping with the code.
>
> Here are my ideas. I don't know if these topics were already discussed
> before my subscription to this list; if so, kindly send me a pointer
> so I can avoid you repeating ideas that are already consolidated.
>
> I would like to propose the following layout on the Wiki:
>
> - build instructions for trunk (currently
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> that needs some updating anyway, such as removing SVN)
>
> - specialized build instructions for trunk on individual
> O.S. (Linux, Windows, BSD etc)
>
> - build instructions for the latest release (4.1.8)
>
> - specialized build instructions for the latest release on
> individual O.S.
>
> The distinction between trunk and release is IMHO necessary. For
> example, Jim is doing a very good work of updating core parts of the
> build system, and this changes for one the initial call to the
> configure script. In addition, deprecated information such as the SVN
> repository could be deleted from the trunk build instructions, and
> only remain in the once-applicable instructions.
>
> The current build scripts on SVN should be explicitly indicated in the
> instructions, so that everyone will be able to get (almost) the exact
> same release build, as what they can download from the web site.
>
> Moreover, having very clear instructions could make DevOps experience
> useful, if we ever need it. For those subscribed to the recruitment
> mailing list: yes, I am referring to a recent email received
> there. :-)
>
> When a new release is out, a ``snapshot'' of the trunk build
> instructions will become the release's build instructions. Similarly
> to a git or SVN branch. The trunk instructions always document... the
> trunk.
>
> If the above is approved, I will be willing to help achieving it. The
> roadmap I can think of is the following:
>
> 1- copy the current build instructions to a "release" build
> instructions page.
>
> 2- fix the "release" build pages (starting from going back in the
> page history) so that they contain the actual steps to build AOO
> 4.1.8.
>
> 3- remove outdated parts from the trunk build instructions (such as
> the SVN repository)
>
> Thank you in advance for your feedback and comments!
>
> Best regards,
> --
> rigo
>
> http://rigo.altervista.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Re: [PROPOSAL] restructuring build documentation
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Dear dev@ and doc@ lists,
this message is to inform you that I am (slowly) beginning to put my
proposal in action.
There is a thread on dev@ that is about archiving old web pages, that
is currently on hold for the holiday time. I will _not_ wait for that
thread to reach a conclusion, because I honestly believe that
archiving build instructions for individual releases does not really
fit in the purpose of that thread.
If anyone thinks that I am wrong, and that I should instead wait until
that thread has come to a conclusion, then please just tell me, and I
will stop and revert any changes. I am just trying not to lose time,
in the interest of the project.
I take the occasion to wish a happy 2021 to everybody!
--
Arrigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Dear dev@ and doc@ lists,
this message is to inform you that I am (slowly) beginning to put my
proposal in action.
There is a thread on dev@ that is about archiving old web pages, that
is currently on hold for the holiday time. I will _not_ wait for that
thread to reach a conclusion, because I honestly believe that
archiving build instructions for individual releases does not really
fit in the purpose of that thread.
If anyone thinks that I am wrong, and that I should instead wait until
that thread has come to a conclusion, then please just tell me, and I
will stop and revert any changes. I am just trying not to lose time,
in the interest of the project.
I take the occasion to wish a happy 2021 to everybody!
--
Arrigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
RE: [PROPOSAL] restructuring build documentation
Posted by Dennis Hamilton <or...@msn.com>.
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 <ar...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
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:
> > Hello Keith,
> >
> > On Fri, Jan 01, 2021 at 07:30:17PM -0500, Keith N. McKenna wrote:
> >
> >> On 1/1/2021 10:06 AM, Arrigo Marchiori wrote:
> >>> Dear dev@ and doc@ lists,
> >>>
> >>> this message is to inform you that I am (slowly) beginning to put my
> >>> proposal in action.
> >>>
> >>> There is a thread on dev@ that is about archiving old web pages, that
> >>> is currently on hold for the holiday time. I will _not_ wait for that
> >>> thread to reach a conclusion, because I honestly believe that
> >>> archiving build instructions for individual releases does not really
> >>> fit in the purpose of that thread.
> >>>
> >>> If anyone thinks that I am wrong, and that I should instead wait until
> >>> that thread has come to a conclusion, then please just tell me, and I
> >>> will stop and revert any changes. I am just trying not to lose time,
> >>> in the interest of the project.
> >>>
> >>> I take the occasion to wish a happy 2021 to everybody!
> >>>
> >> rigio;
> >>
> >> Irregardless of the archiving thread, I am having a difficult time
> >> seeing the need for per build instructions.I see nothing in the per
> >> revision instructions that is not covered in the generic instructions or
> >> would be better placed in the OS specific instructions.
> >>
> >> Please understand that I look at this purely from a documentation
> >> standpoint as I do not build. From my reading the Build Guides
> >> instructions appear generic enough and link to more specific instruction
> >> for for different operating systems. Please help me understand what I
> >> may be missing.
> >
> > 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
Yes, thank you for further explaining your point.
The reason behind my proposal and edits is simple: I could not find
the information _easily_ enough. Now I think I can use what you wrote
in this and in your previous message to better elaborate the topic of
building older versions, and then leave it all on a single page.
As I am poking into the other pages to make other edits, I found more
than one link to the build scripts, that I could not see when I first
started trying to build OpenOffice. I thought that Mechtilde's "AOO
Bauen" page [1] was the only one mentioning the build scripts it and
now I know I was wrong.
This makes my work overall less urgent than I expected, but I am still
commited to do it because I think that the build documentation is
still worth a little re-organization.
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.
After all, wiki edits can always be reverted; so if the majority of
people here strongly disagrees with me, I will just end up having
gained some experience on MediaWiki. ;-)
References:
1: https://wiki.openoffice.org/wiki/User:Mechtilde/AOOBauen
--
Arrigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On 1/2/2021 4:48 AM, Arrigo Marchiori wrote:
> Hello Keith,
>
> On Fri, Jan 01, 2021 at 07:30:17PM -0500, Keith N. McKenna wrote:
>
>> On 1/1/2021 10:06 AM, Arrigo Marchiori wrote:
>>> Dear dev@ and doc@ lists,
>>>
>>> this message is to inform you that I am (slowly) beginning to put my
>>> proposal in action.
>>>
>>> There is a thread on dev@ that is about archiving old web pages, that
>>> is currently on hold for the holiday time. I will _not_ wait for that
>>> thread to reach a conclusion, because I honestly believe that
>>> archiving build instructions for individual releases does not really
>>> fit in the purpose of that thread.
>>>
>>> If anyone thinks that I am wrong, and that I should instead wait until
>>> that thread has come to a conclusion, then please just tell me, and I
>>> will stop and revert any changes. I am just trying not to lose time,
>>> in the interest of the project.
>>>
>>> I take the occasion to wish a happy 2021 to everybody!
>>>
>> rigio;
>>
>> Irregardless of the archiving thread, I am having a difficult time
>> seeing the need for per build instructions.I see nothing in the per
>> revision instructions that is not covered in the generic instructions or
>> would be better placed in the OS specific instructions.
>>
>> Please understand that I look at this purely from a documentation
>> standpoint as I do not build. From my reading the Build Guides
>> instructions appear generic enough and link to more specific instruction
>> for for different operating systems. Please help me understand what I
>> may be missing.
>
> 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
Regards
Keith
>> Unless you are looking at adding a new operating system
>> at this point I do not see the need to add per build for instructions
>> that will just add more pieces that will add to the debate over what to
>> do with what some will call outdated material and want to have it archived.
>
> After a brief work on this topic, I expect each release to require not
> more than 2 or 3 pages.
>
> For sure, I do not want to make the debate any more complex than it is
> now! That would be the main reason to stop immediately.
>
> For the moment, I isolated the "main" build instructions for:
> - 4.1.8,
> - 4.1.7,
> - 4.1.6,
> - 4.1.5.
>
> Those are just snapshots of the main page, taken at (hopefully)
> appropriate moments in time, with very small changes.
>
> I really think that 4.1.8-related pages are important. We currently
> have two development branches and one RC branch; why should we only
> have one page for build instructions? I can delete the older ones if
> others share your point of view.
>
> As future perspective, my proposal is to "snapshot" the trunk
> instructions (once reviewed) for each future release. If we decide
> that we do not want outdated instructions, we will just delete the
> next-to-last page.
>
>> I look forward to discussing this with you further.
>
> Thank you for sharing your opinion! I hope I understood your
> criticism and replied in topic.
>
> Best regards,
>
Re: [PROPOSAL] restructuring build documentation
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Hello Keith,
On Fri, Jan 01, 2021 at 07:30:17PM -0500, Keith N. McKenna wrote:
> On 1/1/2021 10:06 AM, Arrigo Marchiori wrote:
> > Dear dev@ and doc@ lists,
> >
> > this message is to inform you that I am (slowly) beginning to put my
> > proposal in action.
> >
> > There is a thread on dev@ that is about archiving old web pages, that
> > is currently on hold for the holiday time. I will _not_ wait for that
> > thread to reach a conclusion, because I honestly believe that
> > archiving build instructions for individual releases does not really
> > fit in the purpose of that thread.
> >
> > If anyone thinks that I am wrong, and that I should instead wait until
> > that thread has come to a conclusion, then please just tell me, and I
> > will stop and revert any changes. I am just trying not to lose time,
> > in the interest of the project.
> >
> > I take the occasion to wish a happy 2021 to everybody!
> >
> rigio;
>
> Irregardless of the archiving thread, I am having a difficult time
> seeing the need for per build instructions.I see nothing in the per
> revision instructions that is not covered in the generic instructions or
> would be better placed in the OS specific instructions.
>
> Please understand that I look at this purely from a documentation
> standpoint as I do not build. From my reading the Build Guides
> instructions appear generic enough and link to more specific instruction
> for for different operating systems. Please help me understand what I
> may be missing.
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.
> Unless you are looking at adding a new operating system
> at this point I do not see the need to add per build for instructions
> that will just add more pieces that will add to the debate over what to
> do with what some will call outdated material and want to have it archived.
After a brief work on this topic, I expect each release to require not
more than 2 or 3 pages.
For sure, I do not want to make the debate any more complex than it is
now! That would be the main reason to stop immediately.
For the moment, I isolated the "main" build instructions for:
- 4.1.8,
- 4.1.7,
- 4.1.6,
- 4.1.5.
Those are just snapshots of the main page, taken at (hopefully)
appropriate moments in time, with very small changes.
I really think that 4.1.8-related pages are important. We currently
have two development branches and one RC branch; why should we only
have one page for build instructions? I can delete the older ones if
others share your point of view.
As future perspective, my proposal is to "snapshot" the trunk
instructions (once reviewed) for each future release. If we decide
that we do not want outdated instructions, we will just delete the
next-to-last page.
> I look forward to discussing this with you further.
Thank you for sharing your opinion! I hope I understood your
criticism and replied in topic.
Best regards,
--
Arrigo
http://rigo.altervista.org
Re: [PROPOSAL] restructuring build documentation
Posted by "Keith N. McKenna" <ke...@comcast.net>.
On 1/1/2021 10:06 AM, Arrigo Marchiori wrote:
> Dear dev@ and doc@ lists,
>
> this message is to inform you that I am (slowly) beginning to put my
> proposal in action.
>
> There is a thread on dev@ that is about archiving old web pages, that
> is currently on hold for the holiday time. I will _not_ wait for that
> thread to reach a conclusion, because I honestly believe that
> archiving build instructions for individual releases does not really
> fit in the purpose of that thread.
>
> If anyone thinks that I am wrong, and that I should instead wait until
> that thread has come to a conclusion, then please just tell me, and I
> will stop and revert any changes. I am just trying not to lose time,
> in the interest of the project.
>
> I take the occasion to wish a happy 2021 to everybody!
>
rigio;
Irregardless of the archiving thread, I am having a difficult time
seeing the need for per build instructions.I see nothing in the per
revision instructions that is not covered in the generic instructions or
would be better placed in the OS specific instructions.
Please understand that I look at this purely from a documentation
standpoint as I do not build. From my reading the Build Guides
instructions appear generic enough and link to more specific instruction
for for different operating systems. Please help me understand what I
may be missing. Unless you are looking at adding a new operating system
at this point I do not see the need to add per build for instructions
that will just add more pieces that will add to the debate over what to
do with what some will call outdated material and want to have it archived.
I look forward to discussing this with you further.
Regards
Keith
Re: [PROPOSAL] restructuring build documentation
Posted by Arrigo Marchiori <ar...@yahoo.it.INVALID>.
Hello Dave,
On Thu, Dec 17, 2020 at 11:09:15AM -0800, Dave Fisher wrote:
> Hi Arrigo,
>
> I really appreciate your enthusiasm and excellent help on AOO!
Thank you! I am just doing what I can.
> There was another thread where we discussed moving devtools to git.
I think you mean this one?
https://lists.apache.org/thread.html/r64090cf9de98c0147098b5d7d58b5f248c71b42e06d3dcb1c536bc88%40%3Cdev.openoffice.apache.org%3E
> I think this would be the perfect time to move/rewrite build instructions as
markdown files on these GitHub repos:
>
> Apache/openoffice - README.md
> Apache/openoffice-project source.md
> A new Apache/openoffice-devtools
>
> I would deprecate the Wiki instructions.
I think I get your point. This would ensure that the doc is always
paired with the software it talks about.
However, I suggest to keep this documentation on the Wiki, at least at
a first stage. I think it is quicker and easier to edit, and better
allows people to cooperate on the same document, than using Git and
pull requests.
When finished, the ``snapshots'' could be saved into the source tree
when a release is published, and this could avoid us ``branches'' on
the wiki as well as on the code. But I would leave such decision to a
later stage.
I hope this makes sense.
Best regards,
--
rigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Dave Fisher <wa...@apache.org>.
Hi Arrigo,
I really appreciate your enthusiasm and excellent help on AOO!
There was another thread where we discussed moving devtools to git.
I think this would be the perfect time to move/rewrite build instructions as markdown files on these GitHub repos:
Apache/openoffice - README.md
Apache/openoffice-project source.md
A new Apache/openoffice-devtools
I would deprecate the Wiki instructions.
Regards,
Dave
> On Dec 17, 2020, at 5:05 AM, Arrigo Marchiori <ar...@yahoo.it.INVALID> wrote:
>
> Dear All,
>
> I am cross-posting to dev@ and doc@ because... I am not sure which one
> fits best. Please excuse me if this is wrong, and only reply on the
> correct list.
>
> I personally find building OpenOffice a bit too difficult today, in
> terms of _understanding_ what needs to be done. We have build
> instructions on the Wiki, build scripts on a SVN repository, but IMHO
> a little ``integration'' among these pieces would help every newcomers
> (like me) to get a big picture, complete the first successful build
> and start helping with the code.
>
> Here are my ideas. I don't know if these topics were already discussed
> before my subscription to this list; if so, kindly send me a pointer
> so I can avoid you repeating ideas that are already consolidated.
>
> I would like to propose the following layout on the Wiki:
>
> - build instructions for trunk (currently
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> that needs some updating anyway, such as removing SVN)
>
> - specialized build instructions for trunk on individual
> O.S. (Linux, Windows, BSD etc)
>
> - build instructions for the latest release (4.1.8)
>
> - specialized build instructions for the latest release on
> individual O.S.
>
> The distinction between trunk and release is IMHO necessary. For
> example, Jim is doing a very good work of updating core parts of the
> build system, and this changes for one the initial call to the
> configure script. In addition, deprecated information such as the SVN
> repository could be deleted from the trunk build instructions, and
> only remain in the once-applicable instructions.
>
> The current build scripts on SVN should be explicitly indicated in the
> instructions, so that everyone will be able to get (almost) the exact
> same release build, as what they can download from the web site.
>
> Moreover, having very clear instructions could make DevOps experience
> useful, if we ever need it. For those subscribed to the recruitment
> mailing list: yes, I am referring to a recent email received
> there. :-)
>
> When a new release is out, a ``snapshot'' of the trunk build
> instructions will become the release's build instructions. Similarly
> to a git or SVN branch. The trunk instructions always document... the
> trunk.
>
> If the above is approved, I will be willing to help achieving it. The
> roadmap I can think of is the following:
>
> 1- copy the current build instructions to a "release" build
> instructions page.
>
> 2- fix the "release" build pages (starting from going back in the
> page history) so that they contain the actual steps to build AOO
> 4.1.8.
>
> 3- remove outdated parts from the trunk build instructions (such as
> the SVN repository)
>
> Thank you in advance for your feedback and comments!
>
> Best regards,
> --
> rigo
>
> http://rigo.altervista.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org
Re: [PROPOSAL] restructuring build documentation
Posted by Dave Fisher <wa...@apache.org>.
Hi Arrigo,
I really appreciate your enthusiasm and excellent help on AOO!
There was another thread where we discussed moving devtools to git.
I think this would be the perfect time to move/rewrite build instructions as markdown files on these GitHub repos:
Apache/openoffice - README.md
Apache/openoffice-project source.md
A new Apache/openoffice-devtools
I would deprecate the Wiki instructions.
Regards,
Dave
> On Dec 17, 2020, at 5:05 AM, Arrigo Marchiori <ar...@yahoo.it.INVALID> wrote:
>
> Dear All,
>
> I am cross-posting to dev@ and doc@ because... I am not sure which one
> fits best. Please excuse me if this is wrong, and only reply on the
> correct list.
>
> I personally find building OpenOffice a bit too difficult today, in
> terms of _understanding_ what needs to be done. We have build
> instructions on the Wiki, build scripts on a SVN repository, but IMHO
> a little ``integration'' among these pieces would help every newcomers
> (like me) to get a big picture, complete the first successful build
> and start helping with the code.
>
> Here are my ideas. I don't know if these topics were already discussed
> before my subscription to this list; if so, kindly send me a pointer
> so I can avoid you repeating ideas that are already consolidated.
>
> I would like to propose the following layout on the Wiki:
>
> - build instructions for trunk (currently
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> that needs some updating anyway, such as removing SVN)
>
> - specialized build instructions for trunk on individual
> O.S. (Linux, Windows, BSD etc)
>
> - build instructions for the latest release (4.1.8)
>
> - specialized build instructions for the latest release on
> individual O.S.
>
> The distinction between trunk and release is IMHO necessary. For
> example, Jim is doing a very good work of updating core parts of the
> build system, and this changes for one the initial call to the
> configure script. In addition, deprecated information such as the SVN
> repository could be deleted from the trunk build instructions, and
> only remain in the once-applicable instructions.
>
> The current build scripts on SVN should be explicitly indicated in the
> instructions, so that everyone will be able to get (almost) the exact
> same release build, as what they can download from the web site.
>
> Moreover, having very clear instructions could make DevOps experience
> useful, if we ever need it. For those subscribed to the recruitment
> mailing list: yes, I am referring to a recent email received
> there. :-)
>
> When a new release is out, a ``snapshot'' of the trunk build
> instructions will become the release's build instructions. Similarly
> to a git or SVN branch. The trunk instructions always document... the
> trunk.
>
> If the above is approved, I will be willing to help achieving it. The
> roadmap I can think of is the following:
>
> 1- copy the current build instructions to a "release" build
> instructions page.
>
> 2- fix the "release" build pages (starting from going back in the
> page history) so that they contain the actual steps to build AOO
> 4.1.8.
>
> 3- remove outdated parts from the trunk build instructions (such as
> the SVN repository)
>
> Thank you in advance for your feedback and comments!
>
> Best regards,
> --
> rigo
>
> http://rigo.altervista.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org