hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sivabalan <>
Subject Apache Hudi release voting process
Date Sun, 22 Aug 2021 20:25:17 GMT
Hi folks,
    Wanted to start a thread to discuss our guidelines on the release
process with Apache Hudi. You can find our existing release process here
a high level, our release process is as follows.

    1. Call for a release and rough timeline.
    2. Nominate a release manager.
    3. RM collects all release blockers and starts an email thread. This
email is to call for any other jiras/release blockers to be included as
part of the release. Also, asks respective owners of release blockers to
commit to a time for closing it out.
    4. After the deadline, if not all release blockers are landed: a. Moves
any pending release blockers to the next release that seems not very
critical. b. If there are some essential release blockers, ask the
respective owners to get it to closure and extends deadlines to get them in.
    5. Once all release blockers are landed, works on RC1. Verifies the
candidate and puts it out for voting.
    6. If approved by majority, proceed with actual release.
    7. If not approved by majority, waits for the fix to get merged and
works on RC2.

Coming to our 0.9.0 release, here is how the timeline looks like.

Jul 14: Decided on RM
Aug  3: RM sent an email with all release blockers. He called out for
missed our release blockers and asked for respective owners to be mindful
of the deadline for release.
Aug  5: Decided the deadline for release blockers to be landed as 13th Aug.
Aug 14: All release blockers were landed. Those that could not be landed
were rolled over to 0.10.0
Aug 15: RC1 was announced.
Aug 17: voted -1 by PMC due to config name issue. Existing jobs from older
hudi versions might fail once migrated.
Aug 18 to Aug 19: Config patch was worked upon and landed.
Aug 20: RC2 was announced.

>From the literature I found on apache release guidelines
<>, there are no strict
guidelines on what can be qualified as -1. But only PMC votes are binding
in general. From what we have seen, reasons for -1 are as follows: if there
are any license issues or any of the apache process is not followed
properly, or basic quick start is failing, or major regression for existing
users who might be migrating to this latest release or anything that's
considered very critical for the project to have something as part of the
upcoming release. I also went through the release guidelines of other
popular apache projects (spark, flink), but didn't not find any project
specific guidelines on voting -1 as such.

I agree that we have a gap here wrt voting guidelines. We can definitely
work towards that and fix it before the next release on what can be
qualified for -1. But we have laid out the release guidelines to make the
process smooth and to follow the apache way. That's why RM sent an email
calling out for any more release blockers to be considered for the upcoming
release. And looks like we had 10+ days until the deadline from the email
sent out. Wondering why the issues raised now were not brought up earlier.

I do get the intention behind, getting more improvements as part of the
release for users of Hudi with major releases. But we should be mindful of
setting a precedence here. As I called out in the other email, if we start
approving new bug fixes or improvements after RM starts working on release
candidates, chances are that we might end up thrashing by going after new
candidates. Since Hudi has a very active developer community, every week we
have few patches getting landed and everyone might wish to get their
patches in with the upcoming release.

Anyways, we have two options here.
1. Lets not incorporate the issues reported to vote out RC2 and proceed on
voting as usual. Lets wait to hear from other PMCs on regular voting. We
can immediately start working on 0.9.1 after 0.9.0 is officially released,
for patches that did not go into 0.9.0.
2. Make an exception just once, for the issues reported and work on RC3.

Asynchronously, brainstorm and come up with guidelines on voting

I welcome folks to chime in here.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message