My understanding is that this was tracked down using git bisect, so I'd assume that there is a test case?
Am Mo., 10. Feb. 2025 um 18:10 Uhr schrieb Konrad Windszus <k...@apache.org >: > Hi Robert, > Thanks for chiming in. > > > On 10. Feb 2025, at 18:03, Robert Munteanu <romb...@apache.org> wrote: > > > > Hi, > > > > (usual peanut gallery disclaimer applied) > > > > On Mon, 2025-02-10 at 16:10 +0100, Konrad Windszus wrote: > >> Hi Julian, > >> I would refrain from doing reverts before really understanding (and > >> describing) the actual issue. > >> IIUC from https://issues.apache.org/jira/browse/OAK-11470 the root > >> cause is still unclear. > >> Please provide further insights why a revert fixed this and what the > >> nature of those failing ITs were. > >> > >> For me it feels a bit like there is something going on outside the > >> ASF which drives the release which is not how it is supposed to be. > >> For me as PMC it is impossible to judge how reasonable the commit > >> related to OAK-11470 is without knowing: > >> > >> - at least the failing external ITs output > >> - a reproducible scenario > >> > >> Regarding: > >>> > >>> Can we please leave these details to the person acting as Release > >>> Manager? > >> > >> Reverting lots of commits on the main branch is not a detail, it will > >> affect everyone working on the same code base. > >> Therefore I think before doing that as release manager this justifies > >> some pre-alignment on the mailing list. > >> > >> Open source is all about transparency. Let us come back to this > >> transparency at Jackrabbit. > > > > > > I would trust the release manager to cancel the release vote if they > > have found enough proof that there is a problem with the release. They > > can of course also postpone the decision until the root cause is > > properly understood and formulate but I don't think that's mandatory. > > Fully agree here, however my concern was not about cancelling the release > but doing revert commits on the main branch. > > > > > What I am not that onboard with is respinning a release without a good > > understanding about why the initial release was broken to start with. I > > think there is no rush to get this release out the door and we should > > do it with a good regression test in place. > > Also very much +1 here. > > > > > Thanks, > > Robert > > > > > >> > >> Thanks, > >> Konrad > >> > >>> On 8. Feb 2025, at 10:57, Julian Reschke > >>> <julian.resc...@gmx.de.INVALID> wrote: > >>> > >>> On 08.02.2025 09:37, Konrad Windszus wrote: > >>>> Hi Julian, > >>>> This sounds pretty vague. What exactly was not working in some > >>>> external tests? > >>> > >>> I really don't know exactly. What we could single out was the > >>> removal of > >>> Guava ImmutableSet. These kind of changes are somewhat risky > >>> because of > >>> subtle differences with the alternatives (nullability & order). > >>> > >>>> Also all the reverts and particularly > >>>> https://issues.apache.org/jira/browse/OAK-11470 don’t really > >>>> provide any insights. > >>> > >>> ...added some short explanation. > >>> > >>>> Why do we temporarily have to revert everything in master instead > >>>> of using a branch to fix the release? > >>> > >>> Because I did not want to release from a branch. > >>> > >>> Can we please leave these details to the person acting as Release > >>> Manager? > >>> > >>>> ... > >>> > >>> > >>> Best regards, Julian > >
