Re: Use RTC in Log4j and Log4Net

On Wed, Sep 18, 2024 at 10:17 AM Piotr P. Karwasz wrote: > However, we don't necessarily need to use `2.x` or `main` for those tests. > You cannot fix fuzz tests in another branch than `2.x` once OSS-Fuzz starts pointing there – unless you're willing to waste +2 months for testing a simple typo:

Re: Use RTC in Log4j and Log4Net

I sort of agree and sort of not. It would be nice to have automation that can enforce some rules. You can’t do that if there are none. We could agree in principle to a small number of files and lines but set the enforcement to a larger number to allow for some exceptions. For example, if we agr

Re: Use RTC in Log4j and Log4Net

The quick turnaround time for PR reviews is important when I only have time to work on the project one or two days a week. > On Sep 18, 2024, at 08:38, Ralph Goers wrote: > > I sort of agree and sort of not. It would be nice to have automation that can > enforce some rules. You can’t do that i

Re: [log4j] Google OSS-Fuzz integration

Very neat! > On Sep 17, 2024, at 14:21, Volkan Yazıcı wrote: > > OSS-Fuzz is a Google service that > continuously runs fuzz tests of critical F/OSS projects on a beefy cluster > and reports its findings (bugs, vulnerabilities, etc.) privately to project > mai

Re: Use RTC in Log4j and Log4Net

This proposal is two pages (on my phone)! I can't imagine counting lines and walking through these steps, it's crazy making IMO. How would you count lines anyway? From diff output? I'd rather skip the bikeshedding and let devs create PRs when they think it makes sense. IOW, when they want a review

Re: Use RTC in Log4j and Log4Net

Hi Volkan, On Wed, 18 Sept 2024 at 09:46, Volkan Yazıcı wrote: > Changes can be exempt from this policy if and only if they suffice *only > one* of the following conditions: > >1. Grammatical corrections to the documentation (incl. Javadoc and >release notes) >2. Code typo fixes¹ less

Re: Use RTC in Log4j and Log4Net

I agree in principle, but... *Exemption criteria* I agree with Ralph on that we should specify criteria on what shall be exempt from this PR-driven workflow policy. We should of course materialize these criteria collaboratively. Below is my attempt for a starting point: Changes can be exempt fro