Hi Matt,
On Mon, 26 Feb 2024 at 23:08, Matt Sicker wrote:
>
> Must be a relic from when we used Subversion to publish the website instead
> of Git. Maybe ask Infra?
It is done: https://issues.apache.org/jira/browse/INFRA-25550
Piotr
Must be a relic from when we used Subversion to publish the website instead of
Git. Maybe ask Infra?
> On Feb 26, 2024, at 12:05, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On Mon, 26 Feb 2024 at 18:49, Matt Sicker wrote:
>>
>> The /log4j/2.0/ link is because 2.0 is a symbolic link to 2.x, and
Hi Matt,
On Mon, 26 Feb 2024 at 18:49, Matt Sicker wrote:
>
> The /log4j/2.0/ link is because 2.0 is a symbolic link to 2.x, and 2.x is a
> symbolic link to the latest release (or at least that’s how it was set up
> originally). The links can probably use .htaccess rewrite rules instead.
I rea
The /log4j/2.0/ link is because 2.0 is a symbolic link to 2.x, and 2.x is a
symbolic link to the latest release (or at least that’s how it was set up
originally). The links can probably use .htaccess rewrite rules instead.
> On Feb 21, 2024, at 04:44, Piotr P. Karwasz wrote:
>
> Hi,
>
> On Mo
Hi,
On Mon, 19 Feb 2024 at 10:34, Volkan Yazıcı wrote:
>
> If there are no objections, after Log4j `2.23.0` and `3.0.0-beta2`
> releases, I want to proceed with replacing the contents of
> `asf-{site,staging}` branches with `clean-staging`. Effectively, this
> operation has the following outcomes
If there are no objections, after Log4j `2.23.0` and `3.0.0-beta2`
releases, I want to proceed with replacing the contents of
`asf-{site,staging}` branches with `clean-staging`. Effectively, this
operation has the following outcomes:
- The `logging-log4j-site` repository will contain only follo
FWIW I believe that keeping around old sites is useful, but only if
there's a banner that says "this is out of date, please use the newest
version" with a link to the new version. The reason for keeping them
around is that sometimes you are stuck on an older version, so you
need that archived doc
Hi Volkan,
On Wed, 7 Feb 2024 at 11:05, Volkan Yazıcı wrote:
> I can see the use cases for wanting to keep the website+manual of every
> single release in a dedicated directory. Though my counter arguments are:
>
>1. These pages were never officially linked, hence were not exposed to
>use
On Tue, Feb 6, 2024 at 5:46 PM Ralph Goers
wrote:
> When you say “hard to work with it” what does that mean?
Git commands work slow (e.g., `git status` takes seconds) and it is
difficult to understand what goes where.
> Volkan has mentioned some ideas to me which would allow us to keep the
>
+1
Nit: I would use `2.3.x` and `2.12.x` to match the `.x` suffix convention
we use in `1.x`, `2.x`, and `3.x`. Or totally the other way around, no `.x`
suffix at all: `1`, `2`, `2.3`, `2.12`, and `3`.
On Tue, Feb 6, 2024 at 5:06 PM Piotr P. Karwasz
wrote:
> Hi all,
>
> The current `asf-site`
Hi Ralph,
On Tue, 6 Feb 2024 at 17:47, Ralph Goers wrote:
>
> When you say “hard to work with it” what does that mean? All that should ever
> be required is to do
I am mostly concerned by the great amount of files on the website.
Most of them are hidden, since we don't provide links to
`/log4j/
When you say “hard to work with it” what does that mean? All that should ever
be required is to do
git rebase asf-staging
I have never had that take more than a few seconds.
Are you really saying that the staging site is hard to work with? My
understanding is that “we” are working on reworki
12 matches
Mail list logo
