Slawomir, we have a fundamental problem. You want to accept PR. But I say that the purpose of PR is not to accept it because the ASFshould be always critical and therefore I think the rules cannot be written in terms "When to accept the PR". There should be rules "When not to accept the PR" because we should be critical to the PRs - that's the purpose of the existence of pull-requests. If there is no review, no comment, most probably the ASF developers should be announced, and/or it means that the business feature presented in the PR is not needed.
The ASF is responsible for the changes, not the contributor. It is no real situation to search the contributor on the plant and ask her/him to repair the fix which will cause a new bug in the future - we are responsible, the contributor is not. So we should not wait for at least one approval. We should be critical to the PRs, and if there is one -1 it means that the PR should be open as a work in progress or it should be closed. There cannot be a rule "No review" -> "wait 3 days" -> "accept" because this is the thing everybody would utilize to involve a trojan horse. T On Fri, Feb 4, 2022 at 12:12 PM Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > Hi, > Example value as 3 days or other values are to discuss and can be an agreed > value. Now such values are not important ... it will be the last item to > confirm. > > I only want to show how the process can look. > > Currently we only have sentence that we use "Commit then Review" policy > without more details > > pt., 4 lut 2022 o 11:58 Xeno Amess <xenoam...@gmail.com> napisał(a): > > > Yes, reviewing prs is time consuming, though usually worth it. > > 3 days does not seem enough for normal pr reviews I think. > > If a maintainer disagrees with this and they do think they can review > every > > prs inside the 3 days limit, then I will be glad to show him why he > can't, > > just tell me what repos he maintains. > > I do have the ability (and experience) in creating 100+ positively > > meaningful prs per day. > > > > > > Tibor Digana <tibordig...@apache.org> 于2022年2月4日周五 18:00写道： > > > > > IMHO the reactions against PRs should be technically critical. > > > IMHO the PRs from contributors should not be accepted unless there are > > > objections or pending objections. > > > Example, would you move your hand up and accept long commit in a PR > even > > if > > > you do not see the following statements? > > > *if ( cha[] == char[] )* > > > Sometimes, you need to open the PR in your IDE because GH view is pure > > for > > > complex changes. You should do everything in order to understand the PR > > and > > > you must be convinced about the proposals almost like you were the > author > > > of the PR even if you are not the author. > > > > > > > > > On Thu, Feb 3, 2022 at 12:23 PM Xeno Amess <xenoam...@gmail.com> > wrote: > > > > > > > 3 days? > > > > according to my experience, usually you need 30 - 180 days. > > > > > > > > Tibor Digana <tibordig...@apache.org> 于2022年1月28日周五 06:40写道： > > > > > > > > > It's nice to write some rules but still the developers are not > > > machines. > > > > > You can, for instance, get some vote for totally crazy things like > > > > removing > > > > > public method in a library which is widely used in ASF or in the > > world. > > > > > Yes, your right against the rules but was this according to the > best > > > > > practices, those best practices which must be learned by the > > developers > > > > for > > > > > years? > > > > > Was the public method @Deprecated before removal? > > > > > Did you check the consumers of this artifact in the Maven > repository > > > and > > > > > checked or asked the projects if it can be removed? > > > > > Did you announce the community on the site? > > > > > What if there are other deprecated methods and they have survived > > > several > > > > > releases but still not removed, and this method is going to be > > removed > > > > > without deprecation? Is it consistent in project which is used by > > > others? > > > > > These are all the things which cannot be written in the rules but > we > > > have > > > > > it somewhere in our mind. > > > > > Do you obey your internal rules? > > > > > Which have higher priority? > > > > > > > > > > I don't need to have an answer for my questions, since they are not > > > > > questions... > > > > > > > > > > T > > > > > > > > > > On Tue, Jan 25, 2022 at 8:46 PM Slawomir Jaranowski < > > > > > s.jaranow...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > On the page "Apache Maven Project Roles" [1] we have paragraph > > > > > > about Committers with: > > > > > > > > > > > > The Apache Maven project uses a Commit then Review policy and > has a > > > > > number > > > > > > of conventions which should be followed. > > > > > > > > > > > > > > > > > > Looks like Review then Commit policy is from svn time, so should > be > > > > > > refreshed or confirmed that is actual. > > > > > > > > > > > > When we want Review than Commit policy, we need some rules which > > > allow > > > > us > > > > > > to effectively work if nobody is interested for feedback. > > > > > > We also need rules / examples for direct commits, when they are > > > > > acceptable. > > > > > > > > > > > > Do we need different rules for Maven core, plugins, shared ... > etc > > > > > > > > > > > > Example of rule: > > > > > > > > > > > > PR -> no feedback for X days -> send a mail on dev@, if still > not > > > > > feedback > > > > > > after X days after mail -> proceed alone > > > > > > > > > > > > [1] https://maven.apache.org/project-roles.html#committers > > > > > > > > > > > > -- > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > > > > -- > Sławomir Jaranowski >
