Re: Contributing an extension
Hi Eyal, Thanks for the contrib, I'll have some time to start reviewing in the next week or two. It seems like a cool feature with interest from users, so I'd lean towards keeping it open for review/merge. Best, Jon On Tue, Jan 29, 2019 at 5:29 PM Eyal Yurman wrote: > Hi, > > This pr is waiting for a few months for review: > https://github.com/apache/incubator-druid/pull/6430 > https://github.com/apache/incubator-druid/issues/6320 > > So far only one reviewer (@b-slim) was kind enough to start looking at it. > > Since this is an contrib extension, it is not really blocking me (It is in > production for the past 2 years...). But I have noticed a large number of > users commenting/emojiing the PR/issue, so I think the community would > appreciate it if this would be released. > > Since this is an extension, would you say it's better if I release it in my > company's own repository, or should I continue to request review and merge? > > Thanks! > > Eyal. >
Contributing an extension
Hi, This pr is waiting for a few months for review: https://github.com/apache/incubator-druid/pull/6430 https://github.com/apache/incubator-druid/issues/6320 So far only one reviewer (@b-slim) was kind enough to start looking at it. Since this is an contrib extension, it is not really blocking me (It is in production for the past 2 years...). But I have noticed a large number of users commenting/emojiing the PR/issue, so I think the community would appreciate it if this would be released. Since this is an extension, would you say it's better if I release it in my company's own repository, or should I continue to request review and merge? Thanks! Eyal.
Re: Contributing an extension
Hi Eyal, I'll take a look too. For some reason I missed this when you first posted it, but it is very interesting work, and looks like it could be part of a path to supporting generic windowed aggregations in Druid SQL. (Moving average, cumulative sum, and so on) On Tue, Jan 29, 2019 at 7:07 PM Jihoon Son wrote: > Sorry for delayed review. I'll take a look once the 0.14.0 release is > finished. > > Jihoon > > On Tue, Jan 29, 2019 at 3:58 PM Eyal Yurman > wrote: > > > Hi, > > > > A few months ago I worked on open sourcing an extension we've been using > > internally for a couple of years. > > > > https://github.com/apache/incubator-druid/pull/6430 > > https://github.com/apache/incubator-druid/issues/6320 > > > > This has been upvoted by a few community users, so I was happy to put in > > the effort. > > > > Unfortunately, I haven't found any committer who could spend the time > > reviewing this work... > > > > Is there anyone who could do that sometime next month? > > > > I could always release it under a separate repository, but since I am > > committed to continuing maintaining and expanding the module, I'd prefer > to > > keep it as part of the Druid codebase. > > > > Thanks! > > > > Eyal. > > >
Regarding the proposal for Consolidated segment metadata management
Hi all, I wrote a proposal for consolidated segment metadata management a few weeks ago. Since it's also a huge and incompatible change, I would like to get more attention from others. As described in the proposal, Druid currently stores segment metadata in two places: metadata store and deep storage. This design has some drawbacks like not easy to keep them synced. To solve this problem, the proposal proposes to store the segment metadata in only metadata store. As a result, insert-segment-to-db tool should be removed together because it depends on the segment metadata in deep storage. Please take a look and let me know what you think. Thanks, Jihoon
Re: Contributing an extension
Sorry for delayed review. I'll take a look once the 0.14.0 release is finished. Jihoon On Tue, Jan 29, 2019 at 3:58 PM Eyal Yurman wrote: > Hi, > > A few months ago I worked on open sourcing an extension we've been using > internally for a couple of years. > > https://github.com/apache/incubator-druid/pull/6430 > https://github.com/apache/incubator-druid/issues/6320 > > This has been upvoted by a few community users, so I was happy to put in > the effort. > > Unfortunately, I haven't found any committer who could spend the time > reviewing this work... > > Is there anyone who could do that sometime next month? > > I could always release it under a separate repository, but since I am > committed to continuing maintaining and expanding the module, I'd prefer to > keep it as part of the Druid codebase. > > Thanks! > > Eyal. >
Contributing an extension
Hi, A few months ago I worked on open sourcing an extension we've been using internally for a couple of years. https://github.com/apache/incubator-druid/pull/6430 https://github.com/apache/incubator-druid/issues/6320 This has been upvoted by a few community users, so I was happy to put in the effort. Unfortunately, I haven't found any committer who could spend the time reviewing this work... Is there anyone who could do that sometime next month? I could always release it under a separate repository, but since I am committed to continuing maintaining and expanding the module, I'd prefer to keep it as part of the Druid codebase. Thanks! Eyal.
Re: Dev sync this week
sorry, yes, that is the information I meant. that Feature Freeze is in its final stages On Tue, Jan 29, 2019 at 12:21 PM David Glasser wrote: > On Tue, Jan 29, 2019 at 10:45 AM Charles Allen > wrote: > >* *0.14 *release is in final stages, any blockers for 0.14 should be > called out to the dev list. > > Can you clarify this? I don't think a 0.14 branch has been cut yet — > things that land on master soon are likely to make it in, right? > > --dave (hoping a tiny approved PR of his makes it :) ) > > - > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > For additional commands, e-mail: dev-h...@druid.apache.org > >
Re: Dev sync this week
On Tue, Jan 29, 2019 at 10:45 AM Charles Allen wrote: >* *0.14 *release is in final stages, any blockers for 0.14 should be called >out to the dev list. Can you clarify this? I don't think a 0.14 branch has been cut yet — things that land on master soon are likely to make it in, right? --dave (hoping a tiny approved PR of his makes it :) ) - To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
Re: The etiquette of pocking people on Github and the policy when people stop responding
> I disagree with Roman's suggestions. If a PR has enough votes, we should > trust the committers approving the PR and move forward. FWIW, I do think it's good to be courteous and give other reviewers a day or two to either follow up on a review or decide to leave the decision to the reviewers that have already chimed in. I just think that allowing two weeks for that is excessive and would lead to PRs languishing in the queue even more than they do now. On Mon, Jan 28, 2019 at 1:30 PM Fangjin Yang wrote: > I disagree with Roman's suggestions. If a PR has enough votes, we should > trust the committers approving the PR and move forward. > > On Mon, Jan 28, 2019 at 9:28 AM Gian Merlino wrote: > > > I don't think it's irresponsible to start a review and not be able to > > finish it promptly. But drawing the process out can feel frustrating to > > other committers that have already finished reviewing, like they are > being > > told that their review is not good enough. I think it's a matter of > degree. > > Two weeks sounds very long to me but two or three days sounds reasonable. > > Part of the rationale for this is that PR review is an iterative process. > > If each iteration could take two weeks then a patch might not be > committed > > for months. (This happens sometimes, and it is sad, and sometimes I've > been > > on the guilty end of it, and it's something I think we should try to > avoid > > by endeavoring to speed up review cycles.) > > > > It's a totally different situation if nobody else has reviewed a patch > yet. > > In that case a reviewer reviewing things with longer cycles isn't > blocking > > anything. They are actually helping a lot by being the only person > willing > > to review the patch at all. In this case I think the etiquette and > timings > > you suggested are more reasonable. > > > > I guess that reviewers prioritize the newest PRs first because of how the > > GitHub UI works. By default it sorts PRs by created date, newest first. > And > > it doesn't have an option to sort by "most time elapsed since review". > > Maybe we should make our own review console that sorts the PRs > differently? > > Or shoot for PR-zero (like inbox-zero): close all PRs that haven't had > > comments in 6 months and try to review all the others as fast as > possible. > > > > On Mon, Jan 28, 2019 at 8:43 AM Roman Leventov > > wrote: > > > > > On Fri, 25 Jan 2019 at 23:12, Gian Merlino wrote: > > > > > > > If enough other committers have already reviewed and accepted a > patch, > > I > > > > don't think it's fair to the author or to those other reviewers for > > > > committing to be delayed by two weeks because another committer > doesn't > > > > have time to finish reviewing, but wants others to wait for them > > anyway. > > > > > > > > > It sounds like it's implied that the reviewer is irresponsible because > he > > > started reviewing a PR but "doesn't have time to finish reviewing". In > > > fact, a reviewer could *have* time to finish reviewing and is willing > to > > > finish the review, but they don't have time *tomorrow*. A reviewer > could > > > have different duties and could slice only Y hours for reviews of Druid > > PRs > > > every X days. X/(Y * number of PRs the reviewer is interested in at the > > > moment) is how often (in days) a reviewer could pay attention to > specific > > > PR. I think we should respect that for some people, at least at some > > times, > > > this value could grow to about 7. Saying that we shouldn't wait for > those > > > people creates a bias favoring most involved developers, and it's not > > > necessarily a good bias, because sometimes outsider (or half-outsider) > > > perspective is valuable. > > > > > > If we do releases every 3 months and the time between creating a > release > > > branch and the final release candidate is at least 3 weeks > > (historically), > > > why there is an urge to commit anything faster. > > > > > > IMO the real source of unfairness in reviews is that reviewers > generally > > > prioritize the newest PRs rather than PRs that await for reviews the > > > longest. The probability that somebody starts to review a PR decreases > > with > > > time, while it should increase. > > > > > >
Re: Proposal to shade Guava manually in Druid
Interesting proposal - I commented on the issue. It sounds like a good idea. On Tue, Jan 29, 2019 at 7:22 AM Roman Leventov wrote: > https://github.com/apache/incubator-druid/issues/6942 >
Proposal to shade Guava manually in Druid
https://github.com/apache/incubator-druid/issues/6942
