Re: Staging sites and repo convention

[Volkan Yazıcı]

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: Staging sites and repo convention

[Apache]

+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

[Volkan Yazıcı]

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.
> >>
>

Re: Staging sites and repo convention

[Christian Grobmeier]

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

[Piotr P. Karwasz]

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: Staging sites and repo convention

[Volkan Yazıcı]

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.

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

[Christian Grobmeier]

>> It would mean "use logging.staged.apache.org (the ~), but generate the 
>> content to the subfolder /log4j".
>> I left out the magic /content folder since it was a given. This magic folder 
>> appears to be the problem that I raised with moving the main site to 
>> logging, at least, that's what I understood from infra: because of the bug, 
>> we would generate to /output, which confused the server.
>
> Yes. I can see how this would confuse it. When you changed the main 
> site to use output instead of content you essentially deleted the 
> content directory. So then the sub-project web sites had nowhere to 
> live. We would have had to change all the sub-projects to switch to 
> using output as well to fix it.

Yes, that is what I was told too. Meanwhile, my fix worked and even Jekyll 
works with content now. 
However, the staging server seems to be in a bad "state", that's why I asked 
infra to help and maybe clean it.
Once they do this, everything is back to normal, which is currently my goal. I 
really would love to have a working Jekyll site now, with all the news we have 
coming in.

Piotrs proposal is a different thing to me, and I don't have an opinion about 
this yet. In the end, I agree with you and Piotr as well that we should keep 
the existing URLs for the next 30 years or so

Re: Staging sites and repo convention

[Ralph Goers]

> On Oct 20, 2023, at 1:37 PM, Christian Grobmeier  wrote:
> 
> On Fri, Oct 20, 2023, at 18:43, Ralph Goers wrote:
>> If I am reading this correctly that would mean we want all our projects 
>> to have an empty profile so that they all appear under 
>> logging.staged.apache.org  and 
>> logging.apache.org … ?
> 
> Please take everything cautiously because this knowledge is new to me, and I 
> may make mistakes - but yes, this is correct.
> 
> From the log4j profile (latest commit changed something):
> https://github.com/apache/logging-log4j-site/commit/048bb9983cfb7e8549801c8a491a2adb0a6de433
> 
> It reads:
> 
> staging:
>  profile: ~
>  whoami: asf-staging
>  subdir: content/log4j
> 
> It would mean "use logging.staged.apache.org (the ~), but generate the 
> content to the subfolder /log4j".
> I left out the magic /content folder since it was a given. This magic folder 
> appears to be the problem that I raised with moving the main site to logging, 
> at least, that's what I understood from infra: because of the bug, we would 
> generate to /output, which confused the server.

Yes. I can see how this would confuse it. When you changed the main site to use 
output instead of content you essentially deleted the content directory. So 
then the sub-project web sites had nowhere to live. We would have had to change 
all the sub-projects to switch to using output as well to fix it.

Ralph

Re: Staging sites and repo convention

[Christian Grobmeier]

On Fri, Oct 20, 2023, at 18:43, Ralph Goers wrote:
> If I am reading this correctly that would mean we want all our projects 
> to have an empty profile so that they all appear under 
> logging.staged.apache.org  and 
> logging.apache.org … ?

Please take everything cautiously because this knowledge is new to me, and I 
may make mistakes - but yes, this is correct.

>From the log4j profile (latest commit changed something):
https://github.com/apache/logging-log4j-site/commit/048bb9983cfb7e8549801c8a491a2adb0a6de433

It reads:

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/log4j

It would mean "use logging.staged.apache.org (the ~), but generate the content 
to the subfolder /log4j".
I left out the magic /content folder since it was a given. This magic folder 
appears to be the problem that I raised with moving the main site to logging, 
at least, that's what I understood from infra: because of the bug, we would 
generate to /output, which confused the server.

If you want to maintain flume:

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/flume

The same goes for asf-site, which is then deployed to the public destination.

You can look at the current config on this tool (for production sites only, it 
seems):
https://infra-reports.apache.org/#sitesource

Christian

Re: Staging sites and repo convention

[Ralph Goers]

If I am reading this correctly that would mean we want all our projects to have 
an empty profile so that they all appear under logging.staged.apache.org 
 and logging.apache.org 
… ?

Ralph

