Dear all, I am just bystander on Druid List however I like to contribute code to Druids some day because it is very great, we use it at my company. It sounds consensus was reached that Github milestones should be used not so frequently and is proposed vote about to change this.. is this correct?
Regards, Jay On 2018/12/12 00:39:29, Jonathan Wei <j...@apache.org> wrote: > After a PR has been reviewed and merged, I think we should tag it with the> > upcoming milestone to make life easier for release managers, for all PRs.> > > Regarding unresolved PRs:> > > > I advocate for not assigning milestones to any non-bug (or otherwise> > "critical") PRs, including "feature", non-refactoring PRs.> > > That seems like a reasonable policy to me, based on the points Roman made> > in the thread.> > > On Tue, Dec 11, 2018 at 1:13 AM Julian Hyde <jh...@apache.org> wrote:> > > > Well, see if you can get consensus around such a policy. Other Druid> > > folks, please speak up if you agree or disagree.> > >> > > > On Dec 8, 2018, at 8:02 AM, Roman Leventov <le...@gmail.com>> > > wrote:> > > >> > > > It's not exactly and not only that. I advocate for not assigning> > > milestones> > > > to any non-bug (or otherwise "critical") PRs, including "feature",> > > > non-refactoring PRs.> > > >> > > > On Fri, 7 Dec 2018 at 19:29, Julian Hyde <jh...@apache.org> wrote:> > > >> > > >> Consensus.> > > >>> > > >> We resolve debates by going into them knowing that we need to find> > > >> consensus. A vote is a last step to prove that consensus exists, and> > > >> in most cases is not necessary.> > > >>> > > >> Reading between the lines, it sounds as if you and FJ have a> > > >> difference of opinion about refactoring changes. Two extreme positions> > > >> would be (1) we don't accept changes that only refactor code, (2) and> > > >> I assert my right to contribute a refactoring change at any point in> > > >> the project lifecycle. A debate that starts with those positions is> > > >> never going to reach consensus. A better starting point might be "I> > > >> would like to make the following change because I believe it would be> > > >> beneficial. How could I best structure it / time it to minimize> > > >> impact?"> > > >> On Fri, Dec 7, 2018 at 9:19 AM Roman Leventov <le...@gmail.com>> > > >> wrote:> > > >>>> > > >>> I would like like learn what is the Apache way to resolve debates. But> > > >> you> > > >>> are right, this question probably doesn't deserve that. Thanks for> > > >> guidance> > > >>> Julian.> > > >>>> > > >>> On Fri, 7 Dec 2018 at 16:43, Julian Hyde <jh...@gmail.com>> > > wrote:> > > >>>> > > >>>> May I suggest that a vote is not the solution. In this discussion I> > > see> > > >>>> two people beating each other over the head with policy.> > > >>>>> > > >>>> Let’s strive to operate according to the Apache way. Accept> > > >> contributions> > > >>>> on merit in a timely manner. Avoid the urge to “project manage”.> > > >>>>> > > >>>> Julian> > > >>>>> > > >>>>> On Dec 7, 2018, at 07:03, Roman Leventov <le...@gmail.com>> > > >> wrote:> > > >>>>>> > > >>>>> 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 <fa...@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 <fa...@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> > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>> ---------------------------------------------------------------------> > > >>>> 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> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
