> I bet it is impossible to set "code of conduct" that makes everybody is happy Agreed, although we may be able to agree on a minimum standard.
> Would you call me violent if I just commit the proper fix and ignore PR802? I don't think anyone was suggesting violence. > What if I have committed the fix yesterday? > What if I have committed the fix a couple of days ago? I don't think the issue here is timing so much as that in the case of CALCITE-2327, there was no effort made to run the fix past Zoltan before committing (please correct me if I'm wrong). In general, I think waiting a day or two is reasonable. Even if someone isn't able to respond in that window, I think people will appreciate that a heads up was given. -- Michael Mior [email protected] Le mer. 29 août 2018 à 04:00, Vladimir Sitnikov <[email protected]> a écrit : > Julian>If you had just said “Hey Zoltan, I think I’ve come up with a better > fix than your PR; do you mind if I commit it?” then Zoltan would have said > “Sure”. > > While I agree with general points (tough I bet it is impossible to set > "code of conduct" that makes everybody is happy), however reality is not > black and white. > > What is the timeout for the answer? > Does "absence of answer within 2 hours" count as "sure"? > Does "absence of answer within 24 hours" count as "sure"? > Does "absence of answer within 48 hours" count as "sure"? > ... > > Here's an (on-going!) example: > https://issues.apache.org/jira/browse/CALCITE-2484 (Dynamic table tests > give wrong results when running tests concurrently) > There's a bug, there's PR. > > I have reviewed the PR and suggested changes. JIRA reads that my review was > "4 days ago". > Would you call me violent if I just commit the proper fix and ignore PR802? > What if I have committed the fix yesterday? > What if I have committed the fix a couple of days ago? > > In both cases, PR/Issue author puts no warnings to the issue/pr that > suggest if (s)he is actively working on the problem. > > I do agree it feels bad when your work (issue comments, code changes) is > discarded. However, people make mistakes, so it might happen they raise > tickets/do code changes that should never be made in the first place > (==>those changes are doomed to be discarded). > > Vladimir >