> On Oct 20, 2023, at 12:13 AM, Christian Grobmeier  
> wrote:
> 
> On Fri, Oct 20, 2023, at 09:03, Piotr P. Karwasz wrote:
>> On Fri, 20 Oct 2023 at 07:55, Ralph Goers  wrote:
>>> As far as the worktree stuff goes, I’d be in favor of that if it can be 
>>> used to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin 
>>> need to be independently committed and merged, although I have a suspicion 
>>> that the ASF web site support would work better if those were in their own 
>>> repos as I have my doubts they support worktrees.
>> 
>> INFRA does not care about worktrees. Their code is probably something
>> like: if any `logging-*` repo pushed branch 'lala' that contains an
>> `.asf.yaml` file with:
> 
> It matches the repo name to the project, i.e. 
> 
> logging-site -> logging project logging.staged.a.o
> logging-log4j-site -> also logging project, logging.staged.a.o
> 
> With the profiles, you can manage subdomains
> 
> profile: ~ -> logging.s.a.o directly
> profile: main - > logging-main.logging.s.a.o
> 
> 
> 

Re: Staging sites and repo convention

[Christian Grobmeier]

On Fri, Oct 20, 2023, at 09:03, Piotr P. Karwasz wrote:
> On Fri, 20 Oct 2023 at 07:55, Ralph Goers  wrote:
>> As far as the worktree stuff goes, I’d be in favor of that if it can be used 
>> to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need 
>> to be independently committed and merged, although I have a suspicion that 
>> the ASF web site support would work better if those were in their own repos 
>> as I have my doubts they support worktrees.
>
> INFRA does not care about worktrees. Their code is probably something
> like: if any `logging-*` repo pushed branch 'lala' that contains an
> `.asf.yaml` file with:

It matches the repo name to the project, i.e. 

logging-site -> logging project logging.staged.a.o
logging-log4j-site -> also logging project, logging.staged.a.o

With the profiles, you can manage subdomains

profile: ~ -> logging.s.a.o directly
profile: main - > logging-main.logging.s.a.o

Re: Staging sites and repo convention

[Piotr P. Karwasz]

Hi Ralph,

On Fri, 20 Oct 2023 at 07:55, Ralph Goers  wrote:
> As far as the worktree stuff goes, I’d be in favor of that if it can be used 
> to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need to 
> be independently committed and merged, although I have a suspicion that the 
> ASF web site support would work better if those were in their own repos as I 
> have my doubts they support worktrees.

INFRA does not care about worktrees. Their code is probably something
like: if any `logging-*` repo pushed branch 'lala' that contains an
`.asf.yaml` file with:

staging:
  whoami: lala
  subdir: foo/bar/baz

then copy the content of the branch to `foo/bar/baz`.

Locally you can use a worktree. They might use something else, which
would explain why https://logging-log4j.staged.apache.org is still on,
even if it is not supported by any Git branch.

Piotr

Re: Staging sites and repo convention

[Volkan Yazıcı]

`worktree`s is a personal preference, I just shared how easy it would
be to manage sources next to the website *using a single [git] clone*.
Those who want to have multiple clones, can still do so. This has
again nothing to do with Piotr's proposal. Piotr's proposal in essence
is

1. generate single use domains *on staging* while voting a release
2. move the website of each project to the project's source code repository

