On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote: > On 11 September 2014 15:35, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > OK, so look at a concrete example: in 2002, the Linux kernel went with > > bitkeeper precisely because we'd reached the scaling limit of a single > > integration point, so we took the kernel from a single contributing team > > to a bunch of them. This was expanded with git in 2005 and leads to the > > hundreds of contributing teams we have today. > > > One thing the kernel has that Openstack doesn't, that alter the way > this model plays out, is a couple of very strong, forthright and frank > personalities at the top who are pretty well respected. Both Andrew > and Linux (and others) regularly if not frequently rip into ideas > quite scathingly, even after they have passed other barriers and > gauntlets and just say no to things. Openstack has nothing of this > sort, and there is no evidence that e.g. the TC can, should or desire > to fill this role.
Linus is the court of last appeal. It's already a team negotiation failure if stuff bubbles up to him. The somewhat abrasive response you'll get if you're being stupid acts as strong downward incentive on the teams to sort out their own API squabbles *before* they get this type of visibility. The whole point of open source is aligning the structures with the desire to fix it yourself. In an ideal world, everything would get sorted at the local level and nothing would bubble up. Of course, the world isn't ideal, so you need some court of last appeal, but it doesn't have to be an individual ... it just has to be something that's daunting, to encourage local settlement, and decisive. Every process has to have something like this anyway. If there's no process way of sorting out intractable disputes, they go on for ever and damage the project. James _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev