Huge +1 to "We should stress out that a patch should be committed if and only if committer is confident with the changes."
On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov <voze...@gridgain.com> wrote: > Hi, > > This is tough question, and first of all I'd like to ask participants to > keep cold head. This is a public question and can be discussed on the dev > list safely. > > On the one hand, it is true that a number of patches are not reviewed for a > long time, what negatively affects community development. On the other > hand, we definitely do not want to sacrifice product quality only because > e.g. responsible component owner was on a sick leave or vacation and was > not able to review the patch in a timely manner. Some compromise is needed. > > IMO additional comments in HTC may solve the issue. We should stress out > that a patch should be committed if and only if committer is confident with > the changes. Confidence comes from either experience (you worked with > component a lot and know what you are doing), or from review by component's > expert. But if there is an outdated patch and you are not confident enough, > just don't merge. Let is stay in Patch Available as long as needed. > > In case of lazy consensus we may ask committers to add comments to the > ticket explaining why they decided to merge a ticket without expert's > review. This should help us avoid bad commits. > > Thoughts? > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov <a...@apache.org> wrote: > > > Dmitry, > > > > Phrase "Code modifications can be approved by silence: by lazy consensus > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > Please roll back the changes and start the discussion at the private list > > and never do such updates in the future without the discussion. > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov <dpav...@apache.org> > wrote: > > > > > Hi Igniters, > > > > > > sorry for the late reply. Because this process time to time causes > > > questions, I decided to add a couple of words to our wiki. > > > > > > I've added topics about peer review to HTC > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > > > Actually, it is (more or less) rules of Apache Beam project, as well as > > > Apache Training(incubating), as well as our current process + Apache > > > policies. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov <yzhda...@apache.org>: > > > > > > > Dmitry, > > > > > > > > I like your suggestion very much! And I want everyone to follow. > Let's > > > see > > > > if it helps. > > > > > > > > Can I ask everyone who has submitted tickets for review to add a > > comment > > > > described by Dmitry to each ticket submitted and see if any > additional > > > > check is still required and fix remaining issues? I believe this > should > > > > speed up review process very much. > > > > > > > > --Yakov > > > > > > > > > >
