incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: [VOTE] Apache Drill 0.6.0-incubating release
Date Tue, 07 Oct 2014 21:46:32 GMT

First let me make it clear I am not a java specialist, and secondly big
thanks to both of you for explaining more in detail what the problem is.

On 7 October 2014 21:24, Aditya <> wrote:

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

very fair I would have done the same.

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

I agree with you in principle, but when the project have bothered to write
a unit-test case, it means its an important functionality.

> 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 agree with this, but it still does not explain why the software not
simply deny runing with java1.7+. To me it seems a simple "if" during load
could solve the problem, and is in general something a software should do
with all dependencies especially when newer versions dont work (most of us
expect newer versions to be backward compatible).

> I hope this persuades you to reconsider your position on this release
> candidate.

I hope you noted, that I just raised a concern and did not block the

> Regards,
> aditya...
> 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.

I actually agree with the above statement. A release will contain a number
of open issues, or errors yet to be found. But to me a failing unit test,
is not a low priority bug because it shows that the project feel the tested
functionality is important and if the unit test fails, the software will
fail for some users.

> >
> > On the other hand, delaying by 3+ days is more than a 10% delay in the
> > monthly release.

Is there any demand that makes it nessecary to make an exact monthly
release....or can it be 3weeks sometimes and 5weeks other times ?

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

My intentation was to raise a concern, NOT to block the release (I did on
purpose give a 0 and not -1). I am sorry if you feel its an over-statement,
but honestly for me failing unit tests and not checking a version
dependency (in case of older versions) is cause for alarm.

Java1.8 is not exactly brand new, so if the project depend on version 1.7,
I really expect the software to check the installed version, and not simply
blindly trust the users have installed whats required. In general when I
read release notes stating a version, I assume that never versions are ok.

I do agree that upgrading to a newer version requires more time and far
more testing.

I think the project is doing a fine job and look forward to give many +1 in
the future, so please dont be upset that I point out something which I feel
is important, especially since I do it in a politle way without blocking

jan i.

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