Fangjin, You wrote
> we should try to assign milestones to PRs we want > to get in Can you please define “we”? Do you mean committers, PMC members, release managers, everyone? Julian > On Nov 26, 2018, at 8:43 AM, Roman Leventov <leven...@apache.org> wrote: > > About a year ago, Gian wrote ( > https://groups.google.com/forum/#!msg/druid-development/QPZUIzLtZ2I/eZyw8BoVCgAJ > ): > > "For milestones, I think it would work to use them only for PRs/issues that > are truly release blockers -- should be limited to critical bugs discovered > after a release branch is cut. We could make release notes the way you > suggest, by walking the commit history." > > Today, Fangjin wrote ( > https://github.com/apache/incubator-druid/pull/6656#issuecomment-441698159): > > "I think where possible we should try to assign milestones to PRs we want > to get in and aim to have the PR reviewed and merged before then. If the PR > needs to be pushed back to a future release we can always do that." > > Personally I don't agree with the second take and differentiating non-bug > fixing PRs by their "importance". I think the proportion of PRs that are > assigned the next milestone by committer will depend on self-confidence of > the committer and politics, not the objective importance of the PRs. It > will also make possible for some minor PRs to be sidetracked for extremely > long time if not forever, because there always other more important PRs to > work on. While true in the short and mid run, this is very frustrating for > the authors and could turn them away from contributing into Druid, that is > bad in the long run. Actually this thing happens already sometimes and we > should think how to address that, but differentiating PRs could > only exacerbate this effect. > > Instead, I think the importance of PR should grow with the time passed > since the author addressed all comments (or just created the PR) and the PR > passed automated checks. I. e. a freshly created PR may be not super > important, but if it passes all checks and is open for two months without > reviews, the PR becomes more important to review. This should help to > reduce the variance in PR's time-to-merge and improve the average > contributor experience. In the long run I think it's healthier than > squeezing one extra feature into the very next release. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
