Open Stack

On May 18, 2012, at 11:00 AM, Doug Davis wrote:

> 
> Vish wrote on 05/17/2012 02:18:19 PM:
> ... 
> > 3 Feature Branch in Core 
> > 
> > We are doing some work to support Feature and Subsystem branches in 
> > our CI system. 3rd party apis could live in a feature branch so that
> > they can be tested using our CI infrastructure. This is very similar
> > to the above solution, and gives us a temporary place to do 
> > development until the internal apis are more stable. Changes to 
> > internal apis and 3rd party apis could be done concurrently in the 
> > branch and tested. 
> 
> can you elaborate on this last sentence?  When you say "changes to internal 
> apis" do you mean "in general" or only when in the context of those 
> 3rd party APIs needing a change?  I can't see the core developers wanting 
> to do internal API changes in a 3rd party api branch.  I would expect 
> 3rd party api branches to mainly include just stuff that sits on top of 
> the internal APIs and (hopefully very few) internal API tweaks. 
> Which to me means that these 3rd party API branches should be continually 
> rebased off of the trunk to catch breaking changes immediately.


I agree.  I was suggesting that initially internal api changes could be made in the feature branch in order to enable the new top level apis, tested, and then proposed for merging back into core.  This is generally easier than trying to make changes in two separate repositories to support a feature (as we have to do frequently in openstack).

> 
> If I understand it correctly, of those options, I like option 3 because 
> then the CI stuff will detect breakages in the 3rd party APIs right away 
> and not until some later date when it'll be harder to fix (or undo) those 
> internal API changes.

Well it won't automatically do so, but it should alllow for an easy way for the third party developers to run ci tests without setting up their own infrastructure.

Vish

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120518/60284d75/attachment.html>