Hi Xeno, The openjdk would close such a PR which has no attention. I am keeping it open if it is not necessary to close it, and I am doing it because I respect the time the contributor has spent on it and I want to give him a chance to continue or open a discussion. Yesterday I closed one old PR because Maven 3.0.5 is obsolete which is proven on our pages, it was necessary to close it. <- corner case!!!
IMHO, the rules for people should be written very slowly, they should be verified in practice step by step. For sure, if I have to write them, I would rather start with one border/corner case and not many cases. The rule "wait 3 days" would imply that the people would absent from discussions and it would be legal, the quality would go down. So we have to decide whether we need to have features regardless of quality, or we want to have features and quality. Cheers Tibor On Fri, Feb 4, 2022 at 12:57 PM Xeno Amess <xenoam...@gmail.com> wrote: > 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 > > > > > >
