Then the branch should be called "experimental" not "feature".
Gary On Tue, Oct 21, 2025, 06:58 Piotr P. Karwasz <[email protected]> wrote: > > Hi sebb, > > On 21.10.2025 11:08, sebb wrote: > >> - final int code; > >> + public final int code; > > > > -1 > > > > This exposes what is currently an internal implementation detail. > > There are other ways to make the value available to the fuzzing test > code. > > For example, add a test class in the same package that gives access > > via a getter. > > > > We should not modify the public API to satisfy test requirements > > unless absolutely necessary. > > Thanks for your feedback. I agree that test requirements should not > drive API changes, and I will remove that change before opening any PR > against master. > > Just to clarify the context: the `feat/fuzzing` branch is being used > purely as a working sandbox to explore approaches for fuzzing and to > generate some artifacts (e.g. the `long-name.dump` archive sample that > ended up in PR #710). Making those codes public was only a quick interim > step to support that experiment, not something I ever intended to > propose for `master`. > > To avoid any confusion: > > - I do not plan to merge `feat/fuzzing` directly into master. > > - The branch will be cleaned up and split into a series of focused, > reviewable PRs once the approach stabilizes. > > At the moment this branch should be viewed as exploratory/brainstorming > work. Once I have refined the fuzzing strategy, I will follow the > regular review process and submit PRs. > > Best, > Piotr > > [1] https://github.com/apache/commons-compress/pull/710 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
