<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 18, 2012, at 11:00 AM, Doug Davis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<br><tt><font size="2">Vish wrote on 05/17/2012 02:18:19 PM:<br>
...</font></tt>
<br><tt><font size="2">> 3 Feature Branch in Core</font></tt>
<br><tt><font size="2">> <br>
> We are doing some work to support Feature and Subsystem branches in
<br>
> our CI system. 3rd party apis could live in a feature branch so that<br>
> they can be tested using our CI infrastructure. This is very similar<br>
> to the above solution, and gives us a temporary place to do <br>
> development until the internal apis are more stable. Changes to <br>
> internal apis and 3rd party apis could be done concurrently in the
<br>
> branch and tested. </font></tt>
<br>
<br><tt><font size="2">can you elaborate on this last sentence? When
you say "changes to internal</font></tt>
<br><tt><font size="2">apis" do you mean "in general" or only
when in the context of those</font></tt>
<br><tt><font size="2">3rd party APIs needing a change? I can't see
the core developers wanting</font></tt>
<br><tt><font size="2">to do internal API changes in a 3rd party api branch.
I would expect</font></tt>
<br><tt><font size="2">3rd party api branches to mainly include just stuff
that sits on top of</font></tt>
<br><tt><font size="2">the internal APIs and (hopefully very few) internal
API tweaks.</font></tt>
<br><tt><font size="2">Which to me means that these 3rd party API branches
should be continually </font></tt>
<br><tt><font size="2">rebased off of the trunk to catch breaking changes
immediately.</font></tt><br></blockquote><div><br></div><div><br></div><div>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).</div><br><blockquote type="cite">
<br><tt><font size="2">If I understand it correctly, of those options, I
like option 3 because </font></tt>
<br><tt><font size="2">then the CI stuff will detect breakages in the 3rd
party APIs right away</font></tt>
<br><tt><font size="2">and not until some later date when it'll be harder
to fix (or undo) those</font></tt>
<br><tt><font size="2">internal API changes.</font></tt><br></blockquote><div><br></div>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.</div><div><br></div><div>Vish<br></div><br></body></html>