Re: About creating 0.12.2-rc1
+1, and fwiw, it looks like Apache projects don't always need to do votes for creating release candidates. For example on the Calcite mailing list I see votes for _final_ releases, but the release candidates seem to be created and uploaded without a vote. There is generally some discussion on the list about whether it's a good time to do a release candidate, but I don't generally see formal votes. I think something similar could work for us in the future and could help us get releases out quicker. On Fri, Aug 3, 2018 at 9:38 PM Prashant Deva wrote: > +1 > Prashant > > > On Fri, Aug 3, 2018 at 7:11 PM Niketh Sabbineni < > niketh.sabbin...@gmail.com> > wrote: > > > +1 > > > > Looking forward to this > > > > On Fri, Aug 3, 2018 at 7:09 PM Jihoon Son wrote: > > > > > Hi folks, > > > > > > Releasing 0.12.2 has been delayed because, fortunately, we could find > > more > > > bugs to be fixed before release. > > > > > > Currently, there remains only one PR ( > > > https://github.com/apache/incubator-druid/pull/6106 ) to be merged for > > > 0.12.2. Once the Travis CI passes, I'll merge that PR shortly. Then, > > we're > > > ready for 0.12.2-rc1 release. > > > > > > So, I think it's time to ask your opinion about creating 0.12.2-rc1 > > without > > > the release vote. I think it makes sense because we have already had > two > > > votes ( > > > > > > > > > https://lists.apache.org/thread.html/a96f2e39506118be26184bd950bc51d360107d75e9ac547d8597817a@%3Cdev.druid.apache.org%3E > > > , > > > > > > > > > https://lists.apache.org/thread.html/11a50f22e7669a527625e190bebbe50b7586dd72733c3bf6a1024c02@%3Cdev.druid.apache.org%3E > > > ) > > > for 0.12.2-rc1 release and there's no objection. > > > > > > If there's no objection for this for 48 hours, I'll start 0.12.2-rc1 > > > release. > > > > > > Best, > > > Jihoon > > > > > -- > > Niketh Sabbineni > > >
Re: About creating 0.12.2-rc1
Gian is correct. Creating an RC doesn’t require a vote. It does require a release manager. Usually in Calcite we determine the timeframe of the release, and choose an RM, by a discussion that reaches consensus without an explicit vote. The RM may do a little “traffic control”, asking whether people consider the branch is in good shape, and perhaps asking people to stop pushing, again by a non-vote email thread. Julian > On Aug 5, 2018, at 8:56 AM, Gian Merlino wrote: > > +1, and fwiw, it looks like Apache projects don't always need to do votes > for creating release candidates. For example on the Calcite mailing list I > see votes for _final_ releases, but the release candidates seem to be > created and uploaded without a vote. There is generally some discussion on > the list about whether it's a good time to do a release candidate, but I > don't generally see formal votes. I think something similar could work for > us in the future and could help us get releases out quicker. > > On Fri, Aug 3, 2018 at 9:38 PM Prashant Deva > wrote: > >> +1 >> Prashant >> >> >> On Fri, Aug 3, 2018 at 7:11 PM Niketh Sabbineni < >> niketh.sabbin...@gmail.com> >> wrote: >> >>> +1 >>> >>> Looking forward to this >>> On Fri, Aug 3, 2018 at 7:09 PM Jihoon Son wrote: Hi folks, Releasing 0.12.2 has been delayed because, fortunately, we could find >>> more bugs to be fixed before release. Currently, there remains only one PR ( https://github.com/apache/incubator-druid/pull/6106 ) to be merged for 0.12.2. Once the Travis CI passes, I'll merge that PR shortly. Then, >>> we're ready for 0.12.2-rc1 release. So, I think it's time to ask your opinion about creating 0.12.2-rc1 >>> without the release vote. I think it makes sense because we have already had >> two votes ( >>> >> https://lists.apache.org/thread.html/a96f2e39506118be26184bd950bc51d360107d75e9ac547d8597817a@%3Cdev.druid.apache.org%3E , >>> >> https://lists.apache.org/thread.html/11a50f22e7669a527625e190bebbe50b7586dd72733c3bf6a1024c02@%3Cdev.druid.apache.org%3E ) for 0.12.2-rc1 release and there's no objection. If there's no objection for this for 48 hours, I'll start 0.12.2-rc1 release. Best, Jihoon >>> -- >>> Niketh Sabbineni >>> >> - To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
0.10.1 and 0.12.2 group by/search/select/top n query results
I have an internal test harness setup that I am using for testing version
upgrade from Druid 0.10.1 to 0.12.2. As part of the testing, I noticed that
executing the same query against the same data source gives slightly
different results for 0.10.1 and 0.12.2. I have seen this happen for
search, group by, top n, select query types. The common part in all such
queries is that they have a paging spec with descending set to false.
"pagingSpec": {"pagingIdentifiers": {}, "threshold": 5000}
"desceding": false
My guess is that the data is distributed slightly differently within the
two clusters which is causing this mismatch. Is my guess correct? If so, is
there a way to make this comparison deterministic.
The other thing that I observed is that with doubleSum aggregation type,
0.10.1 is returning values with lower precision (ex - 616346.0) as opposed
to 0.12.1 (ex - 616346.0208094628). Did something change to cause this
change in precision?
Different query results for 0.12.2 and 0.10.1
I have an internal test harness setup that I am using for testing version
upgrade from Druid 0.10.1 to 0.12.2. As part of the testing, I noticed that
executing the same query against the same data sources(on different druid
clusters) gives slightly different results for 0.10.1 and 0.12.2. I have
seen this happen for search, group by, top n, select query types. The
common part in all such queries is that they have a paging spec with
descending set to false.
"pagingSpec": {"pagingIdentifiers": {}, "threshold": 5000}
"desceding": false
My guess is that data distribution is slightly differently within the two
clusters which combined with paging spec is causing this mismatch. Is my
guess correct? If so, is there a way to make such kind of testing
deterministic.
The other thing that I observed is that with doubleSum aggregation type,
0.10.1 is returning values with lower precision (ex - 616346.0) as opposed
to 0.12.1 (ex - 616346.0208094628). Did something change to cause this
change in precision?
