hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Li <>
Subject Re: Apache Hudi release voting process
Date Tue, 24 Aug 2021 14:25:00 GMT
Hi folks,

+1 for honoring the timeline we originally agreed on. +1 for let the RM
decide whether the PRs are blocking or not.

I understand that we have some features that are still in the fast
iteration phase and new improvements are coming out constantly. Whether the
issue is a blocking issue is a subjective question I believe. Developers
have different points of view based on the area they are working on. So I
totally understand the -1s. We want the features we developed as perfect as
possible in the official release :)

I think we could provide enough context when we vote -1s. Maybe the effects
of the last-minute PRs are more important than how it looks like and the
reviewer won't know about it unless the proposer elaborates enough context.
I encourage developers who are interested in or familiar with the PRs to
get involved and discuss the priority, so we can get more context about the
issue. Regarding whether the issue is blocking or not, I totally respect
the final decision made by the release manager.


On Tue, Aug 24, 2021 at 5:25 AM Udit Mehrotra <> wrote:

> 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.
> Thanks,
> 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