Am 10.02.2025 um 16:10 schrieb Konrad Windszus:
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.
I have no insights about what exactly these customer ITs are. What I
know is that we figured out what PR was causing them. We tried a revert,
and it fixed the issue. I fully believe that's sufficient to cancel a
release, revert the change, and respin the release.
(Note that the questionable PR is just one of many for reducing use of
Guava, so it really does not matter *when* it is done; we also know that
this change could have to do with set ordering, nullability etc; that's
why it sometimes is hard to find the exact change in a large PR which is
the real bug)
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.
Releases happen when a PMC member volunteers to do one. It should not
come as surprise that frequently, these releases happen exactly when a
big user of the project actually needs one.
But that does not stop anybody else on the PMC to spin a release at any
other point of time.
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
That doesn't make any sense to me. We have a non-critical change that
breaks *something* *somewhere*. Of course we want to understand what
exactly is the issue, and - even more important - why we don't have test
coverage for it. Because if we did, we wouldn't even have this conversation.
But this kind of investigation/analysis does not happen over night.
Please also note that this problem is already present in Oak 1.74.0. I
think we owe it to users of that release to get this fixed (for some
value of "fixed") and make a new release without that problem.
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.
7. Of which 5 are mostly trivial. (Code cleanup, diagnostics fixed, pom
improvements).
Therefore I think before doing that as release manager this justifies some
pre-alignment on the mailing list.
I actually talked to the committers who were affected. And I also
announced the reverts before I made them. *And* I announced that I'll
re-apply these changes once we have shipped 1.76.0.
Open source is all about transparency. Let us come back to this transparency at
Jackrabbit.
Konrad, you know very well that I'm trying to do this as transparently
as humanly possible.
Sometimes timing is critical and bad.
Releases happen when PMC members feel that a release is needed. I'm
sending out a release plan 24h before starting a release - how many
projects do that?
Managing releases is voluntary. I'd be more than happy if somebody else
stepped in so I'm not the only one. FWIW, attacking those people who
invest most of the time taking care of the project is not helping.
Best regards, Julian
