*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. > > > > > >
