You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by James Turton <dz...@apache.org> on 2022/04/13 08:41:47 UTC
Re: Application for release manager of the next Drill release
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
>
Re: Application for release manager of the next Drill release
Posted by James Turton <dz...@apache.org>.
Hi Vitalii!
Unless something makes us change course, the two next releases are (in
my eyes).
1.20.1 (bugfix release)
2.0.0 (next major release)
James
On 2022/04/14 15:50, Vitalii Diravka wrote:
> What is the next Drill release version 1.21.0 or 2.0.0?
>
> Kind regards
> Vitalii
>
>
> On Wed, Apr 13, 2022 at 6:28 PM Jingchuan Hu <
> jingchuanhu2017@u.northwestern.edu> 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 <dz...@apache.org> 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
>>>>
>>>
Re: Application for release manager of the next Drill release
Posted by Vitalii Diravka <vi...@apache.org>.
What is the next Drill release version 1.21.0 or 2.0.0?
Kind regards
Vitalii
On Wed, Apr 13, 2022 at 6:28 PM Jingchuan Hu <
jingchuanhu2017@u.northwestern.edu> 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 <dz...@apache.org> 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
> > >
> >
> >
>
Re: Application for release manager of the next Drill release
Posted by Jingchuan Hu <ji...@u.northwestern.edu>.
Gotcha!
Best,
Jingchuan
On Wed, Apr 27, 2022 at 2:26 PM James Turton <dz...@apache.org> wrote:
> Great! I've already started down the road of building the missing Hadoop
> 3.2.3 native libs for Windows so don't duplicate that, it looks painful.
> Hopefully I'll open a PR for DRILL-8200 soon, but you can already create
> the 1.20.1 branch and start cherry picking into it before we have that.
>
> On 2022/04/27 04:37, Jingchuan Hu wrote:
> > Hi James,
> >
> > Sure, I am gonna handle this.
> >
> > Best,
> > Jingchuan
> >
> > On Tue, Apr 26, 2022 at 9:38 PM James Turton <dz...@apache.org> wrote:
> >
> >> 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 <dzamo@apache.org
> >>> <ma...@apache.org>> 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
> >>> >
> >>>
>
>
Re: Application for release manager of the next Drill release
Posted by James Turton <dz...@apache.org>.
Great! I've already started down the road of building the missing Hadoop
3.2.3 native libs for Windows so don't duplicate that, it looks painful.
Hopefully I'll open a PR for DRILL-8200 soon, but you can already create
the 1.20.1 branch and start cherry picking into it before we have that.
On 2022/04/27 04:37, Jingchuan Hu wrote:
> Hi James,
>
> Sure, I am gonna handle this.
>
> Best,
> Jingchuan
>
> On Tue, Apr 26, 2022 at 9:38 PM James Turton <dz...@apache.org> wrote:
>
>> 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 <dzamo@apache.org
>>> <ma...@apache.org>> 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
>>> >
>>>
Re: Drill 1.20.1 and some related choices to make
Posted by Jingchuan Hu <ji...@u.northwestern.edu>.
Hi James,
Maybe we could have a committer maintain the latest stable, and if there
are some weak positions needed to discuss, we could arrange a public code
review on the monthly meetup.
Best,
Jingchuan
On Tue, May 10, 2022 at 7:08 PM James Turton <ja...@somecomputer.xyz.invalid>
wrote:
> I've added a new label to GitHub called backport-to-stable which is
> intended to help us identify bug fixes that should be applied to the
> latest stable release. An alternative here is to request that devs send
> backportable fixes to the latest stable branch instead of to master,
> from whence they can get merged _forward_ into master from there without
> any need for a new backport-to-stable label. I don't know if anyone has
> any views on this? While I quite like it, I think that in reality people
> are going to continue to send PRs to master without pausing for thought
> and we should probably remain with that because it's obvious and simple.
>
> That raises another question: should the Drill committer merging a
> backportable bug fix do the cherry picking back to the latest stable
> branch on the spot? Or should all of the cherry picking be done in a
> single later pass by some other committer, as we're currently doing for
> 1.20.1? I think that the merging committer should backport the fix on
> the spot since
>
> 1. this spreads the load of maintaining the latest stable branch over
> all of us and
> 2. the merging committer is either a PR reviewer or author who has just
> perused the code involved. So they are in a strong position if the fix
> doesn't cherry pick cleanly, while one of us coming in cold later on is
> in a weaker position.
>
> Regards
> James
>
>
>
> On 2022/04/27 04:37, Jingchuan Hu wrote:
> > Hi James,
> >
> > Sure, I am gonna handle this.
> >
> > Best,
> > Jingchuan
> >
> > On Tue, Apr 26, 2022 at 9:38 PM James Turton <dz...@apache.org> wrote:
> >
> >> 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 <dzamo@apache.org
> >>> <ma...@apache.org>> 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
> >>> >
> >>>
>
>
Drill 1.20.1 and some related choices to make
Posted by James Turton <ja...@somecomputer.xyz.INVALID>.
I've added a new label to GitHub called backport-to-stable which is
intended to help us identify bug fixes that should be applied to the
latest stable release. An alternative here is to request that devs send
backportable fixes to the latest stable branch instead of to master,
from whence they can get merged _forward_ into master from there without
any need for a new backport-to-stable label. I don't know if anyone has
any views on this? While I quite like it, I think that in reality people
are going to continue to send PRs to master without pausing for thought
and we should probably remain with that because it's obvious and simple.
That raises another question: should the Drill committer merging a
backportable bug fix do the cherry picking back to the latest stable
branch on the spot? Or should all of the cherry picking be done in a
single later pass by some other committer, as we're currently doing for
1.20.1? I think that the merging committer should backport the fix on
the spot since
1. this spreads the load of maintaining the latest stable branch over
all of us and
2. the merging committer is either a PR reviewer or author who has just
perused the code involved. So they are in a strong position if the fix
doesn't cherry pick cleanly, while one of us coming in cold later on is
in a weaker position.
Regards
James
On 2022/04/27 04:37, Jingchuan Hu wrote:
> Hi James,
>
> Sure, I am gonna handle this.
>
> Best,
> Jingchuan
>
> On Tue, Apr 26, 2022 at 9:38 PM James Turton <dz...@apache.org> wrote:
>
>> 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 <dzamo@apache.org
>>> <ma...@apache.org>> 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
>>> >
>>>
Re: Application for release manager of the next Drill release
Posted by Jingchuan Hu <ji...@u.northwestern.edu>.
Hi James,
Sure, I am gonna handle this.
Best,
Jingchuan
On Tue, Apr 26, 2022 at 9:38 PM James Turton <dz...@apache.org> wrote:
> 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 <dzamo@apache.org
> > <ma...@apache.org>> 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
> > >
> >
>
Re: Application for release manager of the next Drill release
Posted by James Turton <dz...@apache.org>.
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 <dzamo@apache.org
> <ma...@apache.org>> 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
> >
>
Re: Application for release manager of the next Drill release
Posted by Jingchuan Hu <ji...@u.northwestern.edu>.
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 <dz...@apache.org> 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
> >
>
>