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:
>>
>> `<code-repo-name>` version `<version_number>` 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.
>>
