On Tue, Mar 12, 2019 at 8:55 AM Jones, Bruce E <bruce.e.jones@intel.com> wrote: [...]
ยท We need to define our branching strategy. Create an f/stx-stein branch? Create a f/nova feature branch for StarlingX? We will need to build our Nova container out of the github staging trees - once Nova cuts there first RC (Mar 22nd). Backports will be checked into github directly.
This is the process I imagined and outlined in the meeting: * When Nova creates their stable/stein branch at RC1 time we will create a mirror of that in starlingx-staging/nova as stx/stein. * This branch will be periodically updated from stable/stein as backports appear there from the Nova team. * As items on our list of upstream changes land in master (Train) we will backport them to stx/stein for StarlingX to pick up. * There may be times that work upstream has not yet merged but is sufficiently complete that we would backport early to meet a StarlingX time requirement, with the expectation that it be brought current with what finally does merge after that happens. * Upstream work that is not yet complete that we want to backport to meet a StarlingX time requirement should be worked upstream to get it to the state mentioned above to enable us to backport it to stx/stein. Still to be decided/confirmed: * We need to have some measure of testing in stx/stein, I will look in to what we can run from OpenStack Zuul directly. * I like the idea of continuing to have only a small number of people with the ability to commit to the staging repo * We may want to consider the tactic of keeping our additional commits in stx/stein rebased on top of the upstream stable/stein rather than merging in upstream backports. This would be inconvenient for those with local copies of the branch after each rebase but it would keep the SHAs in the upstream commits the same. (I am not convinced yet that we should do this, still sorting it out) dt -- Dean Troyer dtroyer@gmail.com