hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udit Mehrotra <>
Subject Re: Apache Hudi release voting process
Date Mon, 23 Aug 2021 21:25:11 GMT
Thanks Sivabalan, for starting this thread and laying out the timelines we
followed in detail. And appreciate all the community members, who are so
passionately debating to ensure a quality release.

As all of you mentioned, "-1" is an important right maintained by the
community members, but we need to clearly define what qualifies as a valid
"-1". In my limited experience working on open source, once we cut a
release and start the voting process, only regressions introduced in any of
the environments or breaking tests should be considered as valid blockers.
Any further bug fixes or improvements go with minor releases. While,
cherry-picking small PRs seems like not such a time taking process, but it
again leads to retesting of the RC, building/publishing the new release and
also opens the door for introducing further bugs. IMO we should be careful
about the precedent we will set here, because bugs/improvements will never
cease to exist in projects operating at the scale of Hudi and boundaries
will become hazy as to what qualifies as a valid blocker.

We did RC2 because we found regressions in RC1, where some of the earlier
configs could not be used with the Hudi 0.9.0 which would have broken
existing customers. The issues currently raised on RC2 are not regressions
and hence I am hesitant to block the release for that. However, I would be
more than happy to hear and consider other points of view.

Again, really encouraging to see folks having this debate, being truly
passionate about the project, and striving for the best possible release.

Udit Mehrotra
Release Manager

On Sun, Aug 22, 2021 at 1:25 PM Sivabalan <> wrote:

> 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
> <
> >.
> On
> 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
> regulations.
> I welcome folks to chime in here.
> --
> Regards,
> -Sivabalan

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