things in openjdk is if a pr cannot gain interest from any already-in members, although it might be a great pr, it is automatically-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. yep, at least one apache-committer's review is needed I think. And apache-committer is hard to become, as I myself even not being one. Tibor Digana <tibordig...@apache.org> 于2022年2月4日周五 19:46写道： > 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 > > >
