[openstack-dev] [all] The future of the integrated release

Eoghan Glynn eglynn at redhat.com
Thu Aug 7 20:41:15 UTC 2014

> > If we try to limit the number of WIP slots, then surely aspiring
> > contributors will simply work around that restriction by preparing
> > the code they're interested in on their own private branches, or
> > in their github forks?
> >
> > OK, some pragmatic contributors will adjust their priorities to
> > align with the available slots. And some companies employing
> > large numbers of contributors will enforce policies to align
> > their developers' effort with the gatekeepers' priorities.
> >
> > But I suspect we'd also have a good number who would take the
> > risk that their code never lands and work on it anyway. Given
> > that such efforts would really be flying beneath the radar and
> > may never see the light of day, that would seem like true waste
> > to me.
> Is that a problem? 

Well I guess it wouldn't be, if we're willing to tolerate waste.

But IIUC the motiviation behind applying the ideas of kanban is
to minimize waste piling up at bottlenecks in the pipeline.

My point was simply that we don't have direct control over the
contributors' activities, so that limiting WIP slots wouldn't
cut out the waste, rather it would force it underground.

This seems worse to me because either:

 (a) lots of good ideas end up being lost, as a critical mass
     of other contributors don't get to see them


 (b) contributors figure out ways to by-pass the rate-limiting
     on gerrit and share their code in other ways

Just a thought ...


> If such developers are going to work on their pet
> project anyway, it's really up to the core team whether or not they
> think it makes sense to merge the changes upstream.
> If the core team doesn't think they're worth merging (given the
> constraints on reviewer/approver time) then so be it.  At that point
> either we accept that we're going to leave possible contributions by the
> wayside or else we increase the core team (and infrastructure, and other
> strategic resources)  to be able to handle the load.
> Chris
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list