incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aditya <>
Subject Re: [VOTE] Apache Drill 0.6.0-incubating release
Date Tue, 07 Oct 2014 19:24:27 GMT
Hi Jan,

The issue was discussed on the release voting thread and there seems to be
an agreement
in the community that it may not be worth holding the release to include
Java 8 support

1.) Among most of the users, as evident on the vote thread, very few are
running Java 8
in dev and test environment and even fewer are running it in production.

2.) The changes that seem to fix the test failures involves moving to a
very new release of
few libraries which are tightly integrated with Drill's core functionality
and hence we would
like to test these a bit more before merging in to a release.

3.) With our goal to have shorter and more frequent (monthly) releases, we
try to be little
judicious with picking what issue could have a wider user impact and should
be fixed immediately,
vs something which affects a very small percentage of use cases.

4.) And lastly, as Julian mentioned on the thread that the set of fixes
might not be complete yet,
I think we need more time before we can merge these changes in to a release
with confidence to
support a new platform.

I hope this persuades you to reconsider your position on this release


On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning <> wrote:

> On Tue, Oct 7, 2014 at 8:41 AM, jan i <> wrote:
> > It seems (from the vote thread) you already have solved the problem, but
> > dont want to wait for a respin, can you please at least explain why the
> > project is under such a time constraint, that 72 hours is too long to
> wait
> > to make good quality.
> >
> You have to make a cut somewhere.
> There are always a number of very small, low priority bugs and platform
> issues in any release.  Drill is now on a monthly release cycle so triaging
> a minor bug as something that doesn't stop shipping has very little
> down-side.
> On the other hand, delaying by 3+ days is more than a 10% delay in the
> monthly release.
> Your characterization of this issue being a "quality" issue is also a bit
> of an over-statement.  The problem was that several dependencies worked
> differently on Java8 than Java7.  The fix involved changing the version of
> these dependencies.  Changing dependency versions is not a small change and
> requires a full QA cycle since it takes serious thought to decide what
> impact the version change might have.  The best way for that to happen in a
> reasonable way is to simply put this fix in the next release.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message