Re: Nightly Builds
On Sat, Jan 21, 2023 at 3:14 PM Matthias Seidel wrote: > > Four weeks are a good period to have archived if a regression occurs. > > No. For old regressions, or to discover old fixes, we ideally want a build from every month in AOO's history.
Re: Nightly Builds
Am 26.01.23 um 16:49 schrieb Carl Marcum: On 1/26/23 10:09 AM, Matthias Seidel wrote: I think we can all agree on a 4 week (30 days) period for archiving the binaries? 4 weeks max seems fine to me. for me also, when the build is always done, independent of a commit. And if possible only build one if there was a commit. +1 Looking at: https://nightlies.apache.org/openoffice/install/linux64/?C=M;O=D we should also think about shortening the filenames. For example the Git hash could be reduced to the first 10 digits. Yes, that's too long. With a prefix to recognize that it's a Git hash then IMHO it would be great. Example: Apache_OpenOffice-SDK_4.5.0_Linux_x86-64_install-deb_en-US_2023-01-26_09:13:18_Git_8a7b2c9448.tar.gz Marcus Am 22.01.23 um 09:31 schrieb Peter kovacs: The output from git --log can be filtered to a since date. If we use the last build date then we can check if there are entries. Maybe some other switches would help. Am 21. Januar 2023 15:03:02 MEZ schrieb Matthias Seidel : Hi Gavin, Am 21.01.23 um 13:33 schrieb Gavin McDonald: Hi All, The nightly builds at https://ci2.apache.org/#/builders/58 are using up much unnecessary disk space on the nightlies.apache.org server. Currently Openoffice alone is using more than 1TB - all due to these nightly builds. Over 600GB are the linux64 snapshots and the rest are the linsnap* ones. Many many of these snapshots are identical to previous ones, but because the date of the build is included then they are just repeated each day. Even if no commits for weeks there is multi GB tars and debs being uploaded each day. This seems a waste. Not only this, but no snapshots are being cleaned up, we have snapshots dating back nearly a year just sitting there. Lets clean this up and be smarter going forwards. I would like to see these nightlies changed :- 1. Change to run weekly instead of daily. 2. Instead of, or in addition to 1, build and upload by commit trigger. Just to clarify: I think the logic should be: Look every day (night) if there was a code change. If yes, do a build, otherwise skip. I don't want to trigger a build with every single commit... ;-) Regards, Matthias 3. Clean up snapshots older than 1 month. Thoughts please - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Nightly Builds
Hi Matthias and All, On 1/26/23 10:09 AM, Matthias Seidel wrote: Hi all, I think we can all agree on a 4 week (30 days) period for archiving the binaries? 4 weeks max seems fine to me. And if possible only build one if there was a commit. For Linux I build my own anyway. I really need mac builds since I can't build on Silicon but that's for another topic. Best regards, Carl Looking at: https://nightlies.apache.org/openoffice/install/linux64/?C=M;O=D we should also think about shortening the filenames. For example the Git hash could be reduced to the first 10 digits. Opinions? Regards, Matthias Am 22.01.23 um 09:31 schrieb Peter kovacs: The output from git --log can be filtered to a since date. If we use the last build date then we can check if there are entries. Maybe some other switches would help. Am 21. Januar 2023 15:03:02 MEZ schrieb Matthias Seidel : Hi Gavin, Am 21.01.23 um 13:33 schrieb Gavin McDonald: Hi All, The nightly builds at https://ci2.apache.org/#/builders/58 are using up much unnecessary disk space on the nightlies.apache.org server. Currently Openoffice alone is using more than 1TB - all due to these nightly builds. Over 600GB are the linux64 snapshots and the rest are the linsnap* ones. Many many of these snapshots are identical to previous ones, but because the date of the build is included then they are just repeated each day. Even if no commits for weeks there is multi GB tars and debs being uploaded each day. This seems a waste. Not only this, but no snapshots are being cleaned up, we have snapshots dating back nearly a year just sitting there. Lets clean this up and be smarter going forwards. I would like to see these nightlies changed :- 1. Change to run weekly instead of daily. 2. Instead of, or in addition to 1, build and upload by commit trigger. Just to clarify: I think the logic should be: Look every day (night) if there was a code change. If yes, do a build, otherwise skip. I don't want to trigger a build with every single commit... ;-) Regards, Matthias 3. Clean up snapshots older than 1 month. Thoughts please - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Nightly Builds
Hi all, I think we can all agree on a 4 week (30 days) period for archiving the binaries? Looking at: https://nightlies.apache.org/openoffice/install/linux64/?C=M;O=D we should also think about shortening the filenames. For example the Git hash could be reduced to the first 10 digits. Opinions? Regards, Matthias Am 22.01.23 um 09:31 schrieb Peter kovacs: > The output from git --log can be filtered to a since date. If we use the last > build date then we can check if there are entries. > Maybe some other switches would help. > > Am 21. Januar 2023 15:03:02 MEZ schrieb Matthias Seidel > : >> Hi Gavin, >> >> Am 21.01.23 um 13:33 schrieb Gavin McDonald: >>> Hi All, >>> >>> The nightly builds at https://ci2.apache.org/#/builders/58 are using up >>> much unnecessary >>> disk space on the nightlies.apache.org server. >>> >>> Currently Openoffice alone is using more than 1TB - all due to these >>> nightly builds. >>> Over 600GB are the linux64 snapshots and the rest are the linsnap* ones. >>> >>> Many many of these snapshots are identical to previous ones, but because >>> the date of the build is included then they are just repeated each day. >>> Even if no commits for weeks there is multi GB tars and debs being uploaded >>> each day. >>> >>> This seems a waste. >>> >>> Not only this, but no snapshots are being cleaned up, we have snapshots >>> dating back nearly a year just sitting there. >>> >>> Lets clean this up and be smarter going forwards. >>> >>> I would like to see these nightlies changed :- >>> >>> 1. Change to run weekly instead of daily. >>> 2. Instead of, or in addition to 1, build and upload by commit trigger. >> Just to clarify: >> >> I think the logic should be: Look every day (night) if there was a code >> change. If yes, do a build, otherwise skip. >> >> I don't want to trigger a build with every single commit... ;-) >> >> Regards, >> >> Matthias >> >>> 3. Clean up snapshots older than 1 month. >>> >>> Thoughts please >>> smime.p7s Description: S/MIME Cryptographic Signature
Re: Forums: BBcode for [rel] links broken
[rel] is not a standard BBcode It would take someone with enough karma to go modify it in the ACP. - Mail original - > De: "Hagar Delest" > À: dev@openoffice.apache.org > Envoyé: Mercredi 25 Janvier 2023 21:54:28 > Objet: Re: Forums: BBcode for [rel] links broken > > Hi, > > I saw that there was some improvement with the Italian forum. > If someone could fix this one too, that would be great. > TIA. > > Hagar > > Le 05/10/2022 à 20:15, Hagar Delest a écrit : > > Hi, > > > > I noticed the [rel] BBcode tag started to work again a short while > > ago. But today, I had the Firefox security warning again (on my > > xubuntu machine). > > I noticed that the url being parsed is > > https://forum.openoffice.org//en/forum/viewtopic.php?f=5=166 for > > example with 2 slashes after the forum.openoffice.org string. > > Any change recently that could have given this glitch? > > > > Hagar > > > > Le 31/05/2022 à 18:55, Dave Fisher a écrit : > >> Hi Hagar, > >> > >> I’ve asked Infra to make some changes to how the > >> user.services.openoffice.org domain is handled. > >> > >> Currently it is an alias (CNAME) for forum.openoffice.org. We are > >> changing it into a redirect from another server. > >> > >> Once that is done we will see if this just fixes itself or if a > >> restart and cache clearance is required. > >> > >>> On May 30, 2022, at 1:01 PM, Hagar Delest > >>> > >>> wrote: > >>> > >>> Hi (Dave), > >>> > >>> There is a problem at least in the EN forum with links made with > >>> the > >>> [rel] BBcode tag. > >>> The base url seems to have reverted to > >>> "https://user.services.openoffice.org/en/forum/; instead of > >>> "https://forum.openoffice.org/en/forum/;. > >>> The consequence is that there is no redirection but an error > >>> message > >>> from the browser (tested with Firefox on Xubuntu 22.04 only), > >>> stating that there may be a security risk following that link > >>> (translation from my French error message). > >>> It used to worked after the migration (it needed a tweak > >>> however). > >>> > >>> I checked in the admin panel of the phpBB interface but I've not > >>> found any string in the interface. Seems to be something in a > >>> configuration file on the server. > >>> > >>> Note: I always took the pain to write my links with that BBcode > >>> to > >>> make it more lean but this issue quite defeats the point. > >>> > >>> Thanks. > >>> Hagar > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
