Re: Release timeline for 2.24.0
I agree that compatibility is paramount for 2.x 😀 Gary On Thu, Jun 20, 2024, 12:22 PM Ralph Goers wrote: > I have been working on creating log4j-context-data. My plan was to remove > stuff from Log4j API after I have something workable. Even though 2.24.0 > won’t include log4j-context-data I want to make sure that what we are > leaving will be compatible. > > Ralph > > > On Jun 20, 2024, at 4:15 AM, Gary Gregory > wrote: > > > > I lost track of where we are after our video discussion regarding all the > > scoped classes and 2.24.0. Where are we on those? > > > > Also, can we get information on what happened with the conference call > > regarding the (IMO bad) idea on conditional testing? I sure hope we're > not > > using it. > > > > Gary > > > > On Tue, May 28, 2024, 12:27 PM Matt Sicker wrote: > > > >> Probably discussions about the ScopedContext API in general. > >> > >>> On May 26, 2024, at 14:49, Ralph Goers > >> wrote: > >>> > >>> > >>> > On May 26, 2024, at 11:06 AM, Christian Grobmeier < > grobme...@apache.org> > >> wrote: > > > > On Sat, May 25, 2024, at 04:22, Gary Gregory wrote: > > I'd like to have the PMC meet to review and discuss ScopedContext, > > which I am not caught up on, and whatever else we should chat about. > > Me too. > > I feel that all the discussion on the ScopedContext should be in an > >> experimental branch or an additional jar file rather than the stable > code > >> base. > > I see it popping up so often, I start to believe it's "not there yet.” > >>> > >>> See what popping up so often? > >>> > >>> Ralph > >> > >> > >
Re: Release timeline for 2.24.0
I have been working on creating log4j-context-data. My plan was to remove stuff from Log4j API after I have something workable. Even though 2.24.0 won’t include log4j-context-data I want to make sure that what we are leaving will be compatible. Ralph > On Jun 20, 2024, at 4:15 AM, Gary Gregory wrote: > > I lost track of where we are after our video discussion regarding all the > scoped classes and 2.24.0. Where are we on those? > > Also, can we get information on what happened with the conference call > regarding the (IMO bad) idea on conditional testing? I sure hope we're not > using it. > > Gary > > On Tue, May 28, 2024, 12:27 PM Matt Sicker wrote: > >> Probably discussions about the ScopedContext API in general. >> >>> On May 26, 2024, at 14:49, Ralph Goers >> wrote: >>> >>> >>> On May 26, 2024, at 11:06 AM, Christian Grobmeier >> wrote: On Sat, May 25, 2024, at 04:22, Gary Gregory wrote: > I'd like to have the PMC meet to review and discuss ScopedContext, > which I am not caught up on, and whatever else we should chat about. Me too. I feel that all the discussion on the ScopedContext should be in an >> experimental branch or an additional jar file rather than the stable code >> base. I see it popping up so often, I start to believe it's "not there yet.” >>> >>> See what popping up so often? >>> >>> Ralph >> >>
Re: Release timeline for 2.24.0
On Thu, Jun 20, 2024 at 8:50 AM Piotr P. Karwasz
wrote:
>
> Hi Gary,
>
> On Thu, 20 Jun 2024 at 13:55, Gary Gregory wrote:
> > I'll give you all my -1 POV here:
>
> I share some of your concerns.
> My main motivation for this experiment with Develocity is not to save
> up CI time, but to improve its responsiveness.
>
> From my contributions to other projects I learned that each project
> has some ("arbitrary") set of PR checks (formatting, unit tests,
> integration tests).
> Some of these checks fail fast enough so that I am able to fix them in
> the time I have available for that project. If those checks fail
> later, I'll fix them a couple of days (or weeks) later.
>
> We could configure PTS as a fail-fast mechanism:
>
> * for each PR we first run with PTS to see if it can find failing tests,
> * if that check succeeds we run the whole suite.
>
> If the PTS algorithm is sound, we might provide feedback to users in
> less than 10 minutes. Worst case scenario, they'll learn that the
> build failed later.
>
> What do you think?
Thank you for your thoughtful comments Piotr :)
This is, IMO, both a false economy and frustration in making for
contributors. Let me explain: This will cause more iterations between
contributors and the CI/us to approve runs and wait for CI runs. By
default IIRC, one of us has to _approve_ a PR before it is run, which
I believe is the correct behavior. A contributor _should_ run a full
local build _before_ pushing a PR IMO and not rely on the CI as their
build machine.
The workflow I encourage (for example in Apache Commons) is:
- We make sure a Maven POM has a default goal containing all build
checks and we document to ask users to run 'mvn' (by itself) _before_
pushing a PR. Having a default goal is simple. avoids missing any
checks, and allows us to edit the behavior without changing build and
PR instructions.
- This process allows the contributors to fix everything locally
_before_ pushing and waiting for the initial and subsequent PR run
approval. This saves time and encourages contributors to clean up or
complete their PR before bothering to push. There is nothing we can do
to avoid getting broken PRs of course.
Another missing piece is that a PR should fail if it decreases code
coverage or has missing tests. One way I found to enforce this in
Commons is to use JaCoCo's metrics checks; it's not perfect but it
sets a bar a PR must pass.
Gary
>
> Piotr
Re: Release timeline for 2.24.0
Hi Gary,
On Thu, 20 Jun 2024 at 13:55, Gary Gregory wrote:
> I'll give you all my -1 POV here:
I share some of your concerns.
My main motivation for this experiment with Develocity is not to save
up CI time, but to improve its responsiveness.
>From my contributions to other projects I learned that each project
has some ("arbitrary") set of PR checks (formatting, unit tests,
integration tests).
Some of these checks fail fast enough so that I am able to fix them in
the time I have available for that project. If those checks fail
later, I'll fix them a couple of days (or weeks) later.
We could configure PTS as a fail-fast mechanism:
* for each PR we first run with PTS to see if it can find failing tests,
* if that check succeeds we run the whole suite.
If the PTS algorithm is sound, we might provide feedback to users in
less than 10 minutes. Worst case scenario, they'll learn that the
build failed later.
What do you think?
Piotr
Re: (logging-log4j2) branch 2.x updated: Disable PTS on a per-module basis
Hi Gary, On Thu, 20 Jun 2024 at 14:15, Gary D. Gregory wrote: > I am -1 on changing our PRODUCTION 2.x build. If you want to experiment with > some company's product, please do so in a non-production branch. The cynic in > me sees this as a company wanting free advertising to say Apache uses their > foo product in production. I am pretty sure, advertising is the main reason many companies offer their products to ASF free of charge. ;-) Piotr
Re: (logging-log4j2) branch 2.x updated: Disable PTS on a per-module basis
On 2024/06/14 20:37:44 "Piotr P. Karwasz" wrote: > Hi Gary, > > On Fri, 14 Jun 2024 at 18:12, Gary Gregory wrote: > > I sure hope that all tests are ALWAYS run by default in the 2.x branch, > > otherwise it will be a -1 from me. > > Currently Predictive Test Selection is enabled on all CI builds, > except the `release/*` branches, since I am trying to evaluate the > feature, before I make a proposal on this mailing list. So please, > indulge me, for a couple of weeks. > > Currently the usage of Develocity is experimental and `logging-log4j2` > is running builds using the `develocity` branch of `logging-parent`, > so be reassured that before we do any release: > > 1. We'll largely discuss my findings (PMC meeting in a week or two?), > 2. `logging-parent` needs to be released. > > For those that have never heard about Develocity, it is a new Gradle > product that aims at increasing developer productivity by reducing the > time we wait for our builds to complete. > INFRA rolled out an ASF instance of Develocity and you can check it out at: > > > https://ge.apache.org/scans?search.rootProjectNames=*log4j*&search.timeZoneId=Europe%2FWarsaw# > > I am experimenting with this tool to improve the quality of our test > suites (aka the code users never help us with). It has some useful > features like: > > 1. Test execution statistics, which help us identify the broken and > flaky tests. As it turns out `JeroMqAppenderTest` is not the test that > fails most often and we also have flaky tests that never (as far as I > can remember) caused a build to fail. For example `BurstFilterTest` > fails at least once in 50% of the builds. > 2. PTS will allow our CI to run faster, because it only runs the tests > that are more likely to fail for a given code modification. This might > help contributors that submit PRs to get faster feedback or run the > test suite before submitting a patch. > Truth be told, I often skipped the local test run, since it took over > 30 minutes on my old laptop. On my new desktop I always run all tests, > since it takes 3 minutes (half of that time Maven is waiting for the 3 > broken Flume tests). > > Of course I have my reservation regarding this tool: > > 1. The Maven plugin it uses is not Open Source. It is probably high > quality code, but not **provably** high quality code. > 2. It uses build caching, which might fake the results of builds. > > As far as I understand Develocity should be a no-op on your computers, > unless you generate an API key for it. If you want to try it, run: > > ./mvnw com.gradle:develocity-maven-extension:provision-access-key > > in a working tree of `logging-log4j2`. What does that mean, "in a working tree of `logging-log4j2`"? I am -1 on changing our PRODUCTION 2.x build. If you want to experiment with some company's product, please do so in a non-production branch. The cynic in me sees this as a company wanting free advertising to say Apache uses their foo product in production. > 1. The Maven plugin it uses is not Open Source. It is probably high > quality code, but not **provably** high quality code. > 2. It uses build caching, which might fake the results of builds. Well, that sounds horrible: "which might fake the results of builds." Gary > > Piotr >
Re: Release timeline for 2.24.0
On Thu, Jun 20, 2024 at 7:37 AM Piotr P. Karwasz wrote: > > Hi Gary, > > > On Thu, 20 Jun 2024 at 13:15, Gary Gregory wrote: > > I lost track of where we are after our video discussion regarding all the > > scoped classes and 2.24.0. Where are we on those? > > From my part I didn't advance much, since we are working hard on > reviewing and improving the documentation. However, my fingers are > aching from writing too much AsciiDoc, so I'll clean up `log4j-api` > soon. > > > Also, can we get information on what happened with the conference call > > regarding the (IMO bad) idea on conditional testing? I sure hope we're not > > using it. > > We can have a call this Sunday, I just need to check my schedule. I'll give you all my -1 POV here: In a real build, I have 100% confidence that ANY change I make runs through the existing code coverage. With this proposal, I have 0% confidence because I know that either not everything is tested, or worse, a random subset of tests runs which is unpredictable to a plain-brained human like myself. For me, this defeats the whole point of having a CI build! The CI build MUST test everything all the time. This is especially important for pull requests. I can imagine this user story: "As a developer, I want the ability to shoot myself and my colleagues in the foot, by only running a random subset of tests locally before I push to the repo". This feels like a classic case of unintended consequences waiting to happen. And just like with other tools like SpotBugs, PMD, Checkstyle, and so on, you end up with a configuration file, an exclusion file, but in this case, the false positives don't fail your build erroneously, instead they skip tests and allow regressions to creep in. No thanks. Gary > > Piotr
Re: Release timeline for 2.24.0
Hi Gary, On Thu, 20 Jun 2024 at 13:15, Gary Gregory wrote: > I lost track of where we are after our video discussion regarding all the > scoped classes and 2.24.0. Where are we on those? >From my part I didn't advance much, since we are working hard on reviewing and improving the documentation. However, my fingers are aching from writing too much AsciiDoc, so I'll clean up `log4j-api` soon. > Also, can we get information on what happened with the conference call > regarding the (IMO bad) idea on conditional testing? I sure hope we're not > using it. We can have a call this Sunday, I just need to check my schedule. Piotr
Re: Release timeline for 2.24.0
I lost track of where we are after our video discussion regarding all the scoped classes and 2.24.0. Where are we on those? Also, can we get information on what happened with the conference call regarding the (IMO bad) idea on conditional testing? I sure hope we're not using it. Gary On Tue, May 28, 2024, 12:27 PM Matt Sicker wrote: > Probably discussions about the ScopedContext API in general. > > > On May 26, 2024, at 14:49, Ralph Goers > wrote: > > > > > > > >> On May 26, 2024, at 11:06 AM, Christian Grobmeier > wrote: > >> > >> > >> > >> On Sat, May 25, 2024, at 04:22, Gary Gregory wrote: > >>> I'd like to have the PMC meet to review and discuss ScopedContext, > >>> which I am not caught up on, and whatever else we should chat about. > >> > >> Me too. > >> > >> I feel that all the discussion on the ScopedContext should be in an > experimental branch or an additional jar file rather than the stable code > base. > >> > >> I see it popping up so often, I start to believe it's "not there yet.” > > > > See what popping up so often? > > > > Ralph > >
