Hi all, I'd like to share some thoughts with regard to our current test and approval process. Let me break this thoughts into 2 separate sections:
1. Testing: Currently, all patches are being tested after they are approved. However, I think it would be of great benefit for contributors - and reviewers - to test patches before and after they're approved. Testing the patches before approval will allow folks proposing patches - although they're expected to test the patches before submitting them - and reviewers to know that the patch is indeed mergeable. Furthermore, it will help spotting corner cases, regressions that would benefit from a good discussion while the PR is hot. I think we don't need to run all jobs, perhaps just Windows, OSx and Linux should be enough for a first test phase. It would also be nice to run lint checks, stability checks etc. IIRC, GH's API should allow us to notify this checks failures. 2. Approval Process I'm very happy about how patches are reviewed. The time a patch waits before receiving the first comment is almost 0 seconds and we are spread in many patches. If we think someone else should take a look at some patch, we always make sure to mention that person. I think the language would benefit from a more strict approval process. For example, requiring 2 r+ from 2 different reviewers instead of 1. This might seem a bit drastic now, however as the number of contributors grows, this will help with making sure that patches are reviewed at least by 2 core reviewers and they get enough attention. I think both of these points are very important now that we're moving towards 1.0 and the community keeps growing. Thoughts? Feedback? -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
