[Starlingx-discuss] Git tagging of upstream branches
Jones, Bruce E
bruce.e.jones at intel.com
Tue Sep 25 22:15:59 UTC 2018
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?
From: Dean Troyer [mailto:dtroyer at gmail.com]
Sent: Tuesday, September 25, 2018 2:17 PM
To: starlingx-discuss at 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 .
dtroyer at gmail.com
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
More information about the Starlingx-discuss