On Fri, Oct 20, 2023 at 7:55 AM Ralph Goers  wrote:
>
> If the urls are preserved then I would not be -1.
>
> As far as the worktree stuff goes, I’d be in favor of that if it can be used 
> to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need to 
> be independently committed and merged, although I have a suspicion that the 
> ASF web site support would work better if those were in their own repos as I 
> have my doubts they support worktrees.
>
> Ralph
>
> > On Oct 19, 2023, at 4:37 PM, Christian Grobmeier  
> > wrote:
> >
> >
> >>> Why are you pissed? I am sorry if I would be the reason
> >>
> >> 1. I indicated I didn’t want changing to Jekyl to be the reason for
> >> changing to Jekyll. So far, that appears to be the reason. I thought
> >> you mentioned something about getting CI to work but the current
> >> process could have been automated as well.
> >
> > No, that's not the reason. Switching to Jekyll would mean easy updates, 
> > data files, SCSS support.
> >
> >> 2. Switching to Jekyll seems to have changed the target directory with
> >> dire consequences. As I stated, my experience with the ASF “CMS” is
> >> that you can “layer” web sites on top of each other by using sub-dirs
> >> of the content directory. I don’t recall the details as it has been
> >> several years since I migrated the web sites from the old CMS to the
> >> Git tooling provided by infra. But what I did was deliberate and on
> >> purpose.
> >
> > The output directory was changed. I took a lot of time (I am not used to 
> > Python) to send 2 PRs to Infra:
> > https://github.com/apache/infrastructure-p6/pull/1704
> > https://github.com/apache/infrastructure-p6/pull/1700
> > To fix the output directory situation.
> > Both were accepted. The output directory is now working again, as described 
> > in the docs.
> > https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features
> >
> > However, for unknown reasons, the webserver still does not recognize the 
> > fix. That's why I asked for help and eventually created a ticket for Infra 
> > to help return to the old status:
> > https://issues.apache.org/jira/browse/INFRA-25097
> >
> >> 3. The final consequence is that it seems that we must now use
> >> logging-log4j2.staged.apache.org/log4j/2.x
> >> . Since staging is
> >> supposed to exactly match live this means the live url now has to be
> >> logging-log4j2.apache.org/log4j/2.x
> >> . That is unacceptable.
> >
> > I agree this is unacceptable, but it is not the case that we must now use 
> > this.
> >
> > I am working towards using the same system as before, using the same URLs 
> > except, instead of jbake, with Jekyll. I am sorry that I ran into bugs I 
> > could not control, but I am not enforcing or promoting a change of URLs 
> > just because there are bugs.
> >
> > I want it to be "as before". Piotr's proposal contains ideas that have 
> > nothing to do with my tooling change. You could decline it if you wish, 
> > without any effect of the switch to Jekyll.
> >
> > To summarize:
> >
> > - I want to replace jbake with jekyll
> > - I don't want to change anything on the URLs
> > - I run into Infra bugs, that I fixed myself
> > - I now look at a web server mess, that I can't control, and wait for Infra 
> > support
> >
> > Once Infra helps to sort out the webservers, it should be exactly as before.
> >
> > Again, I apologize for opening this discussion, it was not my intent. My 
> > intent was to move to a tool that is easier to use (in my opinion), and 
> > that helps me to promote log4j further. It is not the fault of the tooling 
> > that the web server has that hiccup.
> >
> > I hope you are less pissed now, that you know that we are on the same page. 
> > To be precise, I am pretty much stressed that the docs told me "it would 
> > work" when I had to find out "it doesn't".
> >
> > Kind regards,
> > Christian
>

Re: Staging sites and repo convention

[Ralph Goers]

If the urls are preserved then I would not be -1.  

As far as the worktree stuff goes, I’d be in favor of that if it can be used to 
solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need to be 
independently committed and merged, although I have a suspicion that the ASF 
web site support would work better if those were in their own repos as I have 
my doubts they support worktrees.

Ralph

