Ok. Thanks
> On Apr 18, 2019, at 2:34 PM, SorabhApache <[email protected]> wrote:
>
> Hi Charles,
> I don't think DRILL-7185 is a blocker bug since it's there from 1.11.0
> onwards. I will prefer for this fix to go in master branch instead of
> release branch to avoid having to prepare for RC candidate again from
> scratch (which will take another ~3 hours). In case if RC0 doesn't succeed
> then we can take this fix in next candidate. For now I am removing the
> blocker tag from it and marking it for 1.17.
>
> Thanks,
> Sorabh
>
> On Thu, Apr 18, 2019 at 11:25 AM Charles Givre <[email protected]> wrote:
>
>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
