On Sat, Sep 2, 2023 at 8:35 AM Gary Gregory <garydgreg...@gmail.com> wrote:
> On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > >> > For me, there is one kind of "user" >> >> As Piotr indicated we have multiple user groups. As stewards of this >> project we should take these into account, not just our personal agenda. >> The current release model where everything shipped all at once doesn't >> cater for all such use cases. >> >> > For me, there is one kind of "user": a POM that Dependabot can >> optionally manage >> >> We will still ship a BOM module where we share a version composition that >> is guaranteed to work. Hence, the "user" you mentioned, can still safely >> rely on *one single* `log4j.version` property in their `pom.xml` and that >> will still get regularly updated by `dependabot`. >> > > So any time you release any jar, the BOM is updated? > updated -> released Gary > > Gary > > >> >> Put another way, we won't disrupt the existing consumption method of >> Log4j. >> It will keep on working. We will introduce a new possibility: only relying >> on particular components (e.g., `log4j-api`) and only getting updates when >> those components *are* really updated. >> >> On Fri, Sep 1, 2023 at 11:16 PM Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >> > Hi Piotr, >> > >> > Thank you for your detailed response :-) >> > >> > My comments are inline below. >> > >> > >> > On Thu, Aug 31, 2023 at 4:59 PM Piotr P. Karwasz < >> piotr.karw...@gmail.com> >> > wrote: >> > >> > > Hi Gary, >> > > >> > > May I offer a different perspective on this. >> > > >> > >> > I knew that ;) >> > >> > >> > > >> > > On Wed, 30 Aug 2023 at 18:56, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > > > - I like a mon-repo in general because: >> > > > -- Everything is released together with the same version. There is >> no >> > > > mystery of what works with what, what we tested with what. See the >> bugs >> > > > with Maven plugins mysteriously breaking as counter-examples. >> > > >> > > While seeing the same version is aesthetically pleasant, we have 4 >> > > kinds of users: >> > > * library developers will never need anything beyond `log4j-api`, >> > > * JUL users will only need `log4j-to-jul`, which declares its >> > > `log4j-api` requirement, >> > > * same for Logback users, they'll only need `log4j-to-slf4j`, >> > > * Log4j Core users **need** to use `log4j-bom` anyway: I have seen >> > > several question from Spring Boot users that add the newest version of >> > > `log4j-core` to their app and end up with an old (incompatible) >> > > version of `log4j-api`, since Spring Boot does version management. >> > > >> > >> > I don't think this is relevant IMO. For me, there is one kind of >> "user": a >> > POM that Dependabot can optionally manage. Over at Apache Commons, >> > Dependabot runs on Friday and that's the day I pay attention to such >> things >> > (or Saturday AM). Running it every day is not great. It would be nice if >> > Dependabot could tell you about releases that address CVEs as soon as >> they >> > are available. >> > >> > >> > > >> > > > -- A mono-repo gives me the confidence that everything works >> *together* >> > > because >> > > > it was built and tested *together*. >> > > >> > > In a multi-module setup we would still run e.g. `log4j-cassandra` >> > > version 2.20.0 tests against the `log4j-core `2.24.0` snapshot. >> > > >> > >> > That's bad in my view, it's confusing as well. >> > >> > >> > > >> > > > -- I or Dependabot can update one Maven property in in my POM for >> all >> > of >> > > > Log4j and I'm done. >> > > > -- I *don't *want a Dependabot PR for each Log4j jar because I use >> > > > log4j-api v1, log4j-core v2, log4j-foo v3, log4j-bar v4, log4j-boo >> v5, >> > > > log4j-arg v6, and so on. >> > > >> > > If you stick to `log4j-api`, `log4j-bom`, `log4j-to-slf4j` or >> > > `log4j-to-jul` above, you would also get just one Dependabot PR. >> > > >> > >> > Maybe, maybe not. What module is in what repo is imaginary ATM. >> > >> > >> > > With some improvements to Dependabot, a new release of >> > > `log4j-something` and `log4j-bom` might be ignored by Dependabot if it >> > > detects that you are not using `log4j-something`. >> > > >> > >> > "With some improvements to Dependabot..." is an argument against what >> you >> > propose. You can't sell me something built with a tool that doesn't >> exist. >> > >> > >> > > > -- A mono-repo is the lowest barrier to entry for new contributors. >> > Don't >> > > > force me to learn more weird tooling and procedures, Maven and plain >> > git >> > > > are enough magic for anyone. >> > > >> > > I agree that finding the right repo in a multi-repo project might be >> > > challenging. >> > > On the other hand from a testing perspective the user does not have to >> > > know why a PR on `log4j-core` starts a test suite in another repo. >> > > >> > >> > And imagine the surprise when they break a downstream build they had no >> > idea existed in the first place. >> > >> > >> > > > - I would like to see all modules split up such that there are no >> > > optional >> > > > dependencies. I want to be able to depend on a log4j-console for >> simple >> > > > apps and get a minimal install. >> > > >> > > I would like that too in 3.x. At my current job the requirement was >> > > "having a logging system that prints to a console or a file", so we >> > > went with JUL. Of course I switched the backend on my dev box to Log4j >> > > Core since debugging using JUL is painful (no proper layout, markers, >> > > etc.). >> > > >> > >> > Well, there's one thing we can agree on :-) >> > >> > >> > > >> > > > - I am horrified to read "Enables module rot". Hiding a module from >> a >> > > user >> > > > and letting it "rot" is terrible: It is not a development process >> and >> > > > reflects poorly on us IMO. To drop a module, we should: Agree in a >> poll >> > > or >> > > > vote, deprecate it for removal, and then remove it. That's a >> process. >> > Not >> > > > "Oh, well, it's been rotting on the side over there and it doesn't >> work >> > > > anymore, oh well! Sorry!" >> > > >> > > Let's use the term "to retire a module". >> > >> > >> > Giving it a more polite name does not change anything. I see three >> states: >> > Supported, Deprecated, and Removed. >> > >> > I'll stop here since I've already expressed my arguments against what's >> > below. >> > >> > Gary >> > >> > >> > > These are feature stable that >> > > have a much slower lifecycle than `log4j-core` and a smaller user >> > > base. >> > > I would prefer: >> > > * to still support these modules, >> > > * to have a version number that reflects the actual changes to the >> > module, >> > > * to be able to release them independently if a bug report comes in, >> > > * to allow people to relieve us from maintaining these modules, if >> > > they work on a day-to-day basis with that technology. E.g. Apache >> > > Cassandra might decide to take over `log4j-cassandra` (fork the repo). >> > > >> > > We are not talking about "hiding" them from the user: one of the >> > > projects for next year is to include on our website the generated >> > > documentation of every Log4j component that has an enhanced >> > > `Log4jPlugins` in its JAR (on a opt-in basis). >> > > >> > > I have the feeling that we are discussing an X-Y problem: I want to be >> > > able to release components independently, so I don't have to release >> > > `log4j-core` just because SLF4J released version 2.x or I don't have >> > > to delay the release of `log4j-core` because Jackson has a streak of >> > > CVEs. I'd like to split the responsibility of releasing a 10M monthly >> > > downloads product into more digestible bits. >> > > >> > > That is why I support multi-repo, because it seems simpler to reach >> > > the goal. From a Public Relations perspective I would only like >> > > `log4j-api` and the three existing implementations to have separate >> > > repos. >> > > >> > > Piotr >> > > >> > >> >
