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: [logging-log4j-jmx-gui] branch release/2.21.1 updated: Bump timestamp

[Volkan Yazıcı]

We shouldn’t manually provide a value each time. If you are adamant about
it, we should ideally pass it from command line in CI workflow. But again,
not manually please. This undermines our objective of relieving RM’s load.

On Thu, 19 Oct 2023 at 23:33, Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Thu, 19 Oct 2023 at 23:20, Volkan Yazıcı  wrote:
> >
> > Piotr, why do we need this? We already inherit a valid value from
> parent’s
> > parent, i.e., ‘org.apache:apache’.
>
> We don't, but the build didn't start without a change.
> On the other hand we should use a realistic value, not whatever
> `org.apache:apache` gives us.
>

Re: [VOTE][LAZY] Release Apache Logging Parent 10.2.0

[Volkan Yazıcı]

Will do 72 hours next time.

On Thu, 19 Oct 2023 at 16:41, Ralph Goers 
wrote:

> I am confused. I thought even lazy consensus votes needed to stay open for
> 72 hours so people still have time to look at them if they want to. I
> personally do not like limiting a vote to 24 hours except in extraordinary
> circumstances (i.e.critical security fixes).
>
> Ralph
>
> > On Oct 18, 2023, at 12:54 PM, Volkan Yazıcı  wrote:
> >
> > This is a lazy-vote to release the Apache Logging Parent 10.2.0.
> >
> > Website: https://logging-parent.staged.apache.org/logging-parent
> > GitHub: https://github.com/apache/logging-parent
> > Commit: 13ee5ca880ef515b69fb1fc6b5fe2e1807e48be6
> > Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> > Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1204
> > 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 24 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.
> >
> > === Release Notes
> >
> > This minor release contains several small improvements.
> >
> >  Added
> >
> > * Added support for auto-generating CycloneDX Software Bill of Materials
> (SBOM)
> >
> >  Changed
> >
> > * Add a compulsory `bnd-baseline-maven-plugin` execution to check for
> > breaking API changes
> > * Apply the default `bnd-maven-plugin` configuration to all the plugin's
> goals
> > * Moves `.flattened-pom.xml` to the same directory as `pom.xml` to
> > preserve the relative parent path. This requires adding
> > `.flattened-pom.xml` to the `.gitignore` file of the repository.
> > * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
> > version `0.5.0`
> > * Update `log4j-changelog` XSD (used for validating changelog entries)
> > to version `0.1.2`
> > * Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.0`
> (#44)
> >
> >  Fixed
> >
> > * Prioritize definitions in `bnd-extra-*` variables over those inherited
> (#39)
> > * Keep parent in `flatten-bom` configuration (#37)
> > * Remove `build` in `flatten-bom` configuration
> > * Fixed the archiving of symbolically linked directories in the
> > `distribution` Maven profile (#43)
> > * Used specific execution IDs in ``defaultGoal``s to avoid running
> > unwanted plugins
>
>

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: [logging-log4j-jmx-gui] branch release/2.21.1 updated: Bump timestamp

[Piotr P. Karwasz]

Hi Volkan,

On Thu, 19 Oct 2023 at 23:20, Volkan Yazıcı  wrote:
>
> Piotr, why do we need this? We already inherit a valid value from parent’s
> parent, i.e., ‘org.apache:apache’.

We don't, but the build didn't start without a change.
On the other hand we should use a realistic value, not whatever
`org.apache:apache` gives us.

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: [logging-log4j-jmx-gui] branch release/2.21.1 updated: Bump timestamp

[Volkan Yazıcı]

Piotr, why do we need this? We already inherit a valid value from parent’s
parent, i.e., ‘org.apache:apache’.


On Thu, 19 Oct 2023 at 19:35,  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> pkarwasz pushed a commit to branch release/2.21.1
> in repository
> https://gitbox.apache.org/repos/asf/logging-log4j-jmx-gui.git
>
>
> The following commit(s) were added to refs/heads/release/2.21.1 by this
> push:
>  new 732aa98  Bump timestamp
> 732aa98 is described below
>
> commit 732aa9821bc6706cc21f4e15724207897e7f56b7
> Author: Piotr P. Karwasz 
> AuthorDate: Tue Oct 17 18:30:53 2023 +0200
>
> Bump timestamp
> ---
>  pom.xml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/pom.xml b/pom.xml
> index cd5b60d..bc01d6c 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -131,6 +131,9 @@
>
>
>
> +
> +
> 2023-10-20T18:29:45+02:00
> +
>  
>  2.21.1-SNAPSHOT
>
>
>

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: [VOTE][LAZY] Release Apache Logging Parent 10.2.0

[Gary Gregory]

FWIW, the normal way to proceed is 72 hours but can be reduced, usually for
security issues. There is no rush IMO, especially for a normal release,
time zones and do on.

Gary


On Thu, Oct 19, 2023, 10:40 AM Ralph Goers 
wrote:

> I am confused. I thought even lazy consensus votes needed to stay open for
> 72 hours so people still have time to look at them if they want to. I
> personally do not like limiting a vote to 24 hours except in extraordinary
> circumstances (i.e.critical security fixes).
>
> Ralph
>
> > On Oct 18, 2023, at 12:54 PM, Volkan Yazıcı  wrote:
> >
> > This is a lazy-vote to release the Apache Logging Parent 10.2.0.
> >
> > Website: https://logging-parent.staged.apache.org/logging-parent
> > GitHub: https://github.com/apache/logging-parent
> > Commit: 13ee5ca880ef515b69fb1fc6b5fe2e1807e48be6
> > Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> > Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1204
> > 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 24 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.
> >
> > === Release Notes
> >
> > This minor release contains several small improvements.
> >
> >  Added
> >
> > * Added support for auto-generating CycloneDX Software Bill of Materials
> (SBOM)
> >
> >  Changed
> >
> > * Add a compulsory `bnd-baseline-maven-plugin` execution to check for
> > breaking API changes
> > * Apply the default `bnd-maven-plugin` configuration to all the plugin's
> goals
> > * Moves `.flattened-pom.xml` to the same directory as `pom.xml` to
> > preserve the relative parent path. This requires adding
> > `.flattened-pom.xml` to the `.gitignore` file of the repository.
> > * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
> > version `0.5.0`
> > * Update `log4j-changelog` XSD (used for validating changelog entries)
> > to version `0.1.2`
> > * Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.0`
> (#44)
> >
> >  Fixed
> >
> > * Prioritize definitions in `bnd-extra-*` variables over those inherited
> (#39)
> > * Keep parent in `flatten-bom` configuration (#37)
> > * Remove `build` in `flatten-bom` configuration
> > * Fixed the archiving of symbolically linked directories in the
> > `distribution` Maven profile (#43)
> > * Used specific execution IDs in ``defaultGoal``s to avoid running
> > unwanted plugins
>
>

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: [VOTE][LAZY] Release Apache Logging Parent 10.2.0

[Ralph Goers]

I am confused. I thought even lazy consensus votes needed to stay open for 72 
hours so people still have time to look at them if they want to. I personally 
do not like limiting a vote to 24 hours except in extraordinary circumstances 
(i.e.critical security fixes).

Ralph

> On Oct 18, 2023, at 12:54 PM, Volkan Yazıcı  wrote:
> 
> This is a lazy-vote to release the Apache Logging Parent 10.2.0.
> 
> Website: https://logging-parent.staged.apache.org/logging-parent
> GitHub: https://github.com/apache/logging-parent
> Commit: 13ee5ca880ef515b69fb1fc6b5fe2e1807e48be6
> Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1204
> 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 24 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.
> 
> === Release Notes
> 
> This minor release contains several small improvements.
> 
>  Added
> 
> * Added support for auto-generating CycloneDX Software Bill of Materials 
> (SBOM)
> 
>  Changed
> 
> * Add a compulsory `bnd-baseline-maven-plugin` execution to check for
> breaking API changes
> * Apply the default `bnd-maven-plugin` configuration to all the plugin's goals
> * Moves `.flattened-pom.xml` to the same directory as `pom.xml` to
> preserve the relative parent path. This requires adding
> `.flattened-pom.xml` to the `.gitignore` file of the repository.
> * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
> version `0.5.0`
> * Update `log4j-changelog` XSD (used for validating changelog entries)
> to version `0.1.2`
> * Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.0` (#44)
> 
>  Fixed
> 
> * Prioritize definitions in `bnd-extra-*` variables over those inherited (#39)
> * Keep parent in `flatten-bom` configuration (#37)
> * Remove `build` in `flatten-bom` configuration
> * Fixed the archiving of symbolically linked directories in the
> `distribution` Maven profile (#43)
> * Used specific execution IDs in ``defaultGoal``s to avoid running
> unwanted plugins

Re: Information regarding log4j-audit-api 1.0.1

[Ralph Goers]

I will beginning the work to upgrade that this weekend.

Ralph

> On Oct 19, 2023, at 6:02 AM, Shiplu Kundu  wrote:
> 
> Hi Team,
> 
> For my current project I was using* log4j-audit-api* to print the audit log
> of my application .
> But the latest version for this plugin 1.0.1 and last release was on 2018
> June, and also it is showing around 75 vulnerabilities.
> I searched over the internet but didn't receive any latest library info for
> the same dependency.
> 
> Can you please suggest to me do you have the latest library for this, or
> any similar library.
> 
> Thanks
> Shiplu Kundu

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.

[ANNOUNCE] Apache Logging Parent 10.2.0 released

[Volkan Yazıcı]

Apache Logging Parent team is pleased to announce the 10.2.0
release. This project contains the parent POM for other Maven-based
Apache Logging Services projects. For further information (support,
download, etc.) see the project website[1].

[1] https://logging.apache.org/logging-parent

=== Release Notes

This minor release contains several small improvements.

 Added

* Added support for auto-generating CycloneDX Software Bill of Materials (SBOM)

 Changed

* Add a compulsory `bnd-baseline-maven-plugin` execution to check for
breaking API changes
* Apply the default `bnd-maven-plugin` configuration to all the plugin's goals
* Moves `.flattened-pom.xml` to the same directory as `pom.xml` to
preserve the relative parent path. This requires adding
`.flattened-pom.xml` to the `.gitignore` file of the repository.
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
version `0.5.0`
* Update `log4j-changelog` XSD (used for validating changelog entries)
to version `0.1.2`
* Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.0` (#44)

 Fixed

* Prioritize definitions in `bnd-extra-*` variables over those inherited (#39)
* Keep parent in `flatten-bom` configuration (#37)
* Remove `build` in `flatten-bom` configuration
* Fixed the archiving of symbolically linked directories in the
`distribution` Maven profile (#43)
* Used specific execution IDs in `defaultGoal`s to avoid running
unwanted plugins

Re: Information regarding log4j-audit-api 1.0.1

[Piotr P. Karwasz]

Hi Shiplu,

On Thu, 19 Oct 2023 at 15:09, Shiplu Kundu  wrote:
> For my current project I was using* log4j-audit-api* to print the audit log
> of my application .
> But the latest version for this plugin 1.0.1 and last release was on 2018
> June, and also it is showing around 75 vulnerabilities.
> I searched over the internet but didn't receive any latest library info for
> the same dependency.

We have been discussing the fate of Log4j Audit for the past month.
There are multiple threads about it:

https://lists.apache.org/thread/gy8j0tgjk6d5njvpm7gy58d2lvwj5s0c
https://lists.apache.org/thread/5x3g3ko0bb3x19d36oyx1b5tvkb7zq0x
https://lists.apache.org/thread/xgd8oxcogdn7t80hccwyzbtz6kvzpt0y

I believe that your e-mail on this matter represents a turning point
in the discussion: we were not sure if Log4j Audit had some user base.
Now that we know it does, we'll try to divert some effort to this project.

Our resources are limited, so we would be grateful for all the help we
can get (issue reports, PRs). Event if Log4j Audit dependencies
**have** multiple CVEs, I don't believe they constitute a problem for
users, which can always overwrite the proposed dependency versions.
Anyway we'll try to update them ourselves and publish a release.

Piotr

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

Information regarding log4j-audit-api 1.0.1

[Shiplu Kundu]

Hi Team,

For my current project I was using* log4j-audit-api* to print the audit log
of my application .
But the latest version for this plugin 1.0.1 and last release was on 2018
June, and also it is showing around 75 vulnerabilities.
I searched over the internet but didn't receive any latest library info for
the same dependency.

Can you please suggest to me do you have the latest library for this, or
any similar library.

Thanks
Shiplu Kundu

Re: SBOM (was: [VOTE][LAZY] Release Apache Logging Parent 10.2.0)

[Volkan Yazıcı]

It took me a while to do the research.
But I have some answers!
[See my comments below.]

> {
>   "type" : "distribution",
> "url" : "
https://repository.apache.org/service/local/staging/deploy/maven2;
> },
>
> This is a private URL for staging a release.

Below is the relevant excerpt from `cyclonedx-maven-plugin`:

if (project.getDistributionManagement() != null) {
addExternalReference(ExternalReference.Type.DISTRIBUTION,
project.getDistributionManagement().getDownloadUrl(), component);
if (project.getDistributionManagement().getRepository() != null) {
addExternalReference(ExternalReference.Type.DISTRIBUTION,
project.getDistributionManagement().getRepository().getUrl(), component);
}
}

Guess what we inherit from `org.apache:apache` POM in the
`distributionManagement` element?


  
...
${distMgmtReleasesUrl}
  
  ...



  ...
  
https://repository.apache.org/service/local/staging/deploy/maven2


We can override
`distributionManagement.repository[id="apache.releases.https"].url` at
use-site, i.e., the root `pom.xml` of `logging-log4j2`,
`logging-log4j-tools`, etc. It'd indeed be nice to fix this for
`logging-parent` version `10.2.0`, though I don't find it a show stopper.

The question is which URL shall this point to?

   1. Nexus? Though it is not an official ASF distribution channel.
   2. ASF Distribution directory (e.g., `
   https://downloads.apache.org/logging/logging-parent`)
   3. The distribution page (e.g., `
   https://logging.apache.org/logging-parent/latest/#distribution`)

I am in favor of the last one. Since this elaborates on all distribution
channels in detail.

> We probably also need to fill in other keys in the SBOM:

As far as I can read from sources, custom "keys" (i.e., "external
references") are not supported by `cyclonedx-maven-plugin`. I am
double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin`
maintainer) as we speak. I might create a ticket (maybe even along with a
PR) depending on the outcome.


On Thu, Oct 19, 2023 at 11:39 AM Volkan Yazıcı  wrote:

> Those are all good points Piotr. Thanks for raising them.
>
> Some of the settings you shared can be fixed for all projects, hence
> in `logging-parent` configuration. This will necessitate either a
> `10.2.0` RC2 or `10.2.1`.
>
> The others need to be addressed per project, which I will implement
> once we have a `logging-parent` release with `cyclonedx-maven-plugin`.
>
> In conclusion, I am on it.
>
> On Thu, Oct 19, 2023 at 10:18 AM Piotr P. Karwasz
>  wrote:
> >
> > Hi Volkan,
> >
> > On Wed, 18 Oct 2023 at 21:55, Volkan Yazıcı  wrote:
> > > * Added support for auto-generating CycloneDX Software Bill of
> Materials (SBOM)
> >
> > Looking at the generated `bom.json`, it gives a strange URL for the
> > distribution:
> >
> > {
> >   "type" : "distribution",
> >   "url" :
> > "https://repository.apache.org/service/local/staging/deploy/maven2;
> > },
> >
> > This is a private URL for staging a release. I would expect this key to
> contain:
> >
> > https://repository.apache.org/content/repositories/releases/
> >
> > We probably also need to fill in other keys in the SBOM:
> >
> > https://cyclonedx.org/docs/1.5/json/#externalReferences_items_type
> >
> > (I use the version 1.5 schema, since it is commented, while 1.4 isn't).
> >
> > The keys that would be useful to fill IMHO are:
> >
> > * `advisories`, pointing to a common page with all the CVE we
> > published against all our products,
> > * `release-notes`, `documentation` and `support`,
> > * `license` (for completeness, it is already defined elsewhere),
> > * `security-contact`, `vulnerability-assertion` and
> > `exploitability-statement`.  The latter could use the exploitability
> > assessments we provide in Github (twice, for Dependabot and OSV
> > scanner):
> >
> https://github.com/apache/logging-log4j2/blob/2.x/log4j-parent/osv-scanner.toml
> > * `static-analisys-report`: both CodeQL and Scorecard can produce a
> > SARIF file. The latter even uploads it somewhere.
> >
> > Piotr
>

Re: SBOM (was: [VOTE][LAZY] Release Apache Logging Parent 10.2.0)

[Piotr P. Karwasz]

Hi Volkan,

On Thu, 19 Oct 2023 at 11:42, Volkan Yazıcı  wrote:
> Some of the settings you shared can be fixed for all projects, hence
> in `logging-parent` configuration. This will necessitate either a
> `10.2.0` RC2 or `10.2.1`.

I would prefer `10.2.1`. Let us publish `logging-parent`, find out all
or most things that we are missing in SBOM and release
`logging-parent` again.

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.

Re: SBOM (was: [VOTE][LAZY] Release Apache Logging Parent 10.2.0)

[Volkan Yazıcı]

Those are all good points Piotr. Thanks for raising them.

Some of the settings you shared can be fixed for all projects, hence
in `logging-parent` configuration. This will necessitate either a
`10.2.0` RC2 or `10.2.1`.

The others need to be addressed per project, which I will implement
once we have a `logging-parent` release with `cyclonedx-maven-plugin`.

In conclusion, I am on it.

On Thu, Oct 19, 2023 at 10:18 AM Piotr P. Karwasz
 wrote:
>
> Hi Volkan,
>
> On Wed, 18 Oct 2023 at 21:55, Volkan Yazıcı  wrote:
> > * Added support for auto-generating CycloneDX Software Bill of Materials 
> > (SBOM)
>
> Looking at the generated `bom.json`, it gives a strange URL for the
> distribution:
>
> {
>   "type" : "distribution",
>   "url" :
> "https://repository.apache.org/service/local/staging/deploy/maven2;
> },
>
> This is a private URL for staging a release. I would expect this key to 
> contain:
>
> https://repository.apache.org/content/repositories/releases/
>
> We probably also need to fill in other keys in the SBOM:
>
> https://cyclonedx.org/docs/1.5/json/#externalReferences_items_type
>
> (I use the version 1.5 schema, since it is commented, while 1.4 isn't).
>
> The keys that would be useful to fill IMHO are:
>
> * `advisories`, pointing to a common page with all the CVE we
> published against all our products,
> * `release-notes`, `documentation` and `support`,
> * `license` (for completeness, it is already defined elsewhere),
> * `security-contact`, `vulnerability-assertion` and
> `exploitability-statement`.  The latter could use the exploitability
> assessments we provide in Github (twice, for Dependabot and OSV
> scanner):
> https://github.com/apache/logging-log4j2/blob/2.x/log4j-parent/osv-scanner.toml
> * `static-analisys-report`: both CodeQL and Scorecard can produce a
> SARIF file. The latter even uploads it somewhere.
>
> Piotr

SBOM (was: [VOTE][LAZY] Release Apache Logging Parent 10.2.0)

[Piotr P. Karwasz]

Hi Volkan,

On Wed, 18 Oct 2023 at 21:55, Volkan Yazıcı  wrote:
> * Added support for auto-generating CycloneDX Software Bill of Materials 
> (SBOM)

Looking at the generated `bom.json`, it gives a strange URL for the
distribution:

{
  "type" : "distribution",
  "url" :
"https://repository.apache.org/service/local/staging/deploy/maven2;
},

This is a private URL for staging a release. I would expect this key to contain:

https://repository.apache.org/content/repositories/releases/

We probably also need to fill in other keys in the SBOM:

https://cyclonedx.org/docs/1.5/json/#externalReferences_items_type

(I use the version 1.5 schema, since it is commented, while 1.4 isn't).

The keys that would be useful to fill IMHO are:

* `advisories`, pointing to a common page with all the CVE we
published against all our products,
* `release-notes`, `documentation` and `support`,
* `license` (for completeness, it is already defined elsewhere),
* `security-contact`, `vulnerability-assertion` and
`exploitability-statement`.  The latter could use the exploitability
assessments we provide in Github (twice, for Dependabot and OSV
scanner):
https://github.com/apache/logging-log4j2/blob/2.x/log4j-parent/osv-scanner.toml
* `static-analisys-report`: both CodeQL and Scorecard can produce a
SARIF file. The latter even uploads it somewhere.

Piotr

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.