[This report is written by Volkan Yazici and represents nothing but his personal views. Ever heard of the Oracle Safe Harbor statement? Yes, everything written here is a lie.]

This first version of Online Drinks, in particular aimed for Log4j contributors, is initiated by Volkan Yazici. The meeting was organized through the log4j-pmc mailing list, though it has been decided to move the next organization to the dev mailing list. The participants were as follows:

  1. Carter Kozak
  2. Gary D. Gregory
  3. Matt Sicker
  4. Ralph Goers
  5. Remko Popma
  6. Ron Grabowski
  7. Volkan Yazici

Below is a screenshot from the Google Meet session:

Overview

In addition to hearing personal stories of contributors (e.g., Remko Popmamoving from the Netherlands to Tokyo with the hope of mastering his Go skills, ended up coding Java for finance industry) and their motivation for contributing to the Apache Logging Services, two noteworthy other things have happened:

  1. Ron Grabowski asked for potential Log4j contribution areas to break his long dormant strike as a PMC member. He later on leveraged the created enthusiasm of others to hijack the meeting and consult for certain technical questions, of which some are converted into JIRA tickets: LOG4J2-2985 and LOG4J2-2986.
  2. All major Log4j contributors (i.e., everybody in the room) shared what they are currently work on and what they think needs to be addressed in 2021.

Highlights

Below is a list of highlights collected from the discussions:

Slf4j, Logback, and Spring Framework

The subject is mainly opened by Ralph Goers and received almost everybody's support. Slf4j project in its current state anything but alive. Logback has its fair share from this too. Ceki Gulcu is the founder of these projects and the only one who has access rights to make a release. Given the development on these projects have long been significantly stagnated and nobody is able to step up to keep the development going on, this is sort of concerning from a community perspective. In the light of these, Log4j is a natural successor with rich set of features offered and active community-driven development cycle. Ralph Goers is apparently on a pursuit to convince the Spring Framework to migrate from Logback to Log4j for the good. (Ralph Goers, mind sharing the GitHub issue link so that others can up vote?)

StackOverflow questions

It is stated that many of our users are sharing their questions on StackOverflow. All contributors are kindly asked to check StackOverflow more often and assist users there. (Apparently Remko Popma scores pretty well in this subject, which sort of make others jealous.)

Inactive PMC members

Apache Logging Services have plenty of PMC members, which sort of creates an inaccurate impression for the development resources of the project. It is also not possible to revoke this membership without asking for the consent of the member. Ralph Goers shared the idea of active-vs-inactive PMC members, which captures the development resources more accurately. The rest agreed with the idea.

Pandemic & Remote

Volkan Yazici appears to be the only one complaining about the pandemic and how difficult it is to spare time for anything given the day cares and schools are closed and there is a toddler running in the house. The rest was doing perfectly fine – for some definition of perfect.

ErrorProne, code style guide, compiler warnings, no commits to master

Everybody agrees on the importance of code (style) quality and consistency, though it is admitted that Log4j has plenty of room for improvement in this domain. Two actions points are agreed on regarding this issue:

  1. No commits to master anymore. Everybody will work on branches and GitHub PRs. (Cherry-picking between release-2.x and master is okay.)
  2. Code quality needs to be part of the CI, though it might take us months to get a green build. Hence, as proposed by Gary D. Gregory, we will do this module-by-module, rather than the entire project.

Documentation and approachability of the source code

Even though Log4j is a state-of-the-art logging platform, its website and documentation doesn't reflect this, stated Volkan Yazici. He further noted that the website is pretty difficult to navigate and is not new user welcoming. He shared his secret agenda to revamp the website and the documentation using Anthora. Additionally, everybody(?) knows how cumbersome it is to get Log4j source code up and running in a modern IDE for new contributors. Here Module System introduced with Java 9 is partly to blame. Though there are certain areas we can iron wrinkles for new contributors.

Java 11

Thanks to Ralph Goers, master will move to Java 11. This will significantly simplify the build.

Android

Almost none of the main contributors are working on Android, though it is an important market. Concerns regarding Android compatibility are looking for courageous souls to embark on them.

GraalVM

There are still certain parts of the code base using MethodHandle's, which is sort of a show stopper while compiling using GraalVM. Native binary compilation is not on the radar of anybody yet, though it should be!

JIRA backlog

Log4j has a pretty long backlog. It is agreed that all solutions surrounded around deleting the dormant tickets are bad. Hence, it is what it is.

  • No labels

1 Comment

  1. I should note that although this is title "Online Drinks" I really didn't notice anyone drinking anything other than water!

    Regarding Spring. https://github.com/spring-projects/spring-boot/issues/16864 and https://github.com/spring-projects/spring-boot/issues/10072 were both requests to make Log4j2 the default. Both were declined but I commented on both about our support for Spring. However, https://github.com/spring-projects/spring-boot/issues/22149 was opened by Phil Webb, one of the major contributors to Spring, to look at making this happen in Spring Boot 3. I have expressed our support for that issue.

    Regarding the Jira backlog - all automated or scripted solutions are bad. Manually wading through the backlog is tedious but is worth doing to close any items that have already been fixed or don't apply any more. The largest question revolves around issues that are very unlikely to ever be worked on but are valid.

    Regarding code style - we didn't make any decision regarding directly committing to the master or release-2.x branches. We can't make any binding decisions on a call like this. We did agree that the only way to improve our code quality was to always use pull requests with appropriate GitHub actions to validate them.