The previous consensus community decision seems to be to not use PR milestones for any PRs except bugs. To change this policy, probably there should be a committer (or PPMC?) vote.
On Thu, 6 Dec 2018 at 20:49, Julian Hyde <jh...@apache.org> wrote: > FJ, > > What you are proposing sounds suspiciously like project management. If a > contributor makes a contribution, that contribution should be given a fair > review in a timely fashion and be committed based on its merits. You > overstate the time-sensitivity of contributions. I would imagine that there > are only a few days preceding each release where stability is a major > concern. At any other times, contributions can go in after a review. > > Remember that in Apache, no one person or group of people determines the > technical direction of the project, nor the timing of the releases. > Contributions are accepted based on merit, and release timing is determined > by consensus. > > Let’s be sure not to overuse milestone policy. Milestones should be for > guidance only. > > Julian > > > > On Dec 6, 2018, at 10:12 AM, Fangjin Yang <fang...@imply.io> wrote: > > > > Roman - one of the roles of a committer is to make decisions on what is > > best for Druid and the Druid community. If a committer feels that their > PR > > should be included in the next release, they should make an argument of > why > > that is. Conversely, if folks in the community feel that a PR should not > be > > included, they should be free to voice their opinion as well. > > > > Many of the community contributions I see today are adding value to the > > project and we should try to include them in upcoming releases. The PRs I > > see adding no value are unnecessary refactoring of that serve no real > > purpose. They don't make the code stable, easier to maintain, or add new > > features, and look to be submitted only to increase total contribution > line > > count to Druid. I think we should aim to prevent these types of PRs in > any > > release because they don't serve to benefit the community. > > > > On Tue, Dec 4, 2018 at 5:24 AM Roman Leventov <leventov...@gmail.com> > wrote: > > > >> Fangjin, what you suggest will lead to just one thing - all committers > will > >> always assign their PRs to the next release milestone. In addition, you > >> also assign PRs from non-committers to the next release milestone. So > >> nearly 100% of new PRs will have that milestone. It will make this whole > >> activity pointless, because the milestone will not tell release managers > >> anything. Except maybe creating unneeded sense of rush. > >> > >> Currently in Druid, there is a good fraction of PRs that are merged very > >> quickly (in a matter of days and sometimes hours), but there are also > quite > >> some less lucky PRs that linger for months. For contributors, it's not > very > >> important that the PR is merged in 1 hour, it's more important that it > >> appears in the next release. Therefore we need to optimize for the > fraction > >> of PRs that are merged in 1 month or less (the average time between > >> creation of a new release branch and a final release date). Reviewers > >> should schedule their time so that there are less PRs that are merged in > >> less than one day, but more PRs that are merged in less than one month. > >> > >> On Tue, 4 Dec 2018 at 04:28, Julian Hyde <jh...@apache.org> wrote: > >> > >>> 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 <fang...@imply.io> 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 <jh...@apache.org> 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 <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 > >>>>> > >>>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > >>> For additional commands, e-mail: dev-h...@druid.apache.org > >>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > For additional commands, e-mail: dev-h...@druid.apache.org > >
