I put is as a blocker (and maybe that is overkill and if so I apologize) because I wasn’t able to actually use Drill to query my data. Drill kept crashing when I was trying to query these collection of PCAP files, which it really should have been able to read.
It literally was something as simple as adding a ‘=‘. — C > On Apr 18, 2019, at 2:23 PM, SorabhApache <[email protected]> wrote: > > 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. >>> >>> >>> >>> >>> >>>
