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