Jan, Your concern was a valid one and definitely one worth explanation.
Please do not take my response as a rant from an upset soul :), rather an explanation towards why we chose to do what we did. I apologize if I sounded like one. We are, sometime, limited by the tools that we use and one such limitation of maven's unit test framework which Drill uses is that there is no clean way to enforce upper bound on Java version during test execution. And in the spirit of exploration and tinkering, among the core tenets of open source philosophy, I do not think we should block anyone from trying something unknown, a new platform in this case. We do though, test for and indicate for the known incompatibility. However, I do agree that a well defined list of supported platform helps minimize confusion and makes the users' life a tad easier. To that effect, we will keep the list up-to-date. We thank you and look forward to your participation in our discussions in future. Regards, aditya... On Tue, Oct 7, 2014 at 2:46 PM, jan i <j...@apache.org> wrote: > 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. >
