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 <cgi...@gmail.com> 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 <sor...@apache.org> 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 < > sohami.apa...@gmail.com> > > 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 <ted.dunn...@gmail.com> > wrote: > >> > >>> > >>> > >>> On Mon, Apr 15, 2019 at 12:35 PM Sorabh Hamirwasia < > >>> sohami.apa...@gmail.com> wrote: > >>> > >>>> ... > >>>> > >>>> @Ted Dunning <ted.dunn...@gmail.com> - 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. > >>> > >>> > >>> > >>> > >>> > >>> > >
