hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinoth Chandar <vin...@apache.org>
Subject Re: [VOTE] Release 0.9.0, release candidate #2
Date Mon, 23 Aug 2021 01:08:58 GMT
+1 (binding)

RC check [1] passed

[1] https://gist.github.com/vinothchandar/68b34f3051e41752ebffd6a3edeb042b


On Sun, Aug 22, 2021 at 1:28 PM Sivabalan <n.siva.b@gmail.com> wrote:

> We can keep the specific discussion out of this voting thread. Have started
> a new thread here
> <
> https://lists.apache.org/thread.html/r3bae7622904b04c7d1fb2ddaf5226e37166d5fbb1721f403b1b04545%40%3Cdev.hudi.apache.org%3E
> >
> to
> continue this discussion. We can keep this thread just for voting. Thanks.
>
> On Sun, Aug 22, 2021 at 2:13 AM Danny Chan <danny0405@apache.org> wrote:
>
> > It's not a surprise that 0.9 has a longer release process, the Spark SQL
> > was added and many promotions from the Flink engine. We need more
> patience
> > for this release IMO.
> >
> > Having another minor release like 0.9.1 is a solution but not a good one,
> > people have much more promise to the major release and it carries
> > many expectations. If people report the problems during the release
> > process, just accept it if it is not a big PR/fix, and there are only a
> few
> > ones up to now. I would not take too much time.
> >
> > I know that it has been about 4 months since the last release, but people
> > want a complete release version not a defective one.
> >
> > Best,
> > Danny
> >
> > Sivabalan <n.siva.b@gmail.com> 于2021年8月22日周日 上午11:50写道:
> >
> > > I would like to share my thoughts on the release process in general. I
> > will
> > > read more about what exactly qualifies for -1 and will look into what
> > Peng
> > > and Danny has put up. But some thoughts on the release in general.
> > >
> > > Every release process is very tedious and time consuming and RM does
> put
> > in
> > > non-trivial amount of work in getting the release out. To make the
> > process
> > > smooth, RM started an email thread by Aug 3, calling for any release
> > > blockers. Would like to understand, if these were surfaced in that
> > thread?
> > > What I am afraid of is, we might keep delaying our release by adding
> more
> > > patches/bug fixes with every candidate. For instance, if we consider
> > these
> > > and RM works on RC3 and puts up a vote in 5 days and what if someone
> else
> > > wants to add a couple of more fixes or improvements to the release? If
> > it's
> > > a very serious bug that one cannot do basic operations like
> insert/upsert
> > > in any of the engines or some serious regression, yeah we can
> definitely
> > > block the release. But if there are corner case bugs, or any
> improvements
> > > in general, we can always have another release immediately following
> > this.
> > > This is my humble opinion having gone through the release process
> myself
> > in
> > > the past and have helped others in doing the release in Hudi. It's been
> > > more than 4 months we have had a release. Would be good for us to be
> > > mindful of that as well. Maybe this is common in other projects, but I
> am
> > > not aware of that. Please enlighten me if you have experience with
> other
> > > projects.
> > >
> > > I would like to hear from other PMCs and experts who are more
> > > knowledgeable about the release process.
> > > And if anyone has any suggestions on improving the release process in
> > > general (if we can seal the patches that go into a release upfront,
> > etc), I
> > > am all ears to that as well.
> > >
> > >
> > > On Sat, Aug 21, 2021 at 10:41 PM Danny Chan <danny0405@apache.org>
> > wrote:
> > >
> > > > I have fired a cherry-pick PR:
> > https://github.com/apache/hudi/pull/3519
> > > >
> > > > Best,
> > > > Danny
> > > >
> > > > Danny Chan <danny0405@apache.org> 于2021年8月22日周日 上午9:07写道:
> > > >
> > > > > I'm sorry I would also vote -1.
> > > > >
> > > > > HUDI-2316
> > > > > HUDI-2340
> > > > > HUDI-2342
> > > > >
> > > > > are all important improvements for Flink and we hope they can be
> > > > > cherry picked to release 0.9.
> > > > >
> > > > > Best,
> > > > > Danny
> > > > >
> > > > > Udit Mehrotra <uditme@apache.org> 于2021年8月21日周六
上午7:13写道:
> > > > >
> > > > >> Hi everyone,
> > > > >>
> > > > >> Please review and vote on the release candidate #2 for the version
> > > > 0.9.0,
> > > > >> as follows:
> > > > >>
> > > > >> [ ] +1, Approve the release
> > > > >>
> > > > >> [ ] -1, Do not approve the release (please provide specific
> > comments)
> > > > >>
> > > > >> The complete staging area is available for your review, which
> > > includes:
> > > > >>
> > > > >> * JIRA release notes [1],
> > > > >>
> > > > >> * the official Apache source release and binary convenience
> releases
> > > to
> > > > be
> > > > >> deployed to dist.apache.org [2], which are signed with the key
> with
> > > > >> fingerprint 44A484600E48193A74F97447C47E66F8386204DF [3],
> > > > >>
> > > > >> * all artifacts to be deployed to the Maven Central Repository
> [4],
> > > > >>
> > > > >> * source code tag "release-0.9.0-rc2" [5],
> > > > >>
> > > > >> The vote will be open for at least 72 hours. It is adopted by
> > majority
> > > > >> approval, with at least 3 PMC affirmative votes.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Release Manager
> > > > >>
> > > > >> [1]
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12322822&version=12350027
> > > > >>
> > > > >> [2] https://dist.apache.org/repos/dist/dev/hudi/hudi-0.9.0-rc2/
> > > > >>
> > > > >> [3] https://dist.apache.org/repos/dist/dev/hudi/KEYS
> > > > >>
> > > > >> [4]
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachehudi-1043/
> > > > >>
> > > > >> <
> > > > >>
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachehudi-1042/org/apache/hudi/
> > > > >> >[5]
> > > > >> https://github.com/apache/hudi/tree/release-0.9.0-rc2
> > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > -Sivabalan
> > >
> >
>
>
> --
> Regards,
> -Sivabalan
>

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