I love this idea, Volkan!
> On Jan 15, 2024, at 3:40 AM, Volkan Yazıcı <vol...@yazi.ci> wrote:
>
> -1 on merging multiple websites to a single repository.
>
> I think documentation should reside in the same repository where sources
> are. I already implemented this for *almost* every repository:
>
> logging-parent
> logging-log4j-tools
> logging-log4j-transform
> logging-log4j-kotlin
> logging-log4j-scala
> logging-log4j-jakarta
>
> There is only one left to migrate to this scheme: `logging-log4j2`, which I
> intend to do on February 9 during STF MS12. `logging-site`, `cyclonedx`,
> `activity-monitor` are exceptions, since they are only websites, not source
> code repositories. Hence, your statement of *"the way our website is
> created from multiple repos and branches is somehow incoherent"* is untrue.
>
> Using *"site next to sources"* scheme, when one checks out a repository, it
> is crystal clear what goes where:
>
> - the `asf-site` branch for `logging.apache.org`
> - the `asf-staging` branch for `logging.staged.apache.org`
> - the rest of the branches for the source code
>
> This scheme would enable many benefits:
>
> 1. Contributors, maintainers, users, etc. can easily locate the site and
> submit changes with zero a priori knowledge. Cloned the sources? Ready to
> go.
> 2. Since all Maven-based projects would be sharing the same site scheme,
> we can automate the website publication in the CI-based release process.
>
> Those who are concerned about folder structure deviation between
> `afs-{site,staging}` branches and the rest, all you need is a Git worktree:
>
> $ git clone g...@github.com:
> apache/logging-log4j-tools.git logging-log4j-tools~main
> $ cd logging-log4j-tools~main
> $ git checkout -B asf-site origin/asf-site
> $ git checkout -B asf-staging origin/asf-staging
> $ git worktree add ../logging-log4j-tools~site asf-site
>
> On Mon, Jan 15, 2024 at 9:34 AM Piotr P. Karwasz <piotr.karw...@gmail.com>
> wrote:
>
>> Hi,
>>
>> As we discussed yesterday the way our website is created from multiple
>> repos and branches is somehow incoherent: some parts of the website
>> have separate repos, other parts have a branch in a code repo, other
>> parts have a branch in a website repo.
>>
>> For example:
>>
>> * the `/log4j/jakarta` directory is published from the `asf-site`
>> branch of the `logging-log4j-jakarta` repo (which also contains the
>> code of Log4j Jakarta),
>> * the `/cyclonedx` directory is published from the `cyclonedx` branch
>> of the `logging-site` repo,
>> * the `/log4j` directory is published from the `asf-site` branch of
>> the `logging-log4j-site` repo (dedicated site repo).
>>
>> This is getting confusing and we need some kind of list to find the
>> repo/branch combination responsible for each part of the site.
>>
>> I think we should bring some order to it. Since not all the parts of
>> the website are connected to a code repo, my personal preference would
>> be to have everything in `logging-site`, with branches named like:
>>
>> asf-site
>> cyclonedx/asf-site
>> log4j/asf-site
>> log4j/2.x/asf-site
>> log4j/jakarta/asf-site
>>
>> Putting an `asf-site` (or another suffix) is a Git requirement since
>> Git does not allow us to have both `asf-site` and `asf-site/log4j`
>> branches.
>>
>> Anyway, any other convention is good for me, as long as the rules to
>> find the correct branch are not too convoluted.
>>
>> Piotr
>>
