This all makes sense to me. I'm assuming we did not do anything like this for the CentOS upgrades, or the in progress Ceph upgrade. Should we handle Ceph in the same way? And everything else going forward? brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Tuesday, September 25, 2018 2:17 PM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Git tagging of upstream branches Background: Jim Somerville is working on a rebase of libvirt to 4.7.0 (we were on 3.5.0) with the stx-specific changes on top of a fresh upstream branch. Until now we have designated that the woking branch name for all activity is 'master'. For upstream forked repos this may not make sense going forward. We will have this problem with most it not all of them as we rebase on new upstream work. These repos were all newly constructed from upstream clones with the stx squash patch laid on top. With libvirt 4.7.0 Jim has done the same thing again (filtering the patches of course) but with individual patches instead of a single squash. (YAY!) What I am proposing we do is maintain multiple branches in these repos corresponding to the upstream branch as _our_ working master. Using this sort of scheme we can have multiple rebase-masters at once (in the above, pike and rocky for example), each release would correspond to only one of those, that relationship would not be encoded in the branch names, I think that is acceptable. So for the immediate libvirt situation: Upstream stable branch: v4.7.0 (this is a tag in the libvirt repo) StarlingX 'master': stx/v4.7.0 (sticking with the libvirt style for versions) Or OpenStack terms: Upstream stable branch: stable/pike StarlingX 'master' branch: stx/pike StarlingX release/stable branch: r/2018.10 Any thoughts on the approach? On the form of the branch names? FWIW, we have proposed the first iteration of this in the stx-libvirt repo [0]. dt [0] https://github.com/starlingx-staging/stx-libvirt/pull/1 -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss