Hi Charles, I was about to share the RC0 candidate and just saw that you have created a blocker issue for 1.16. The JIRA doesn't have much detail as to why it is treated as blocker bug. Can you please provide more details on it ? https://issues.apache.org/jira/browse/DRILL-7185
Thanks, Sorabh On Tue, Apr 16, 2019 at 11:21 AM Sorabh Hamirwasia <[email protected]> wrote: > *Update:* > There is a blocker bug [1] found for 1.16 with TPCDS performance runs and > Gautam is working on it currently. Once that is fixed and there are no > other blocker bugs I will prepare RC0. Since the branch is already created > for 1.16.0 on apache side [2], it will be helpful if everyone can do some > initial testing. This will help to find any potential issues before RC > candidate is created and avoid delays with release. > > [1]: https://issues.apache.org/jira/browse/DRILL-7182 > [2]: https://github.com/apache/drill/commits/1.16.0 > > Thanks, > Sorabh > > On Mon, Apr 15, 2019 at 7:42 PM Ted Dunning <[email protected]> wrote: > >> >> >> On Mon, Apr 15, 2019 at 12:35 PM Sorabh Hamirwasia < >> [email protected]> wrote: >> >>> ... >>> >>> @Ted Dunning <[email protected]> - I am not sure if I understood >>> correctly but I think the reason master is locked and two active branches >>> are not chosen is to reduce the overhead of cherry-picking commits from >>> master to release branch. And also if master is not locked then the >>> scenario which Arina mentioned can still happen if a required commit for >>> 1.16 is between 2 commits intended for 1.17 only. >>> >>> For now *** Please treat master branch as locked and don't merge any >>> commit until further notice *** >>> >> >> >> Yes. I get it. I understand the lock motivation. That means that master >> is effectively a 1.16-RC branch. Somebody who needs to commit changes to >> 1.17 will (should) create a 1.17 branch from which they will eventually >> cherry-pick commits back to master. At the very least, they will have a >> private copy of master that is effectively a separate branch that they will >> have to rebase as changes go on to master to get the release in shape. >> >> This means that there *will* be at least two branches. Probably more than >> two since there is no formal place to put the 1.17 changes that are pending. >> >> As such, I would suggest that making this situation explicit and public >> would be easier for people. It would help people to either create a 1.16 >> branch, committing fixes there for RC problems and cherry-picking to or >> from master as needed OR create a 1.17 branch and use master as the 1.16 >> branch (which is a bit confusing because it changes peoples normal >> procedures). Neither strategy requires that master be locked. The former >> leaves master as the place all new stuff goes. The latter follows the "all >> development on a branch" orthodoxy. >> >> >> >> >> >>
