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 >
