osdir.com

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

Re: PR Milestone policy


I agree with you that merging PRs promptly is very important for growing community. Or, if the PR is inadequate, promptly explain to the contributor what they can do to improve it.

Assigning target milestones to bugs and issues that don’t yet have PRs can be problematic. The person assigning the milestone has stepped into the role of project manager, unless they are committing to fix the issue personally. And even then, they are implicitly saying “hold the release while I work on this code”, which should really be the responsibility of the release manager alone.

Julian




> On Dec 3, 2018, at 1:57 PM, Fangjin Yang <fangjin@xxxxxxxx> wrote:
> 
> Committers. In general I think we should try to be more inclusive of the
> community and people that are interested in contributing to Druid and try
> to get their PRs in as much as possible. This helps to grow the community.
> To me, this means assigning milestones to contributions, not being overly
> picky on code (if it has no real impact on functionality/performance). If
> we need to push PRs back to a later release because they are complicated
> and require more review, we can always do that.
> 
> On Tue, Nov 27, 2018 at 4:45 PM Julian Hyde <jhyde@xxxxxxxxxx> wrote:
> 
>> 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 <leventov@xxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxx
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxx