Re: Cleanup of `downloads.apache.org`

[Volkan Yazıcı]

On Wed, Nov 13, 2024 at 4:38 PM Piotr P. Karwasz 
wrote:

> 6. Currently we place all sub-projects of Log4j directly in the
> `logging` folder, but `archive.apache.org`[6] shows that it wasn't
> always this way. For example `log4j-scala` used to be in `log4j/scala`.
> Which convention should we use?
>

I am missing the motivation for this question. Is there a problem with
the current convention?

This is introduced to ease the automation of SVN uploads during releases –
otherwise subfolders need to be scanned, checked, etc. This is not trivial
thanks to the simplicity of SVN. Plus, this keeps the folder structure in
line with the repository names. Hence, I suggest not changing this
convention, please.

Cleanup of `downloads.apache.org`

[Piotr P. Karwasz]

Hi all,

Looking at our releases, as the appear on `projects.apache.org`[1], I 
think that it is about time to clean up `downloads.apache.org`. I would 
propose to:


1. Formally vote on the end-of-life of the Apache Extras for Apache 
log4j[2] and Apache log4php[3] projects.


2. Formally vote on the end-of-life of the Log4j 2.3.x[4] and 2.12.x[5] 
branches.


3. Remove all the release files of the distributions that reached 
end-of-life. Users can always find those releases on `archive.apache.org`.


4. Update the websites to clearly mark some projects as EOL or dormant 
with a link to a clear definition of the terms. For me these terms mean:


    End-of-life: There will be no further releases. Security reports 
for those projects/branches will not be accepted and those 
projects/branches will not be checked against vulnerabilities.


    Dormant: Further releases are unlikely, unless users step in. 
Security reports and security releases are handled normally. The project 
can be voted EOL at any time with an X-month notice.


5. We should update our DOAP files. My understanding is that each 
subproject (Apache Log4j Tools, Apache Log4j Transform) should have its 
own DOAP file.


6. Currently we place all sub-projects of Log4j directly in the 
`logging` folder, but `archive.apache.org`[6] shows that it wasn't 
always this way. For example `log4j-scala` used to be in `log4j/scala`. 
Which convention should we use?


Piotr

[1] https://projects.apache.org/releases.html

[2] https://logging.apache.org/log4j/extras/

[3] https://logging.apache.org/log4php/

[4] https://logging.apache.org/log4j/2.3.x/

[5] https://logging.apache.org/log4j/2.12.x/

[6] https://archive.apache.org/dist/logging/

Re: Cleanup of `downloads.apache.org`

[Piotr P. Karwasz]

Hi Volkan,

On 13.11.2024 16:54, Volkan Yazıcı wrote:

On Wed, Nov 13, 2024 at 4:38 PM Piotr P. Karwasz 
wrote:


6. Currently we place all sub-projects of Log4j directly in the
`logging` folder, but `archive.apache.org`[6] shows that it wasn't
always this way. For example `log4j-scala` used to be in `log4j/scala`.
Which convention should we use?


I am missing the motivation for this question. Is there a problem with
the current convention?

This is introduced to ease the automation of SVN uploads during releases –
otherwise subfolders need to be scanned, checked, etc. This is not trivial
thanks to the simplicity of SVN. Plus, this keeps the folder structure in
line with the repository names. Hence, I suggest not changing this
convention, please.


This is more of an observation than a question. I don't have a problem 
with the convention, but let us keep to it for the foreseeable future or 
`archive.apache.org` will become a mess.


Piotr

Re: Cleanup of `downloads.apache.org`

[Ralph Goers]

Log4j 2.3.x and 2.12.x don’t need votes. We declared that we were no longer 
supporting Java 6 and then Java 7 and that those would be the last releases to 
do so. We made an exception for Log4Shell and created patches for both since 
the security exposure was so bad. Those release lines are clearly marked as EOL 
and have been for a long time.

I have no issue with removing anything/everything from downloads.apache.org 
 since they are all available from the archive 
sites. As it is we are encouraged by Infra to ONLY keep the latest release. 
Again, we treated 2.3.x and 2.12.x as special since they were the last versions 
for the target platform. But after all these years I can’t imagine why anyone 
would need to download them.

In the past we always added a banner to each site when it moved to dormant.

Ralph

> On Nov 13, 2024, at 8:14 AM, Piotr P. Karwasz  
> wrote:
> 
> Hi all,
> 
> Looking at our releases, as the appear on `projects.apache.org`[1], I think 
> that it is about time to clean up `downloads.apache.org`. I would propose to:
> 
> 1. Formally vote on the end-of-life of the Apache Extras for Apache log4j[2] 
> and Apache log4php[3] projects.
> 
> 2. Formally vote on the end-of-life of the Log4j 2.3.x[4] and 2.12.x[5] 
> branches.
> 
> 3. Remove all the release files of the distributions that reached 
> end-of-life. Users can always find those releases on `archive.apache.org`.
> 
> 4. Update the websites to clearly mark some projects as EOL or dormant with a 
> link to a clear definition of the terms. For me these terms mean:
> 
> End-of-life: There will be no further releases. Security reports for 
> those projects/branches will not be accepted and those projects/branches will 
> not be checked against vulnerabilities.
> 
> Dormant: Further releases are unlikely, unless users step in. Security 
> reports and security releases are handled normally. The project can be voted 
> EOL at any time with an X-month notice.
> 
> 5. We should update our DOAP files. My understanding is that each subproject 
> (Apache Log4j Tools, Apache Log4j Transform) should have its own DOAP file.
> 
> 6. Currently we place all sub-projects of Log4j directly in the `logging` 
> folder, but `archive.apache.org`[6] shows that it wasn't always this way. For 
> example `log4j-scala` used to be in `log4j/scala`. Which convention should we 
> use?
> 
> Piotr
> 
> [1] https://projects.apache.org/releases.html
> 
> [2] https://logging.apache.org/log4j/extras/
> 
> [3] https://logging.apache.org/log4php/
> 
> [4] https://logging.apache.org/log4j/2.3.x/
> 
> [5] https://logging.apache.org/log4j/2.12.x/
> 
> [6] https://archive.apache.org/dist/logging/
>