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 c
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" :
"ht
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 ha
> 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`
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/l
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
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 `c
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 libr
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 existi
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.
>
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
=== Releas
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
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
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 wa
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 1
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
> chan
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 o
> 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 s
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
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 s
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
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:
> 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
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
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 UR
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 extraor
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,
>
> O
>> 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
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
`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 singl
Hi Volkan,
On Thu, 19 Oct 2023 at 23:40, Volkan Yazıcı wrote:
>
> 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.
Th
Correct me if I read you wrong: *"you have added a timestamp, so you can
update it to trigger the CI"*. Adding a timestamp creates an RM
responsibility. It adds one extra manual step to the release procedure. And
I am against this. (I think everybody should be against it.) Do you want to
trigger th
32 matches
Mail list logo
