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
