On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues <wrodrig...@schubergphilis.com> wrote: > Hi guys, > > I hope that’s not too late to react on this one. > > Having 6 RMs seems a bit too much for me. For PRs containing a few lines of > code, just bug fixes or changing maven files, python, sh, etc it might be > simple and quick. However, if we get a PR with +30 commits and 10k lines > added, it gets really difficult to get the community to test/review the PR. > So, for 2 people to go over it is already taking too long to get the code > imagine, now imagine 4 or 6. > > Rohit has done an excellent job in looking into the PRs, commenting on them > and some times testing as well. But there are things that cannot simply get > him, or perhaps other guys, to test properly a PR; having time and > environment as the main reasons. > > I would say that in case we have a PR that contains: > > 1. Documentation on the Apache CS Wiki > 2. Unit Tests (a lot of them, minimum 70% for the code changed) > 3. Marvin Test Results report - test_routers, test_vpc_routers, > test_vm_life_cycle, test_account, at least. > > Should be given priority and get less RMs involved in order to speed up our > development/release processes. Unless, of course, the people would have time > to look into the PR immediately. > > What do you think? > > Cheers, > Wilder >
I like this. We have to live by our tests. So enforcing good coverage, and gating on good results makes sense to me. No human can reliably eyeball all of this. --David
