And now I wish I could delete my messages sent to ML. On 3/31/16 9:38 PM, Nikhil Komawar wrote: > 2) is a giveaway it's Apr 1 (in some TZs)! > > > On 3/31/16 9:12 PM, Assaf Muller wrote: >> Have you been negatively impacted by slow development and review >> velocity? Read on. >> >> OpenStack has had a slow review velocity for as long as I can >> remember. This has a cascading effect where people take up multiple >> tasks, so that they can work on something while the other is being >> reviewed. This adds even more patches to ever growing queues. Features >> miss releases and bugs never get fixed. Even worse, we turn away new >> contributors due to an agonizing process. >> >> In the Neutron community, we've tried a few things over the years. >> Neutron's growing scope was identified and load balancing, VPN and >> firewall as a service were split out to their own repositories. >> Neutron core reviewers had less load, *aaS contributors could iterate >> faster, it was a win win. Following that, Neutron plugins were split >> off as well. Neutron core reviewers did not have the expertise or >> access to specialized hardware of vendors anyway, vendors could >> iterate faster, and everybody were happy. Finally, a specialization >> system was created. Areas of the Neutron code base were determined and >> a "Lieutenant" was chosen for each area. That lieutenant could then >> nominate core reviewers, and those reviewers were then expected to +2 >> only within their area. This led to doubling the core team, and for my >> money was a great success. Leading us to today. >> >> Today, I think it's clear we still have a grave problem. Patches sit >> idle for months, turning contributors away. I believe we've reached a >> tipping point, and now is the time for out of the box thinking. I am >> proposing two changes: >> >> 1) Changing what a core reviewer is. It is time to move to a system of >> trust: Everyone have +2 rights to begin with, and the system >> self-regulates by shaming offending individuals and eventually taking >> away rights for repeated errors in judgement. I've proposed a Neutron >> governance change here: >> >> https://review.openstack.org/300271 >> >> 2) Now, transform yourself six to twelve months in the future. We now >> face a new problem. Patches are flying in. You're no longer working on >> a dozen patches in parallel. You push up something, it is reviewed >> promptly, and you move on to the next thing. Our next issue is then CI >> run-time. The time it takes to test (Check queue), approve and test a >> patch again (Gate queue) is simply too long. How do we cut this down? >> Again, by using a proven open source methodology of trust. As >> Neutron's testing lieutenant, I hereby propose that we remove the >> tests. Why deal with a problem you can avoid in the first place? The >> Neutron team has been putting out fires in the form of gate issues on >> a weekly basis, double so late in to a release cycle. The gate has so >> many false negatives, the tests are riddled with race conditions, >> we've clearly failed to get testing right. Needless to say, my >> proposal keeps pep8 in place. We all know how important a consistent >> style is. I've proposed a patch that removes Neutron's tests here: >> >> https://review.openstack.org/300272 > Well played! But 2) gave it away =] > >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
