[vdsm][maintainership] proposal for a new stable branch policy
Hi all, Recently Milan, Petr and me discussed the state of ovirt.4.2, considering that release 4.2.2 is still pending and this prevents merging of patches in the sub-branch ovirt-4.2. We agreed we could improve the handling of the stable branch(es), in order to make the process smoother and more predictable. Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...) as much as we can, to avoid the hassle of double-backporting patches to stable branch. However, if a release hits unexpected delay, this policy causes different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively locked, so patches already queued and ready for next releases can't be merged and need to wait. The new proposed policy is the following: - we will keep working exactly as now until we hit a certain RC version. We choosed RC3, a rule of thumb made out of experience. - if RC3 is final, everyone's happy and things resume as usual - if RC3 is NOT final, we will branch out at RC3 -- from that moment on, patches for next version could be accepted on the Y-branch -- stabilization of the late Z version will continue on the Z-branch -- patches will be backported twice Example using made up numbers - We just released ovirt 4.3.1 - We are working on the ovirt-4.3 branch - The last tag is v4.30.10, from ovirt-4.3 branch - We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch - We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1). Tag is made from ovirt-4.3 branch. - Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC 3. Both tags are made from ovirt-4.3 branch. - Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch ovirt-4.3 from the same commit pointed by tag 4.30.13 - Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the ovirt-4.3.2 branch I believe this approach will make predictable for everyone if and when the branch will be made, so when the patches could be merged and where. The only drawback I can see - and that I realized while writing the example - is the version number which can be awkward: v4.30.11 -> 4.3.2 RC1 v4.30.12 -> 4.3.2 RC2 v4.30.13 -> 4.3.2 RC3 v4.30.13.1 -> 4.3.2 RC4 ?!?! v4.30.13.5 -> 4.3.2 RC5 ?!?! Perhaps we should move to four versions digit? So we could have v4.30.11.0 -> 4.3.2 RC1 v4.30.11.1 -> 4.3.2 RC2 v4.30.11.2 -> 4.3.2 RC3 v4.30.11.3 -> 4.3.2 RC4 v4.30.11.4 -> 4.3.2 RC5 I don't see any real drawback in using 4-digit versions by default, besides a minor increase in complexity, which is balanced by more predictable and consistent versions. Plus, we already had 4-digit versions in Vdsm, so packaging should work just fine. Please share your thoughts, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh
On Wed, Mar 21, 2018 at 11:57 AM, Francesco Romani <fromani@redhat.com> wrote:
Hi all,
Recently Milan, Petr and me discussed the state of ovirt.4.2, considering that release 4.2.2 is still pending and this prevents merging of patches in the sub-branch ovirt-4.2.
We agreed we could improve the handling of the stable branch(es), in order to make the process smoother and more predictable.
Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...) as much as we can, to avoid the hassle of double-backporting patches to stable branch.
However, if a release hits unexpected delay, this policy causes different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively locked, so patches already queued
and ready for next releases can't be merged and need to wait.
The new proposed policy is the following:
- we will keep working exactly as now until we hit a certain RC version. We choosed RC3, a rule of thumb made out of experience.
- if RC3 is final, everyone's happy and things resume as usual
- if RC3 is NOT final, we will branch out at RC3
-- from that moment on, patches for next version could be accepted on the Y-branch
-- stabilization of the late Z version will continue on the Z-branch
-- patches will be backported twice
Example using made up numbers
- We just released ovirt 4.3.1
- We are working on the ovirt-4.3 branch
- The last tag is v4.30.10, from ovirt-4.3 branch
- We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch
- We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1). Tag is made from ovirt-4.3 branch.
- Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC 3. Both tags are made from ovirt-4.3 branch.
- Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch ovirt-4.3 from the same commit pointed by tag 4.30.13
- Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the ovirt-4.3.2 branch
I believe this approach will make predictable for everyone if and when the branch will be made, so when the patches could be merged and where.
The only drawback I can see - and that I realized while writing the example - is the version number which can be awkward:
v4.30.11 -> 4.3.2 RC1
v4.30.12 -> 4.3.2 RC2
v4.30.13 -> 4.3.2 RC3
v4.30.13.1 -> 4.3.2 RC4 ?!?!
v4.30.13.5 -> 4.3.2 RC5 ?!?!
In principle, nothing forces you to align vdsm versions exactly with oVirt (rc) releases. In otopi, as a much simpler example (and there are many here), I do mostly what I want, as needed. I usually bump versions when I have enough bugs fixed for a next project release, but _also_ if I want to introduce some change that some other project needs - so that I can bump the 'Requires: otopi >= X.Y.Z' line of the other project. So the main question to ask, if you do want to keep above scheme, is: Do you expect, in above example, to have to tag/build vdsm for 4.3.3 before 4.3.2 is released? If not, then you can have: v4.30.11 -> 4.3.2 RC1 v4.30.12 -> 4.3.2 RC2 v4.30.13 -> 4.3.2 RC3 v4.30.14 -> 4.3.2 RC4 v4.30.15 -> 4.3.2 RC5 And the only problem will be what to do in the -4.3 branch when you branch -4.3.2 at RC3. Can't think about a good answer for this... It's probably not a good idea to keep it at 4.30.13 (or .12), because you want builds from it to have higher versions than from the -4.3.2 branch.
Perhaps we should move to four versions digit? So we could have
v4.30.11.0 -> 4.3.2 RC1
v4.30.11.1 -> 4.3.2 RC2
v4.30.11.2 -> 4.3.2 RC3
v4.30.11.3 -> 4.3.2 RC4
v4.30.11.4 -> 4.3.2 RC5
I don't see any real drawback in using 4-digit versions by default, besides a minor increase in complexity, which is balanced by more predictable and consistent versions. Plus, we already had 4-digit versions in Vdsm, so packaging should work just fine.
Makes sense to me. Not sure if this was discussed, but in practice the engine already does that, more-or-less (the tags, not branches). One of the "prices" of adding branches is having to maintain CI for them. Perhaps this policy should also consider what we do if/when migrating to STDCI v2, see e.g.: http://lists.ovirt.org/pipermail/infra/2018-March/033224.html And also affect, if needed, this v2 project. Obviously it would be great if you could have automatically had CI handled in the same single commit that bumps the version. You will still have the price of having to cherry-pick, but I can't see how you can escape that.
Please share your thoughts,
-- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
Francesco Romani <fromani@redhat.com> writes:
Recently Milan, Petr and me discussed the state of ovirt.4.2, considering that release 4.2.2 is still pending and this prevents merging of patches in the sub-branch ovirt-4.2.
We agreed we could improve the handling of the stable branch(es), in order to make the process smoother and more predictable.
Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...) as much as we can, to avoid the hassle of double-backporting patches to stable branch.
However, if a release hits unexpected delay, this policy causes different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively locked, so patches already queued
and ready for next releases can't be merged and need to wait.
The new proposed policy is the following:
- we will keep working exactly as now until we hit a certain RC version. We choosed RC3, a rule of thumb made out of experience.
I think the idea actually was to choose the RC after which patch acceptation is restricted (e.g. blockers only). That would be consistent with the problem being solved, i.e. not to block patch merging and to clearly distinguish between patches to be merged to X.Y only and patches to be merged to X.Y.Z. If may typically be RC3, but I wouldn't hard-bind the branching to a particular version.
- if RC3 is final, everyone's happy and things resume as usual
- if RC3 is NOT final, we will branch out at RC3
-- from that moment on, patches for next version could be accepted on the Y-branch
-- stabilization of the late Z version will continue on the Z-branch
-- patches will be backported twice
Example using made up numbers
- We just released ovirt 4.3.1
- We are working on the ovirt-4.3 branch
- The last tag is v4.30.10, from ovirt-4.3 branch
- We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch
- We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1). Tag is made from ovirt-4.3 branch.
- Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC 3. Both tags are made from ovirt-4.3 branch.
- Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch ovirt-4.3 from the same commit pointed by tag 4.30.13
- Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the ovirt-4.3.2 branch
I believe this approach will make predictable for everyone if and when the branch will be made, so when the patches could be merged and where.
The only drawback I can see - and that I realized while writing the example - is the version number which can be awkward:
v4.30.11 -> 4.3.2 RC1
v4.30.12 -> 4.3.2 RC2
v4.30.13 -> 4.3.2 RC3
v4.30.13.1 -> 4.3.2 RC4 ?!?!
v4.30.13.5 -> 4.3.2 RC5 ?!?!
Our current versions are not tied to RC versions (e.g. there can be more than one tag per one RC), so I can see no special problem with using v4.30.13.1 for RC4 and v4.30.13.2 for RC5.
Perhaps we should move to four versions digit? So we could have
v4.30.11.0 -> 4.3.2 RC1
v4.30.11.1 -> 4.3.2 RC2
v4.30.11.2 -> 4.3.2 RC3
v4.30.11.3 -> 4.3.2 RC4
v4.30.11.4 -> 4.3.2 RC5
I don't see any real drawback in using 4-digit versions by default, besides a minor increase in complexity, which is balanced by more predictable and consistent versions. Plus, we already had 4-digit versions in Vdsm, so packaging should work just fine.
Please share your thoughts,
Yedidyah Bar David <didi@redhat.com> writes:
So the main question to ask, if you do want to keep above scheme, is: Do you expect, in above example, to have to tag/build vdsm for 4.3.3 before 4.3.2 is released?
We probably want to make a new 4.3 tag as soon as one new patch is merged to the 4.3 branch after 4.3.Z is branched out, to distinguish any builds (private, snapshots, …) made from that.
participants (3)
-
Francesco Romani -
Milan Zamazal -
Yedidyah Bar David