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?

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
> > >
> >
>

Reply via email to