Hi Alberto, Here are some of my opinions on this matter.
"the review process is taking longer now. " I agree that the review process is taking a bit longer, but that is the price I believe needs to be paid to improve the probability of good quality code is being merged to Geode. More eyes on the code mean that more issues may be detected. Our goal should not be to merge code as fast as possible but well-vetted code goes into the codebase. "Some code owners might be getting more reviews than they can cope with and they have become a bottleneck." Yes, that may be true, committers are free to decrease the load by modifying the CODEOWNERS file through a PR to remove themselves from certain areas. " reviewers required to approve a pull request can be much higher than two, depending on the number of areas touched by the PR." Yes, I agree but it is also necessary if multiple areas of the code are modified. Geode is a complex distributed system, and we have engineers who are experts in certain areas of the code. It is unfair to a single engineer to approve code in areas that are not in their knowledge domain. Also, I think the engineers involved in the approval process are involved in tasks of their own hence it is ok to increase the time window a bit to accommodate them. Also, a pointer, not all code owners in the reviewers' panel in the PR need to approve the PR for it to be merged. Github at the bottom of the PR lists the smallest set of approvals needed to merge the PR. You can email them if it is a priority. In my opinion, quality and correctness are more important than the speed of merging code. We need to reduce the number of bugs/issues that have greatly reduced the process of releasing Apache Geode. Regards Nabarun ________________________________ From: Alberto Gomez <alberto.go...@est.tech> Sent: Wednesday, March 17, 2021 8:46 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: [DISCUSS] CODEOWNERS mechanism feedback Hi, It's been more than two months since the CODEOWNERS file has been in place to automatically add reviewers to pull requests. While we have seen the great benefit of having the experts in the matter being automatically assigned as reviewers to each pull request, I have the feeling that the review process is taking longer now. Some possible reasons could be: 1. Some code owners might be getting more reviews than they can cope with and they have become a bottleneck. 2. While prior to this change only two approvals were necessary, with the new process the number of approvals from reviewers required to approve a pull request can be much higher than two, depending on the number of areas touched by the PR. Again, this might just be my feeling or something incidental and only related to the pull requests I have been working on. In any case, I would like to know if others are experiencing this slowdown in the review of their pull requests. Also, I do not know if there are metrics available for the review process. For example, the average time taken since a pull request is submitted or a change is made on it until there is a review. Having these types of metrics would be very useful because they would allow us to evaluate this mechanism from perspectives other than the quality of the reviews and to propose corrective actions if necessary. Best regards, Alberto
