[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
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
On Tue, Sep 25, 2018 at 5:15 PM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
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?
I don't know where the Ceph upgrade work is being done, nothing has been proposed to the stx-sech repo. The CentOS upgrades are in the stx-* repos in Gerrit under the regular stuff, this is only for the staging repos that are direct forks of upstream. dt -- Dean Troyer dtroyer@gmail.com
On Tue, Sep 25, 2018 at 5:37 PM, Dean Troyer <dtroyer@gmail.com> wrote:
On Tue, Sep 25, 2018 at 5:15 PM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
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?
I don't know where the Ceph upgrade work is being done, nothing has been proposed to the stx-sech repo.
Good grief, stx-ceph dt -- Dean Troyer dtroyer@gmail.com
The same strategy should apply to the ceph upgrade. Brent -----Original Message----- From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Tuesday, September 25, 2018 6:16 PM To: Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Git tagging of upstream branches 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 _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Sounds reasonable to me Brent -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Tuesday, September 25, 2018 5: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
participants (3)
-
Dean Troyer
-
Jones, Bruce E
-
Rowsell, Brent