Just an external/private one (compare with https://issues.apache.org/jira/browse/OAK-11470). No insights have been shared what exactly was failing/is now fixed. Konrad
> On 10. Feb 2025, at 18:27, Manfred Baedke <manfred.bae...@gmail.com> wrote: > > 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 >> >>
