Re: [log4j] Project URLs per major version
Considering I’m one of the only people who adds @since tags (or Javadocs in general), I think we’ll need some tooling to help with this. In Jenkins, we had some sort of script for this so that we could add “@since TODO” to new files, and the script would replace them all before tagging a release (which is more relevant when you have weekly releases). > On Oct 23, 2023, at 6:28 AM, Volkan Yazıcı wrote: > > Agreed, we should use `@since` tags. Though this doesn't warrant a new > website folder for each release, does it? Given we never disclosed these > folders, I want to understand the value it delivered in the past that can't > be achieved if we switch to using a single folder. > > On Mon, Oct 23, 2023 at 12:49 PM Piotr P. Karwasz > wrote: > >> Hi Volkan, >> >> On Mon, 23 Oct 2023 at 10:40, Volkan Yazıcı wrote: >>> it [doesn't] fully documents what was in prior releases >>> >>> Why is this a problem? We document newly added features with "starting >> from >>> version X, Log4j ships Y...". Doesn't this address your concern? >> >> I prefer to document each new public/protected class or method with a >> `@since` tag. We often don't do that (e.g. even in 2.21.0 there are a >> couple of new methods). >> >> Maybe there is an automatic scanner that can do it. >> >> Piotr >>
Re: [log4j] Annotation processing alternatives
We really don’t have much choice. With JPMS you really need to use ServiceLoader to locate things like plugins across modules. Using a s file like spring.factories doesn’t really help anyway. You wouldn’t want to force users to hand create the entries in that file and so would use annotations and a processor to populate it, which is exactly what we are doing. Ralph > On Oct 23, 2023, at 10:12 AM, Gary Gregory wrote: > > Staying from the built-in Service Loader is a recipe for even more > custom code and complications. I say we stick with the built-in > Service Loader. > > Gary > >> On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz >> wrote: >> >> Hi Matt, >> >>> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: >>> So now we come to your question about a factories file. That’s an >>> interesting idea, though it’s extremely similar to what we’re doing here >>> with ServiceLoader (though the split between META-INF/services/ files and >>> module-info.java provides/uses entries is confusing). Moving away from >>> ServiceLoader to a custom mechanism might be more flexible, though I’m not >>> very knowledgeable about how Java modules work with them. >> >> I think that `ServiceLoader` is the only standard feature that is >> supported by both OSGi and JPMS. If we move away from it, we'll need >> some custom code to support it (or `opens`, etc). I wouldn't go that >> way. >> >> Piotr
Re: [log4j] Annotation processing alternatives
So really, the question is whether we can make the generated service classes easier to create without annotation processing? > On Oct 23, 2023, at 12:11 PM, Gary Gregory wrote: > > Staying from the built-in Service Loader is a recipe for even more > custom code and complications. I say we stick with the built-in > Service Loader. > > Gary > > On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz > wrote: >> >> Hi Matt, >> >> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: >>> So now we come to your question about a factories file. That’s an >>> interesting idea, though it’s extremely similar to what we’re doing here >>> with ServiceLoader (though the split between META-INF/services/ files and >>> module-info.java provides/uses entries is confusing). Moving away from >>> ServiceLoader to a custom mechanism might be more flexible, though I’m not >>> very knowledgeable about how Java modules work with them. >> >> I think that `ServiceLoader` is the only standard feature that is >> supported by both OSGi and JPMS. If we move away from it, we'll need >> some custom code to support it (or `opens`, etc). I wouldn't go that >> way. >> >> Piotr
Re: [log4j] Annotation processing alternatives
Staying from the built-in Service Loader is a recipe for even more custom code and complications. I say we stick with the built-in Service Loader. Gary On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz wrote: > > Hi Matt, > > On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: > > So now we come to your question about a factories file. That’s an > > interesting idea, though it’s extremely similar to what we’re doing here > > with ServiceLoader (though the split between META-INF/services/ files and > > module-info.java provides/uses entries is confusing). Moving away from > > ServiceLoader to a custom mechanism might be more flexible, though I’m not > > very knowledgeable about how Java modules work with them. > > I think that `ServiceLoader` is the only standard feature that is > supported by both OSGi and JPMS. If we move away from it, we'll need > some custom code to support it (or `opens`, etc). I wouldn't go that > way. > > Piotr
Re: Staging sites and repo convention
I think #2 would be necessary when we start doing concurrent releases of the same project; e.g., Log4j `2.34.0` and `3.2.0`. I really liked the single-use staging domains *you* proposed due to the conveniences it enables and I would rather keep it. On Mon, Oct 23, 2023 at 2:03 PM Piotr P. Karwasz wrote: > Hi Volkan, > > On Sun, 22 Oct 2023 at 23:47, Volkan Yazıcı wrote: > >2. Instead of using logging.*staged.*apache.org*/foo*, we will use > >logging*-foo.staged.*apache.org for staging websites. > >3. Log4j Scala, Kotlin, Tools, and Transformation website content will > >be moved from `logging-log4j-site` repository to > `logging-log4j-scala`, > >`logging-log4j-kotlin`, `logging-log4j-tools`, and > >`logging-log4j-transformation` repositories, respectively. > > If we implement 3, 2 will become optional: as long as each project is > on a separate Git repo/branch staging should be easy. > > Piotr >
Re: [VOTE] Release Apache Log4j 2.21.1 RC1
Does not matter, running "mvn clean verify -Psequential-tests", I still get: [ERROR] Failures: [ERROR] UrlConnectionFactoryTest.withAuthentication:130 File was not modified ==> expected: <200> but was: <304> [INFO] [ERROR] Tests run: 2774, Failures: 1, Errors: 0, Skipped: 35 Gary On 2023/10/23 12:50:59 Gary Gregory wrote: > On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz > wrote: > > > > Hi Gary, > > > > On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote: > > > > > > I reran again yesterday, got the same 2 failures we know about plus a new > > > one: > > > > Parallel tests on Windows must be worse than I imagined. Can you run > > with `-Psequential-tests` in the meantime and I'll try to fix those > > problems in a future release? > > Testing... > > Gary > > > > > Piotr >
Re: [VOTE] Release Apache Log4j 2.21.1 RC1
+1 Windows is running on my other PC but all is well on macOS with 'mvn clean verify' using: Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: /usr/local/Cellar/maven/3.9.5/libexec Java version: 11.0.21, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@11/11.0.21/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac" Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64 Gary On Mon, Oct 23, 2023 at 8:50 AM Gary Gregory wrote: > > On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz > wrote: > > > > Hi Gary, > > > > On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote: > > > > > > I reran again yesterday, got the same 2 failures we know about plus a new > > > one: > > > > Parallel tests on Windows must be worse than I imagined. Can you run > > with `-Psequential-tests` in the meantime and I'll try to fix those > > problems in a future release? > > Testing... > > Gary > > > > > Piotr
Re: [VOTE] Release Apache Log4j 2.21.1 RC1
On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz wrote: > > Hi Gary, > > On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote: > > > > I reran again yesterday, got the same 2 failures we know about plus a new > > one: > > Parallel tests on Windows must be worse than I imagined. Can you run > with `-Psequential-tests` in the meantime and I'll try to fix those > problems in a future release? Testing... Gary > > Piotr
Re: [VOTE] Release Apache Log4j 2.21.1 RC1
Hi Gary, On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote: > > I reran again yesterday, got the same 2 failures we know about plus a new one: Parallel tests on Windows must be worse than I imagined. Can you run with `-Psequential-tests` in the meantime and I'll try to fix those problems in a future release? Piotr
Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
Hi On Mon, Oct 23, 2023, at 11:01, Volkan Yazıcı wrote: > Staging website has been broken since October 10, that is, the last two > weeks – please, correct me if I'm wrong. I support Christian's Jekyll > migration and I know he is blocked by INFRA. I have created the issue only 5 days ago, after Infra and I discussed a lot about bug fixing some infra code. It was a weekend between, so I think we should be a bit more patient >1. Do we have a deadline to consider alternative courses of action? I have no deadline, I would like to make this happen >2. Can we implement your Jekyll goal in a way (e.g., build+publish via >CI) that we can roll back to the old working state yet make Jekyll work for >you? The bug fix works and we have /content folder as it was before. There is a mess up on the server to which we don't have access to. Even when we rollback, there will not be a change, as we already have tzhe old setup > > > On Fri, Oct 13, 2023 at 1:47 PM Christian Grobmeier > wrote: > >> >> >> [1] Christian's recent Jekyll experiment on the `asf-staging` branch >> >> of `logging-site` repository confused the INFRA and it is acting >> >> strangely. This will *NOT* be an issue when we push the website >> >> changes to production, i.e., `asf-site` branch. Though we will try >> >> fixing `asf-staging` anyway in the meantime. >> >> On Fri, Oct 13, 2023, at 13:28, Piotr P. Karwasz wrote: >> > I think that the problem is that the `asf-staging` branch in >> > `logging-site` has switched from a `content` folder to an `output` >> > folder, while some of our 6 other site repos have a `content` folder. >> > It is fixable, but INFRA offers us an infinite number of >> > `logging-.staged.apache.org` domains and I think we should use >> > it. >> >> According to this doc: >> >> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features#Git.asf.yamlfeatures-WebsitedeploymentserviceforGitrepositories >> >> We just have to give it a profile: >> >> staging: >> profile: mystuff >> >> Would result in: >> >> logging-mystuff.staged.apache.org >> >> I can easily migrate to this. >> >> The folder "output" is the default with ASF infra, but it is possible to >> replace it with content: >> >> jekyll: >> whoami: jekyll >> target: asf-staging >> outputdir: content >> >> Why is content not causing this issue? >> For me both is possible, just trying to understand the best way. >> >> Kind regards, >> Christian >>
Re: [VOTE] Release Apache Log4j 2.21.1 RC1
I reran again yesterday, got the same 2 failures we know about plus a new one: [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.236 s <<< FAILURE! -- in org.apache.logging.log4j.core.config.FileOutputTest [ERROR] org.apache.logging.log4j.core.config.FileOutputTest.testConfig -- Time elapsed: 5.628 s <<< FAILURE! org.opentest4j.AssertionFailedError: target\test.log failed with java.nio.file.FileSystemException: target\test.log: The process cannot access the file because it is being used by another process. at org.apache.logging.log4j.test.junit.AbstractFileCleaner.clean(AbstractFileCleaner.java:82) at org.apache.logging.log4j.test.junit.AbstractFileCleaner.beforeEach(AbstractFileCleaner.java:43) at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) Suppressed: org.opentest4j.AssertionFailedError: target\test.log failed with java.nio.file.FileSystemException: target\test.log: The process cannot access the file because it is being used by another process. at org.apache.logging.log4j.test.junit.AbstractFileCleaner.clean(AbstractFileCleaner.java:82) at org.apache.logging.log4j.test.junit.AbstractFileCleaner.afterEach(AbstractFileCleaner.java:48) ... 2 more at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:253) Gary On 2023/10/21 20:28:31 "Piotr P. Karwasz" wrote: > Hi Gary, > > On Sat, 21 Oct 2023 at 15:11, Gary D. Gregory wrote: > > > > I got this failure: > > > > [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > > 29.00 s <<< FAILURE! -- in > > org.apache.logging.log4j.core.net.UrlConnectionFactoryTest > > [ERROR] > > org.apache.logging.log4j.core.net.UrlConnectionFactoryTest.withAuthentication > > -- Time elapsed: 0.039 s <<< FAILURE! > > On Sat, 21 Oct 2023 at 15:25, Gary D. Gregory wrote: > > > > Dang, another random failure: > > > > [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > > 53.21 s <<< FAILURE! -- in > > org.apache.logging.log4j.core.appender.rolling.RollingAppenderCronAndSizeTest > > [ERROR] > > org.apache.logging.log4j.core.appender.rolling.RollingAppenderCronAndSizeTest.testAppender > > -- Time elapsed: 53.16 s <<< FAILURE! > > I'll look into those. Some tests in a parallel run fail if multiple > tests access the same file (especially on Windows), but these do not > seem to match this category. > > Piotr >
Re: [log4j] Project URLs per major version
Agreed, we should use `@since` tags. Though this doesn't warrant a new website folder for each release, does it? Given we never disclosed these folders, I want to understand the value it delivered in the past that can't be achieved if we switch to using a single folder. On Mon, Oct 23, 2023 at 12:49 PM Piotr P. Karwasz wrote: > Hi Volkan, > > On Mon, 23 Oct 2023 at 10:40, Volkan Yazıcı wrote: > > > > > it [doesn't] fully documents what was in prior releases > > > > Why is this a problem? We document newly added features with "starting > from > > version X, Log4j ships Y...". Doesn't this address your concern? > > I prefer to document each new public/protected class or method with a > `@since` tag. We often don't do that (e.g. even in 2.21.0 there are a > couple of new methods). > > Maybe there is an automatic scanner that can do it. > > Piotr >
RE: [VOTE] Release Apache Log4j 2.21.1 RC1
+1 Tested it with our product and works flawlessly where 2.20.0 failed On 2023/10/20 21:20:00 "Piotr P. Karwasz" wrote: > This is a vote to release the Apache Log4j 2.21.1. > > Website: https://logging-log4j2.staged.apache.org/log4j > GitHub: https://github.com/apache/logging-log4j2 > Commit: e613e9ed71279bb52753a4df810d61c11389df81 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j > Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1209 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. > > == Countdown > > https://www.timeanddate.com/countdown/party?iso=20231023T2320=1449=cursive > > == Release Notes > > This patch release contains only the fix of a `log4j-jcl` bug that > prevents it from connecting with `commons-logging`. > > The Log4j 2.21.1 API, as well as the other artifacts, maintains binary > compatibility with the previous release. > > Apache Log4j 2.21.1 requires Java 8 to run. > The build requires JDK 11 and generates reproducible binaries. > > For complete information on Apache Log4j 2, including instructions on > how to submit bug reports, patches, get support, or suggestions for > improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j > 2 website]. > > > === Fixed > > * Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865) > > Piotr >
Re: [log4j] Project URLs per major version
Hi Volkan, On Mon, 23 Oct 2023 at 10:40, Volkan Yazıcı wrote: > > > it [doesn't] fully documents what was in prior releases > > Why is this a problem? We document newly added features with "starting from > version X, Log4j ships Y...". Doesn't this address your concern? I prefer to document each new public/protected class or method with a `@since` tag. We often don't do that (e.g. even in 2.21.0 there are a couple of new methods). Maybe there is an automatic scanner that can do it. Piotr
Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
Staging website has been broken since October 10, that is, the last two weeks – please, correct me if I'm wrong. I support Christian's Jekyll migration and I know he is blocked by INFRA. 1. Do we have a deadline to consider alternative courses of action? 2. Can we implement your Jekyll goal in a way (e.g., build+publish via CI) that we can roll back to the old working state yet make Jekyll work for you? On Fri, Oct 13, 2023 at 1:47 PM Christian Grobmeier wrote: > > >> [1] Christian's recent Jekyll experiment on the `asf-staging` branch > >> of `logging-site` repository confused the INFRA and it is acting > >> strangely. This will *NOT* be an issue when we push the website > >> changes to production, i.e., `asf-site` branch. Though we will try > >> fixing `asf-staging` anyway in the meantime. > > On Fri, Oct 13, 2023, at 13:28, Piotr P. Karwasz wrote: > > I think that the problem is that the `asf-staging` branch in > > `logging-site` has switched from a `content` folder to an `output` > > folder, while some of our 6 other site repos have a `content` folder. > > It is fixable, but INFRA offers us an infinite number of > > `logging-.staged.apache.org` domains and I think we should use > > it. > > According to this doc: > > https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features#Git.asf.yamlfeatures-WebsitedeploymentserviceforGitrepositories > > We just have to give it a profile: > > staging: > profile: mystuff > > Would result in: > > logging-mystuff.staged.apache.org > > I can easily migrate to this. > > The folder "output" is the default with ASF infra, but it is possible to > replace it with content: > > jekyll: > whoami: jekyll > target: asf-staging > outputdir: content > > Why is content not causing this issue? > For me both is possible, just trying to understand the best way. > > Kind regards, > Christian >
Re: [log4j] Project URLs per major version
> it [doesn't] fully documents what was in prior releases Why is this a problem? We document newly added features with "starting from version X, Log4j ships Y...". Doesn't this address your concern? Many projects follow this convention, even Java itself: https://docs.oracle.com/en/java/javase/index.html I think we can perfectly make it work for us too. Plus, we provide no public links to previous releases. That is, we provide no links nowhere to `logging.apache.org/log4j/log4j-2.19.0`, hence, it is practically hidden. As a matter of fact the following command returns empty on `asf-site` branch of `logging-log4j-site` repository: find . -type f -not -path "*/.git/*" -and -not -path "*/log4j-2.19.0/*" | grep log4j-2.19.0 This proves we don't link `log4j-2.19.0` anywhere. (Please correct me if I am wrong.) On Mon, Oct 23, 2023 at 10:10 AM Apache wrote: > I am ok with 1 and 2, but not 3. Doing that means older releases web sites > are no longer available. Just because the latest includes release notes for > all versions doesn’t mean it fully documents what was in prior releases. > However, I am not surprised you are suggesting this as I posted in an > earlier email that CI of the web site would be difficult due to this. > > Ralph > > > On Oct 22, 2023, at 2:03 PM, Piotr P. Karwasz > wrote: > > > > Hi Volkan, > > > >> On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı wrote: > >> 3. *Don't create a new folder for every release, but override the > `2.x` > >> folder.* > >> - This is okay, since we keep backward compatibility in minor+patch > >> releases and explicitly provide version for features that are > added later > >> on (e.g., "starting from 2.17.0 Log4j provides X...") > >> - We can set up CI jobs to periodically populate `1.x`, `2.x`, > `3.x`, > >> `4.x`, etc. websites and avoid the need to generate the website > once and > >> for all. > >> - We will stop polluting the folder structure. > > > > +1 on keeping just `1.x`, `2.x`, etc. > > > > We just need to keep in mind that not all public methods have a > > correct `@since` Javadoc tag. We would need to fix that. > > > > Piotr > >
Re: [log4j] Project URLs per major version
I am ok with 1 and 2, but not 3. Doing that means older releases web sites are no longer available. Just because the latest includes release notes for all versions doesn’t mean it fully documents what was in prior releases. However, I am not surprised you are suggesting this as I posted in an earlier email that CI of the web site would be difficult due to this. Ralph > On Oct 22, 2023, at 2:03 PM, Piotr P. Karwasz wrote: > > Hi Volkan, > >> On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı wrote: >> 3. *Don't create a new folder for every release, but override the `2.x` >> folder.* >> - This is okay, since we keep backward compatibility in minor+patch >> releases and explicitly provide version for features that are added >> later >> on (e.g., "starting from 2.17.0 Log4j provides X...") >> - We can set up CI jobs to periodically populate `1.x`, `2.x`, `3.x`, >> `4.x`, etc. websites and avoid the need to generate the website once and >> for all. >> - We will stop polluting the folder structure. > > +1 on keeping just `1.x`, `2.x`, etc. > > We just need to keep in mind that not all public methods have a > correct `@since` Javadoc tag. We would need to fix that. > > Piotr
Re: Staging sites and repo convention
+1 Fix the staging site. Defer talk about anything else until that is done. Ralph > On Oct 22, 2023, at 5:05 PM, Christian Grobmeier wrote: > > > >> On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote: >> It has been a long thread and I want to capture the result: *there are no >> objections to Piotr's proposal, right?* If not, please say so. > > I am not objecting, but I would like to point out that logging.s.a.o is in > bad shape today, and I don't know why (in detail). I'd love to have this > working again before we move on to a different system. > If you know how to fix the system in a way that works with the original > proposal in one go, I am okay with it, too. However, I am afraid we are > touching too many wheels at once and navigating in a bad state. > > > >> >> To avoid misunderstanding, I want to repeat certain points one more time: >> >> 1. All existing logging.apache.org URLs will remain as is – no changes >> there. >> 2. Instead of using logging.*staged.*apache.org*/foo*, we will use >> logging*-foo.staged.*apache.org for staging websites. >> 3. Log4j Scala, Kotlin, Tools, and Transformation website content will >> be moved from `logging-log4j-site` repository to `logging-log4j-scala`, >> `logging-log4j-kotlin`, `logging-log4j-tools`, and >> `logging-log4j-transformation` repositories, respectively. >> >> >> On Thu, Oct 19, 2023 at 10:03 AM Piotr P. Karwasz >> wrote: >> >>> Hi, >>> >>> Since now we have a fast release process It might happen (and it >>> already did) that the voting periods for releases will not be >>> disjoint. >>> >>> That is why I would like to introduce a convention on the procedure to >>> stage websites and Nexus repositories. >>> >>> For websites I would propose: >>> >>> 1. Every Git code repository uses a different staging domain name. >>> E.g. `logging-log4j2` would set: >>> >>> staging: >>> profile: log4j2 >>> >>> which will result in a https://logging-log4j2.staged.apache.org URI. >>> For the `logging-log4j-site` website repo this will also entail that >>> it will have multiple staging branches. >>> 2. The `asf-staging` should not be protected. Before staging a website >>> the Release Manager would perform: >>> >>> git reset --hard origin/asf-site >>> git push -f >>> >>> hence ensuring that moving changes from the staging branch to >>> `asf-site` will be usually a fast-forward and a simple cherry-pick >>> `origin/asf-site..asf-staging` at worst. >>> >>> For the staging Nexus repo I would propose using a comment to close >>> the repo in the format: >>> >>> `` version `` RC1 >>> >>> For example Volkan used "`logging-parent` version `10.2.0` RC`" on the >>> 1204 repo and we can easily guess what that repo contains. ;-) >>> >>> Piotr >>> >>> PS: Maybe we could drop the `*-site` Git repositories except >>> `logging-site` and move their content to an `asf-site/asf-staging` >>> branch of the corresponding code repo. >>>
Re: Staging sites and repo convention
I am not proposing to implement this right now. All I am after is an agreement. Indeed we should pursue this route once staging is back to normal. On Mon, Oct 23, 2023 at 2:05 AM Christian Grobmeier wrote: > > > On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote: > > It has been a long thread and I want to capture the result: *there are no > > objections to Piotr's proposal, right?* If not, please say so. > > I am not objecting, but I would like to point out that logging.s.a.o is in > bad shape today, and I don't know why (in detail). I'd love to have this > working again before we move on to a different system. > If you know how to fix the system in a way that works with the original > proposal in one go, I am okay with it, too. However, I am afraid we are > touching too many wheels at once and navigating in a bad state. > > > > > > > To avoid misunderstanding, I want to repeat certain points one more time: > > > >1. All existing logging.apache.org URLs will remain as is – no > changes > >there. > >2. Instead of using logging.*staged.*apache.org*/foo*, we will use > >logging*-foo.staged.*apache.org for staging websites. > >3. Log4j Scala, Kotlin, Tools, and Transformation website content will > >be moved from `logging-log4j-site` repository to > `logging-log4j-scala`, > >`logging-log4j-kotlin`, `logging-log4j-tools`, and > >`logging-log4j-transformation` repositories, respectively. > > > > > > On Thu, Oct 19, 2023 at 10:03 AM Piotr P. Karwasz < > piotr.karw...@gmail.com> > > wrote: > > > >> Hi, > >> > >> Since now we have a fast release process It might happen (and it > >> already did) that the voting periods for releases will not be > >> disjoint. > >> > >> That is why I would like to introduce a convention on the procedure to > >> stage websites and Nexus repositories. > >> > >> For websites I would propose: > >> > >> 1. Every Git code repository uses a different staging domain name. > >> E.g. `logging-log4j2` would set: > >> > >> staging: > >> profile: log4j2 > >> > >> which will result in a https://logging-log4j2.staged.apache.org URI. > >> For the `logging-log4j-site` website repo this will also entail that > >> it will have multiple staging branches. > >> 2. The `asf-staging` should not be protected. Before staging a website > >> the Release Manager would perform: > >> > >> git reset --hard origin/asf-site > >> git push -f > >> > >> hence ensuring that moving changes from the staging branch to > >> `asf-site` will be usually a fast-forward and a simple cherry-pick > >> `origin/asf-site..asf-staging` at worst. > >> > >> For the staging Nexus repo I would propose using a comment to close > >> the repo in the format: > >> > >> `` version `` RC1 > >> > >> For example Volkan used "`logging-parent` version `10.2.0` RC`" on the > >> 1204 repo and we can easily guess what that repo contains. ;-) > >> > >> Piotr > >> > >> PS: Maybe we could drop the `*-site` Git repositories except > >> `logging-site` and move their content to an `asf-site/asf-staging` > >> branch of the corresponding code repo. > >> >
