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 <[email protected]> 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 <[email protected]> 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 <[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 > >>> > > >>> > >
