Well this is a case where I could possibly buy into the idea of a worktree under the log4j2 site for each of those sub-projects where what they are publishing is an “overlay” on top of the Logj2 web site. As I recall that is more or less what we are doing with the whole logging site anyway. As I recall everything under content/ ends up being one directory tree, which is why they can share the same url. So simply having the sub-project generate its stuff in the correct content sub-directory should solve that problem.
Ralph > On Oct 19, 2023, at 6:14 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Robert, > > On Thu, 19 Oct 2023 at 14:34, Robert Middleton <rmiddle...@apache.org> wrote: >> >> I'm not quite sure what problems this solves. Are you trying to put >> the site HTML code and the normal code in the same repository? Are >> they just different branches in the same repository? What about the >> currently existing URLs? Would it now be logging-log4j2.logging.a.o >> instead of logging.a.o/log4j2? I ask because we would want to make >> sure that redirects are added to try and avoid link rot. > > I am trying to solve concurrency problems on the staging site. Log4cxx > has its own `logging-log4cxx-site` repo, but most of the Log4j > subprojects share `logging-log4j-site`. > > When we have two concurrent releases (e.g. Scala and Kotlin) and the > vote for one of them passes, the release manager has to look at the > Git log and cherry-pick **only** those commits that concern the > project he is publishing. That is a useless complication. Also the > `asf-staging` branch of `logging-log4j-site` can not be reset, so it > has a tendency to diverge from `asf-site`. > > Of course having each project's site in a different repo would solve this. > > Piotr