> On Oct 19, 2023, at 4:37 PM, Christian Grobmeier  wrote:
> 
> 
>>> Why are you pissed? I am sorry if I would be the reason
>> 
>> 1. I indicated I didn’t want changing to Jekyl to be the reason for 
>> changing to Jekyll. So far, that appears to be the reason. I thought 
>> you mentioned something about getting CI to work but the current 
>> process could have been automated as well.
> 
> No, that's not the reason. Switching to Jekyll would mean easy updates, data 
> files, SCSS support.
> 
>> 2. Switching to Jekyll seems to have changed the target directory with 
>> dire consequences. As I stated, my experience with the ASF “CMS” is 
>> that you can “layer” web sites on top of each other by using sub-dirs 
>> of the content directory. I don’t recall the details as it has been 
>> several years since I migrated the web sites from the old CMS to the 
>> Git tooling provided by infra. But what I did was deliberate and on 
>> purpose.
> 
> The output directory was changed. I took a lot of time (I am not used to 
> Python) to send 2 PRs to Infra:
> https://github.com/apache/infrastructure-p6/pull/1704
> https://github.com/apache/infrastructure-p6/pull/1700
> To fix the output directory situation.
> Both were accepted. The output directory is now working again, as described 
> in the docs.
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features
> 
> However, for unknown reasons, the webserver still does not recognize the fix. 
> That's why I asked for help and eventually created a ticket for Infra to help 
> return to the old status:
> https://issues.apache.org/jira/browse/INFRA-25097
> 
>> 3. The final consequence is that it seems that we must now use 
>> logging-log4j2.staged.apache.org/log4j/2.x 
>> . Since staging is 
>> supposed to exactly match live this means the live url now has to be 
>> logging-log4j2.apache.org/log4j/2.x 
>> . That is unacceptable.
> 
> I agree this is unacceptable, but it is not the case that we must now use 
> this. 
> 
> I am working towards using the same system as before, using the same URLs 
> except, instead of jbake, with Jekyll. I am sorry that I ran into bugs I 
> could not control, but I am not enforcing or promoting a change of URLs just 
> because there are bugs.
> 
> I want it to be "as before". Piotr's proposal contains ideas that have 
> nothing to do with my tooling change. You could decline it if you wish, 
> without any effect of the switch to Jekyll.
> 
> To summarize:
> 
> - I want to replace jbake with jekyll
> - I don't want to change anything on the URLs
> - I run into Infra bugs, that I fixed myself
> - I now look at a web server mess, that I can't control, and wait for Infra 
> support
> 
> Once Infra helps to sort out the webservers, it should be exactly as before.
> 
> Again, I apologize for opening this discussion, it was not my intent. My 
> intent was to move to a tool that is easier to use (in my opinion), and that 
> helps me to promote log4j further. It is not the fault of the tooling that 
> the web server has that hiccup.
> 
> I hope you are less pissed now, that you know that we are on the same page. 
> To be precise, I am pretty much stressed that the docs told me "it would 
> work" when I had to find out "it doesn't". 
> 
> Kind regards,
> Christian

Re: Staging sites and repo convention

[Christian Grobmeier]

>> Why are you pissed? I am sorry if I would be the reason
>
> 1. I indicated I didn’t want changing to Jekyl to be the reason for 
> changing to Jekyll. So far, that appears to be the reason. I thought 
> you mentioned something about getting CI to work but the current 
> process could have been automated as well.

No, that's not the reason. Switching to Jekyll would mean easy updates, data 
files, SCSS support.

> 2. Switching to Jekyll seems to have changed the target directory with 
> dire consequences. As I stated, my experience with the ASF “CMS” is 
> that you can “layer” web sites on top of each other by using sub-dirs 
> of the content directory. I don’t recall the details as it has been 
> several years since I migrated the web sites from the old CMS to the 
> Git tooling provided by infra. But what I did was deliberate and on 
> purpose.

The output directory was changed. I took a lot of time (I am not used to 
Python) to send 2 PRs to Infra:
https://github.com/apache/infrastructure-p6/pull/1704
https://github.com/apache/infrastructure-p6/pull/1700
To fix the output directory situation.
Both were accepted. The output directory is now working again, as described in 
the docs.
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features

However, for unknown reasons, the webserver still does not recognize the fix. 
That's why I asked for help and eventually created a ticket for Infra to help 
return to the old status:
https://issues.apache.org/jira/browse/INFRA-25097

> 3. The final consequence is that it seems that we must now use 
> logging-log4j2.staged.apache.org/log4j/2.x 
> . Since staging is 
> supposed to exactly match live this means the live url now has to be 
> logging-log4j2.apache.org/log4j/2.x 
> . That is unacceptable.

I agree this is unacceptable, but it is not the case that we must now use this. 

I am working towards using the same system as before, using the same URLs 
except, instead of jbake, with Jekyll. I am sorry that I ran into bugs I could 
not control, but I am not enforcing or promoting a change of URLs just because 
there are bugs.

I want it to be "as before". Piotr's proposal contains ideas that have nothing 
to do with my tooling change. You could decline it if you wish, without any 
effect of the switch to Jekyll.

To summarize:

 - I want to replace jbake with jekyll
 - I don't want to change anything on the URLs
 - I run into Infra bugs, that I fixed myself
 - I now look at a web server mess, that I can't control, and wait for Infra 
support

Once Infra helps to sort out the webservers, it should be exactly as before.

Again, I apologize for opening this discussion, it was not my intent. My intent 
was to move to a tool that is easier to use (in my opinion), and that helps me 
to promote log4j further. It is not the fault of the tooling that the web 
server has that hiccup.

