Looks like three committers (Jonathan, Mingming and I) voted for the policy
of not adding non bug and security PRs to milestones before merging.
One (Gian) abstained. Therefore I included this in the PR action item list
for committers: https://github.com/apache/incubator-druid/pull/7279 please
My feeling is that setting a milestone on PRs before they're merged is a
way of making their authors feel more included. I don't necessarily see a
problem with setting milestones optimistically and then, when a release
branch is about to be cut (based on the timed release date), we bulk-update
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
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",
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 wrote:
> Consensus.
>
> We resolve debates by going into them knowing that we need to find
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 wrote:
> May I suggest that a vote is not the solution. In this discussion I see
> two people
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 wrote:
> FJ,
>
> What you are proposing sounds suspiciously like project
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
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
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
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
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 wrote:
>
> About a year ago, Gian wrote (
>
12 matches
Mail list logo
