Hi 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 <a...@apache.org> 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 release. > > Regards, > aditya... > > > On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > On Tue, Oct 7, 2014 at 8:41 AM, jan i <j...@apache.org> 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 anything. rgds jan i.