I hope you are less pissed now, that you know that we are on the same page. To 
be precise, I am pretty much stressed that the docs told me "it would work" 
when I had to find out "it doesn't". 

Kind regards,
Christian

Re: Staging sites and repo convention

[Volkan Yazıcı]

No, Piotr’s proposal has nowhere mention of changing live urls. He only
proposes creating single use staging urls for voting purposes, which
enables various technical conveniences he elaborated.

To avoid confusion, let me repeat: Piotr’s proposal is only concerned of
staging URLs; live/asf-site URLs will stay as is.

On Thu, 19 Oct 2023 at 23:22, Ralph Goers 
wrote:

>
>
> > On Oct 19, 2023, at 1:47 PM, Christian Grobmeier 
> wrote:
> >
> > Hi
> >
> > On Thu, Oct 19, 2023, at 16:31, Ralph Goers wrote:
> >> I am -1 (i.e. - code commit veto) on any code change that causes the
> >> Log4j 2 web site url (https://logging.apache.org/log4j/2.x/) to no
> >> longer work.
> >> Since the staging site is a prelude to the live site I have to assume
> >> this change will cause the main site url to change so I am -1.
> >>
> >> To be honest I am a little pissed. This all came about because
> >> Christian wanted to switch to Jekyll [...]
> >
> > Why are you pissed? I am sorry if I would be the reason
>
> 1. I indicated I didn’t want changing to Jekyl to be the reason for
> changing to Jekyll. So far, that appears to be the reason. I thought you
> mentioned something about getting CI to work but the current process could
> have been automated as well.
> 2. Switching to Jekyll seems to have changed the target directory with
> dire consequences. As I stated, my experience with the ASF “CMS” is that
> you can “layer” web sites on top of each other by using sub-dirs of the
> content directory. I don’t recall the details as it has been several years
> since I migrated the web sites from the old CMS to the Git tooling provided
> by infra. But what I did was deliberate and on purpose.
> 3. The final consequence is that it seems that we must now use
> logging-log4j2.staged.apache.org/log4j/2.x <
> http://logging-log4j2.staged.apache.org/log4j/2.x>. Since staging is
> supposed to exactly match live this means the live url now has to be
> logging-log4j2.apache.org/log4j/2.x <
> http://logging-log4j2.apache.org/log4j/2.x>. That is unacceptable.
>
> Ralph

Re: Staging sites and repo convention

[Ralph Goers]

> On Oct 19, 2023, at 1:47 PM, Christian Grobmeier  wrote:
> 
> Hi
> 
> On Thu, Oct 19, 2023, at 16:31, Ralph Goers wrote:
>> I am -1 (i.e. - code commit veto) on any code change that causes the 
>> Log4j 2 web site url (https://logging.apache.org/log4j/2.x/) to no 
>> longer work.
>> Since the staging site is a prelude to the live site I have to assume 
>> this change will cause the main site url to change so I am -1.
>> 
>> To be honest I am a little pissed. This all came about because 
>> Christian wanted to switch to Jekyll [...]
> 
> Why are you pissed? I am sorry if I would be the reason

1. I indicated I didn’t want changing to Jekyl to be the reason for changing to 
Jekyll. So far, that appears to be the reason. I thought you mentioned 
something about getting CI to work but the current process could have been 
automated as well.
2. Switching to Jekyll seems to have changed the target directory with dire 
consequences. As I stated, my experience with the ASF “CMS” is that you can 
“layer” web sites on top of each other by using sub-dirs of the content 
directory. I don’t recall the details as it has been several years since I 
migrated the web sites from the old CMS to the Git tooling provided by infra. 
But what I did was deliberate and on purpose.
3. The final consequence is that it seems that we must now use 
logging-log4j2.staged.apache.org/log4j/2.x 
. Since staging is supposed 
to exactly match live this means the live url now has to be 
logging-log4j2.apache.org/log4j/2.x 
. That is unacceptable.

Ralph

Re: Staging sites and repo convention

[Christian Grobmeier]

Hi

On Thu, Oct 19, 2023, at 16:31, Ralph Goers wrote:
> I am -1 (i.e. - code commit veto) on any code change that causes the 
> Log4j 2 web site url (https://logging.apache.org/log4j/2.x/) to no 
> longer work.
> Since the staging site is a prelude to the live site I have to assume 
> this change will cause the main site url to change so I am -1.
>
> To be honest I am a little pissed. This all came about because 
> Christian wanted to switch to Jekyll [...]

Why are you pissed? I am sorry if I would be the reason

Re: Staging sites and repo convention

[Christian Grobmeier]

On Thu, Oct 19, 2023, at 19:38, Matt Sicker wrote:
> If this is only for staging URLs and doesn’t break the production URLs, 
> this sounds reasonable.

+1

Actually, I would love to have staging sorted out first. Once it works as we 
are used to, I am open to anything.


>
> And the git worktree stuff is new to me!
>
>> On Oct 19, 2023, at 3: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

[Matt Sicker]

If this is only for staging URLs and doesn’t break the production URLs, this 
sounds reasonable.

And the git worktree stuff is new to me!

> On Oct 19, 2023, at 3: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

[Ralph Goers]

> On Oct 19, 2023, at 7:48 AM, Piotr P. Karwasz  wrote:
> 
> Hi Ralph,
> 
> On Thu, 19 Oct 2023 at 16:31, Ralph Goers  wrote:
>> I am -1 (i.e. - code commit veto) on any code change that causes the Log4j 2 
>> web site url (https://logging.apache.org/log4j/2.x/) to no longer work.
>> Since the staging site is a prelude to the live site I have to assume this 
>> change will cause the main site url to change so I am -1.
> 
> I am a big believer in "URLs are forever". If the public website URL
> were to change, I would vote -10.
> 
>> Frankly I have no idea why you would want to have the working tree of 
>> asf-site. The only thing that should ever be done in the branch is a merge 
>> from asf-staging.
> 
> That is the point: with `logging-log4j-site` you **can't** do a `git
> merge asf-staging`, because we might have several votes open and
> **only** one of the Scala, Kotlin, Log4j websites can be published.

See my other email…

> 
>> As for closing the Nexus repo I always just used something like “Log4j 
>> 2.x.y-rc1”. I am not sure why this is all that important to standardize as 
>> long as it is clear what the release candidate is. IOW, I would be ok with 
>> your proposal but would also be ok with a policy that says the comment has 
>> to identify the rc version.
> 
> It is not important to standardize, as long as we know what the repo
> contains, without looking into it. I happened to see 2 open and 2
> closed repos with no idea what they contain.

Yeah - I am sure I didn’t spell that out in the release page in confluence. It 
just seemed sort of obvious.

Ralph

Re: Staging sites and repo convention

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 19 Oct 2023 at 16:31, Ralph Goers  wrote:
> I am -1 (i.e. - code commit veto) on any code change that causes the Log4j 2 
> web site url (https://logging.apache.org/log4j/2.x/) to no longer work.
> Since the staging site is a prelude to the live site I have to assume this 
> change will cause the main site url to change so I am -1.

I am a big believer in "URLs are forever". If the public website URL
were to change, I would vote -10.

> Frankly I have no idea why you would want to have the working tree of 
> asf-site. The only thing that should ever be done in the branch is a merge 
> from asf-staging.

That is the point: with `logging-log4j-site` you **can't** do a `git
merge asf-staging`, because we might have several votes open and
**only** one of the Scala, Kotlin, Log4j websites can be published.

> As for closing the Nexus repo I always just used something like “Log4j 
> 2.x.y-rc1”. I am not sure why this is all that important to standardize as 
> long as it is clear what the release candidate is. IOW, I would be ok with 
> your proposal but would also be ok with a policy that says the comment has to 
> identify the rc version.

It is not important to standardize, as long as we know what the repo
contains, without looking into it. I happened to see 2 open and 2
closed repos with no idea what they contain.

Piotr

Re: Staging sites and repo convention

[Ralph Goers]

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  wrote:
> 
> Hi Robert,
> 
> On Thu, 19 Oct 2023 at 14:34, Robert Middleton  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

Re: Staging sites and repo convention

[Ralph Goers]

I am -1 (i.e. - code commit veto) on any code change that causes the Log4j 2 
web site url (https://logging.apache.org/log4j/2.x/) to no longer work.
Since the staging site is a prelude to the live site I have to assume this 
change will cause the main site url to change so I am -1.

To be honest I am a little pissed. This all came about because Christian wanted 
to switch to Jekyll to which I have yet to understand any tangible benefit 
except he understands it better. The claim that It enables automatically 
pushing the site via CI is equally true for the current process. However, it 
will never be true for the Log4j web site since every release is located in its 
own subdirectory of the web site.

As for dropping the -site repos I would need to see documentation on how I can 
have a window open in IntelliJ for the site vs the code. If all the IDEs 
support it then I would probably end up a +0 on it. To be honest I don’t see how

git clone --bare g...@github.com 
:apache/logging-log4j2.git
cd logging-log4j2.git
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git worktree add ../logging-log4j2-2.x 2.x
git worktree add ../logging-log4j2-main main
git worktree add ../logging-log4j2-web-stg asf-staging
git worktree add ../logging-log4j2-web-pro asf-site

is simpler than
git clone g...@github.com :apache/logging-log4j2.git 2.x
git clone -b main g...@github.com 
:apache/logging-log4j2.git main
git clone g...@github.com 
:apache/logging-log4j2-site.git

Frankly I have no idea why you would want to have the working tree of asf-site. 
The only thing that should ever be done in the branch is a merge from 
asf-staging.

I would also want to know how widespread doing this is. Will users get confused 
when we tell them they have to use a worktree? To be honest I’ve never used 
this before nor I have ever seen it used by anyone. That doesn’t mean it isn’t 
happening.

As for closing the Nexus repo I always just used something like “Log4j 
2.x.y-rc1”. I am not sure why this is all that important to standardize as long 
as it is clear what the release candidate is. IOW, I would be ok with your 
proposal but would also be ok with a policy that says the comment has to 
identify the rc version.

Ralph

> On Oct 19, 2023, at 1: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

[Piotr P. Karwasz]

Hi Robert,

On Thu, 19 Oct 2023 at 14:34, Robert Middleton  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

Re: Staging sites and repo convention

[Robert Middleton]

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.

-Robert Middleton

On Thu, Oct 19, 2023 at 6:05 AM Volkan Yazıcı  wrote:
>
> > Every Git code repository uses a different staging domain name
>
> +1
>
> > The `asf-staging` should not be protected [so that CI/RM can force push]
>
> +1
>
> > For the staging Nexus repo I would propose using a comment to close
>
> +1
>
> > Maybe we could drop the `*-site` Git repositories except `logging-site`
>
> +999
>
> Currently `logging-log4j-site` repository hosts the website for Log4j,
> Log4j Tools, Log4j Transformation, Log4j Scala, and Log4j Kotlin, even
> though these projects are all located in individual repositories. I
> cannot express how awesome it would be to move their website content
> to their own repositories, next to their code, where they belong. In
> combination with git worktrees, it will be a breeze to work in such a
> structure:
>
> git clone --bare g...@github.com:apache/logging-log4j2.git
> cd logging-log4j2.git
> git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
> git worktree add ../logging-log4j2-2.x 2.x
> git worktree add ../logging-log4j2-main main
> git worktree add ../logging-log4j2-web-stg asf-staging
> git worktree add ../logging-log4j2-web-pro asf-site
>
> Plain beauty!
>
> 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

[Volkan Yazıcı]

> Every Git code repository uses a different staging domain name

+1

> The `asf-staging` should not be protected [so that CI/RM can force push]

+1

> For the staging Nexus repo I would propose using a comment to close

+1

> Maybe we could drop the `*-site` Git repositories except `logging-site`

+999

Currently `logging-log4j-site` repository hosts the website for Log4j,
Log4j Tools, Log4j Transformation, Log4j Scala, and Log4j Kotlin, even
though these projects are all located in individual repositories. I
cannot express how awesome it would be to move their website content
to their own repositories, next to their code, where they belong. In
combination with git worktrees, it will be a breeze to work in such a
structure:

git clone --bare g...@github.com:apache/logging-log4j2.git
cd logging-log4j2.git
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git worktree add ../logging-log4j2-2.x 2.x
git worktree add ../logging-log4j2-main main
git worktree add ../logging-log4j2-web-stg asf-staging
git worktree add ../logging-log4j2-web-pro asf-site

Plain beauty!

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.

Staging sites and repo convention

[Piotr P. Karwasz]

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.