Hi, during the TripleO meeting today we had two distinct discussions about reviews.
Firstly, our stats have been slipping: http://russellbryant.net/openstack-stats/tripleo-openreviews.html Stats since the last revision without -1 or -2 (ignoring jenkins): Average wait time: 2 days, 16 hours, 18 minutes 1rd quartile wait time: 0 days, 11 hours, 1 minutes Median wait time: 1 days, 9 hours, 37 minutes 3rd quartile wait time: 5 days, 1 hours, 50 minutes Longest waiting reviews (based on oldest rev without nack, ignoring jenkins): 7 days, 16 hours, 40 minutes https://review.openstack.org/50010 (Fix a couple of default config values) 7 days, 4 hours, 21 minutes https://review.openstack.org/50199 (Utilizie pypi-mirror from tripleo-cd) 6 days, 2 hours, 28 minutes https://review.openstack.org/50431 (Make pypi-mirror more secure and robust) 6 days, 1 hours, 36 minutes https://review.openstack.org/50750 (Remove obsolete redhat-eventlet.patch) 5 days, 1 hours, 50 minutes https://review.openstack.org/51032 (Updated from global requirements) This is holding everyone up, so we want to fix it. When we discussed it we found that there were two distinct issues: A - not enough cross-project reviews B - folk working on the kanban TripleO Continuous deployment stuff had backed off on reviews - and they are among the most prolific reviewers. A: Cross project reviews are super important: even if you are only really interested in (say) os-*-config, it's hard to think about things in context unless you're also up to date with changing code (and the design of code) in the rest of TripleO. *It doesn't matter* if you aren't confident enough to do a +2 - the only way you get that confidence is by reviewing and reading code so you can come up to speed, and the only way we increase our team bandwidth is through folk doing that in a consistent fashion. So please, whether your focus is Python APIs, UI, or system plumbing in the heart of diskiamge-builder, please take the time to review systematically across all the projects: https://wiki.openstack.org/wiki/TripleO#Review_team B: While the progress we're making on delivering a production cloud is hugely cool, we need to keep our other responsibilities in check - https://wiki.openstack.org/wiki/TripleO#Team_responsibilities - is a new section I've added based on the meeting. Even folk working on the pointy end of the continuous delivery story need to keep pulling on the common responsibilities. We said in the meeting that we might triage it as follows: - review reviews for firedrills first. (Critical bugs, things breaking the CD cloud) - review reviews for the CD cloud - then all reviews for the program with a goal of driving them all to 0: if we're on top of things, that should never be a burden. If we run out of time, we'll have unblocked critical things first, unblocked folk working on the pointy edge second - bottlenecks are important to unblock. We'll review how this looks next week. # The second thing The second issue was raised during the retrospective (which will be up at https://wiki.openstack.org/wiki/TripleO/TripleOCloud/MVP1and2Retrospective a little later today. With a production environment, we want to ensure that only released code is running on it - running something from a pending review is something to avoid. But, the only way we've been able to effectively pull things together has been to run ahead of reviews :(. A big chunk of that is due to a lack of active +2 reviewers collaborating with the CD cloud folk - we would get a -core putting a patch up, and a +2, but no second +2. We decided in the retrospective to try permitting -core to +2 their own patch if it's straightforward and part of the current CD story [or a firedrill]. We set an explicit 'but be sure you tested this first' criteria on that : so folk might try it locally, or even monkey patch it onto the cloud for one run to check it really works [until we have gating on the CD story/ies]. Cheers, Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
