Hi Jinghcuan
As soon as we get a fix merged for DRILL-8200 [1], a high severity
security bug, how about you start cherry picking bug fixes into a 1.20.1
branch? I'm working on DRILL-8200 but we need an update of the Hadoop
"winutils" and the publisher we source those from hasn't yet uploaded
one for Hadoop 3.2.3 [2]. If they don't I'm sure we can build our own.
I'll also revisit the -hadoop2 build question.
[1] https://issues.apache.org/jira/browse/DRILL-8200
[2] https://github.com/cdarlint/winutils/issues/29
Thanks
James
On 2022/04/13 17:28, Jingchuan Hu wrote:
Hi James,
It's my great honor that I can help you with bug fix release.
For the hadoop2 support solution, maybe we could start a vote in our
community.
Best,
Jingchuan
On Wed, Apr 13, 2022 at 4:41 PM James Turton <[email protected]
<mailto:[email protected]>> wrote:
Hi Jingchuan Hu
The next major release is a long way off but, if nobody objects to the
idea, would you like to work with me to produce bug fix releases for
1.20? This is new territory for our project but I think we could start
in one of our forks by cherry picking only the bug fix commits from the
master branch to the 1.20.0 branch (the trailing .0 in that branch name
is perhaps a little unfortunate) that was created by the last major
release. We can then open a PR to the 1.20.0 branch in the main repo
and do a review. Once that's approved and merged we can attach a new
tag of drill-1.20.1 and then do the Maven release plugin
incantations to
produce and upload the new build artifacts. As we go we can document
and script the process in the way that the major release process has
been.
We'll naturally be led to revisit the -hadoop2 build in the process,
which is a good thing because it is unsatisfactory in its current form
which creates a whole new version of Drill (1.20.0-hadoop2), including
source control features like the branch and tag, and is not sensible
since this is only a build of 1.20.x under a different profile, not
some
independent version of Drill. Unfortunately the Maven release plugins
we use didn't seem to support this scenario, at least when I looked
while releasing 1.20, so one possibility here is that the project
decides to provide Hadoop 2 support in source form only: users who want
to run with Hadoop 2 must build themselves. We would not be the only
Apache project to do this see e.g. HBase, Phoenix. Or, half way, we
provide a deployable tarball for -hadoop2 but that's it, we don't
populate our Maven repo with the corresponding artifacts.
James
On 2022/03/20 17:15, Jingchuan Hu wrote:
> Hi team,
>
> I am here to apply for the role as the release manager of the
next drill
> release.
>
> As a newcomer to the Drill community. I tried to help the
community to get
> known by more users through the Drill web-site Chinese version setup.
> Committed several PRs for Drill bug fix. Also, helped to
summarize the
> keynotes of Drill online meetup for our community members to
easily "Async"
> with Drill activities. And I want to keep those contributions
with better
> quality in the future.
>
> Over the six months after I joined the community, I am deeply
impressed by
> our community member's dedication and intelligence. No matter
whether I
> could be the release manager, I hope that I can grow with Drill.
>
> If there are some suggestions for me, I would really appreciate it.
>
> Sincerely,
> Jingchuan
>
