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

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

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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.

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

> 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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

`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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

> 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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

> 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

Re: Staging sites and repo convention

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 >

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Re: Staging sites and repo convention

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

Staging sites and repo convention

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