Re: Contribution and committer guidelines

Vlad, We are discussing what qualifies as " technical justification". The proposal also is for putting a time bound on the process. Amol On Mon, Jan 28, 2019 at 1:36 PM Pramod Immaneni wrote: > On Mon, Jan 28, 2019 at 12:45 PM Vlad Rozov wrote: > > > IMO, the performance criteria is quite

Re: Contribution and committer guidelines

On Mon, Jan 28, 2019 at 12:45 PM Vlad Rozov wrote: > IMO, the performance criteria is quite vague and it needs to be taken on a > case by case basis. Fixing not critical bug or adding minor functionality > is different from fixing security issue or data loss/corruption and while > the first one

Re: Contribution and committer guidelines

It was always the case that -1 needs to be accompanied by justification [1]. I don’t recollect any PR where it was stopped by a veto due to missing code refactoring. VETOS A code-modification proposal may be stopped dead in its tracks by a -1

Re: Contribution and committer guidelines

Vlad, This thread is in regards to code review itself, and we are discussing what conditions can a reviewer do a -1. In case a reviewer is ignoring the new policies and continues to give -1 using previous thought process, we will need to have a mechanism where the -1 is overridden. -1 needs an

Re: Contribution and committer guidelines

IMO, the performance criteria is quite vague and it needs to be taken on a case by case basis. Fixing not critical bug or adding minor functionality is different from fixing security issue or data loss/corruption and while the first one never justifies performance degradation, the second one

Re: Contribution and committer guidelines

Amol regarding performance my thoughts were along similar lines but was concerned about performance degradation to the real-time path, that new changes can bring in. I would use stronger language than "do not degrade current performance significantly" at least for the real-time path, we could say

Re: Contribution and committer guidelines

Is there an example from prior PRs where it was not accepted/merged due to a disagreement between a contributor and a committer on the amount of refactoring or code quality? Thank you, Vlad > On Jan 27, 2019, at 06:56, Chinmay Kolhatkar > wrote: > > +1. > > On Sat, 26 Jan 2019, 11:56 pm