> The argument boils down to there is a communications cost to adding > someone to core, and therefore there is a maximum size before the > communications burden becomes to great.
I'm definitely of the mindset that the core team is something that has a maximum effective size. Nova is complicated and always changing; keeping everyone on top of current development themes is difficult. Just last week, we merged a patch that bumped the version of an RPC API without making the manager tolerant of the previous version. That's a theme we've had for a while, and yet it was still acked by two cores. A major complaint I hear a lot is "one core told me to do X and then another core told me to do !X". Obviously this will always happen, but I do think that the larger and more disconnected the core team becomes, the more often this will occur. If all the cores reviewed at the rate of the top five and we still had a throughput problem, then evaluating the optimal size would be a thing we'd need to do. However, even at the current size, we have (IMHO) communication problems, mostly uninvolved cores, and patches going in that break versioning rules. Making the team arbitrarily larger doesn't seem like a good idea to me. > I will say that I am disappointed that we have cores who don't > regularly attend our IRC meetings. That makes the communication much > more complicated. Agreed. We alternate the meeting times such that this shouldn't be hard, IMHO. --Dan
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev