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 > > > > > > > > > >
