Indeed log4jcxx and log4net don't use logging-log4j-site, hence this was a mistake from my side. Yet log4j-kotlin and log4j-scala do.
I am not able to see how my point about the difficulty of multi-repo setups is addressed. Log4j sources and the site are on different repos. In conclusion, I am giving up. I thought that having the site and the sources in the same repo is a good thing to have. Though given your strong objection and no support from others, maybe it is just me who needs to reconsider the idea. On Tue, Oct 19, 2021 at 3:37 PM Apache <ralph.go...@dslextreme.com> wrote: > Volkan, > > I am not in front of my computer at the moment, but I am 100% sure you are > incorrect. Every logging project has its own GitHub repo for its own web > site. The thought of having log4cxx and Log4Net use a repo with Log4J in > the name doesn’t make any sense. > > Publishing a web site involves committing the changes to the asf-staging > branch, reviewing those changes, and then merging the staging branch to the > live branch. > > I just don’t see what advantages using GitHub pages provides over this as > your points below seem like they are already covered. > > Ralph > > > On Oct 19, 2021, at 1:14 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > In its current state, all Logging Services projects (log4j, log4jcxx, > > log4net, etc.) dump their websites to a single repository: > > https://github.com/apache/logging-log4j-site If I need to publish > > continuous benchmark results of logging-log4j2 repository, I need to push > > my changes to two other branches of another repository. What I was asking > > for is if we can publish a website to a logging-log4j2 repository branch > > such that it will be displayed under a logging.apache.org subdomain. > This > > approach would provide the following advantages: > > > > - Every repository will contain its own website. (I guess, we can all > > agree this is a good thing to have.) > > - CI (in particular, benchmark) scripts won't need to hack their way > > around multi-repo setups. > > - No disruption to the current logging.apache.org flow. > > > > > >> On Mon, Oct 18, 2021 at 9:16 PM Ralph Goers <ralph.go...@dslextreme.com > > > >> wrote: > >> > >> I feel like I am going in circles. > >> > >> Testing of what? I still don’t understand what the use case is for > GitHub > >> Pages. What problem is it solving? > >> > >> Ralph > >> > >>>> On Oct 18, 2021, at 12:05 PM, Matt Sicker <boa...@gmail.com> wrote: > >>> > >>> I’d imagine it’s for testing purposes initially. We should integrate it > >> into the main domain when it’s ready for release. This should all be > >> controllable via the .asf.yaml file. > >>> > >>> Matt Sicker > >>> > >>>> On Oct 18, 2021, at 12:32, Ralph Goers <ralph.go...@dslextreme.com> > >> wrote: > >>>> > >>>> Why? > >>>> > >>>> Ralph > >>>> > >>>>> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > >>>>> > >>>>> For the moment, I just want the `gh-pages` branch of the > logging-log4j2 > >>>>> GitHub project to be accessible at "a" URL – just like any other > >> non-ASF > >>>>> GitHub project. > >>>>> > >>>>>> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers < > >> ralph.go...@dslextreme.com> > >>>>>> wrote: > >>>>>> > >>>>>> OK. That page didn’t exist when I migrated the site from the CMS. > That > >>>>>> still leaves > >>>>>> the second question. What are you proposing? I don’t really see the > >> point > >>>>>> of moving > >>>>>> the existing site to GitHub Pages. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > >>>>>>> > >>>>>>> GitHub Pages look pretty doable to me: > >>>>>>> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages > >>>>>>> > >>>>>>> On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers < > >> ralph.go...@dslextreme.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> I don’t really understand this. When I was migrating the web site > >> from > >>>>>> the > >>>>>>>> ASF CMS to GitHub > >>>>>>>> it was made clear that web site hosting using GitHub Pages wasn’t > >>>>>>>> supported. I am not sure > >>>>>>>> what the proposal here is. > >>>>>>>> > >>>>>>>> Ralph > >>>>>>>> > >>>>>>>>> On Oct 15, 2021, at 8:27 AM, Matt Sicker <boa...@gmail.com> > wrote: > >>>>>>>>> > >>>>>>>>> I’m not exactly sure how we can get a beta subdomain, though the > >>>>>> staging > >>>>>>>> one is built in. And while it would be great to automate as much > as > >>>>>>>> possible about the release process in GHA, the code signing aspect > >> is > >>>>>> still > >>>>>>>> not possible (though we might be able to integrate with another > >> service > >>>>>> at > >>>>>>>> Apache for that, but it doesn’t cover the GPG signature). There’s > >> also > >>>>>> some > >>>>>>>> ASF rule I think about releases needing to be done by a human, but > >> that > >>>>>>>> might be more about reproducible builds. > >>>>>>>>> > >>>>>>>>> Matt Sicker > >>>>>>>>> > >>>>>>>>>> On Oct 15, 2021, at 05:57, Volkan Yazıcı <vol...@yazi.ci> > wrote: > >>>>>>>>>> > >>>>>>>>>> I long had the ambition to move the entire site & manual to > >> gh-pages. > >>>>>>>>>> In an ideal world, I would even move the release process to > GitHub > >>>>>>>> Actions > >>>>>>>>>> too. > >>>>>>>>>> But these are, for now, pretty ambitious goals. > >>>>>>>>>> What I would really appreciate is to access gh-pages content > via, > >> say, > >>>>>>>>>> https://beta.logging.apache.org/log4j URL. > >>>>>>>>>> Matt, mind helping me with setting this up please? > >>>>>>>>>> > >>>>>>>>>>> On Wed, Oct 13, 2021 at 7:12 PM Matt Sicker <boa...@gmail.com> > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> That's really cool! Do note that we can publish to the > >> ASF-specific > >>>>>>>>>>> branches, too, for hosting a site. > >>>>>>>>>>> > >>>>>>>>>>>> On Wed, Oct 13, 2021 at 10:37 AM Volkan Yazıcı < > vol...@yazi.ci> > >>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Do this: > >>>>>>>>>>>> > >>>>>>>>>>>> git fetch -p > >>>>>>>>>>>> git checkout -B gh-pages origin/gh-pages > >>>>>>>>>>>> python -m http.server > >>>>>>>>>>>> open http://localhost:8000/benchmark/results/index.html > >>>>>>>>>>>> > >>>>>>>>>>>> *The magic:* > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>> > >> > https://github.com/apache/logging-log4j2/blob/release-2.x/.github/workflows/benchmark.yml > >>>>>>>>>>>> > >>>>>>>>>>>> *Disadvantages:* Runner specs are on the flux, though mostly > >> pretty > >>>>>>>>>>> stable. > >>>>>>>>>>>> > >>>>>>>>>>>> *Future work:* > >>>>>>>>>>>> > >>>>>>>>>>>> - Enable GitHub pages for the project? > >>>>>>>>>>>> - Incorporate more from log4j-perf to here. > >>>>>>>>>>>> - Put the workflow onto a cron schedule. > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >> > >> > >> > > >
