Hi all, First of all, it's great to see us debating around ensuring high quality, timely releases. Shows we have developers who care and are passionate around the project!
Thanks for establishing the timelines, Siva. I would like to add the following data points that all 4 PRs in question (raised on the voting thread) have been submitted well after the Aug 13th cutoff date we had originally agreed upon. If there was communication to the RM or PMC before the cutoff around these JIRAs, please chime in. In the absence of this, it seems like this is an issue of some last minute feature requests and 1 hot fix around SparkSQL. I am pretty concerned about setting this precedent here, that RCs can be voted down if certain bug fixes did not make it in time. We have never encountered an issue like this before. So it's an opportunity to draft an agreed upon set of criteria for what qualifies for a valid -1, this also needs us as a community in investing in nightly integration tests, and more volunteers to ensure our tests are not flaky and exercise all complex scenarios. Without this, I think we have to enforce agreed upon timelines very stringently. I added my +1 to 0.9.0, since I perceive all 4 PRs issues to be non-blocking (even though the sparkSQL bug is a serious limitation). But, I'd still have us honor the timelines we agreed upon, rather than cut another RC3 for these. Apache Voting guidelines explicitly state that "Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision lies with the individual serving as release manager" Love to hear more from the other PMC members and the RM. Looks like the RM has the clear final decision here, unless the majority binding votes for the RC cannot be obtained from the PMC. Thanks Vinoth On Sun, Aug 22, 2021 at 1:25 PM Sivabalan <n.siv...@gmail.com> 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 > < > https://cwiki.apache.org/confluence/display/HUDI/Apache+Hudi+-+Release+Guide > >. > 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 > <https://www.apache.org/foundation/voting.html>, 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 >
