osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PR Milestone policy


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.