[all][oslo] official recommendations to handle oslo-incubator sync requests
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, I've found out there are no clear public instructions on how to handle oslo-incubator synchronizations in master and stable branches neither at [1] nor at [2]. Though my observations show that there is some oral tradition around community on how we handle those review, as follows: 1. For master oslo-incubator sync requests, we tend to sync the whole modules or even all the modules that a project uses (unless some specific obstacles to do so). This is to use the latest and greatest code from Oslo subproject, fetch all possible bug fixes and goodies, and make the synchronized copy of it as similar to upstream (=oslo-incubator) as possible. 2. For stable branches, the process is a bit different. For those branches, we don't generally want to introduce changes that are not related to specific issues in a project. So in case of backports, we tend to do per-patch consideration when synchronizing from incubator. 3. Backporting for stable branches is a bit complicated process. When reviewing synchronization requests for those branches, we should not only check that the code is present in all consequent branches of the appropriate project (f.e. for Havana, in both Juno and Icehouse), but also that the patches being synchronized were successfully backported to corresponding stable branches of oslo-incubator. So the usual way of oslo-incubator bug fix is (in case of e.g. Neutron): oslo-incubator (master) -> neutron (master) -> oslo-incubator (stable/icehouse) -> neutron (stable/icehouse). [For Havana, it's even more complicated, introducing more elements in the backporting chain.] I hope I've described the existing oral tradition correctly. Please comment on that, and if we're ok with the way it's written above, I'd like to update our wiki pages ([1] and [2]) with that. [1]: https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist [2]: https://wiki.openstack.org/wiki/StableBranch Cheers, /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT81aRAAoJEC5aWaUY1u57PmgIAIJzzOUHMRe4oDJ0slj5DwjW FpXY6ce/awnFBpG7PR/qlMWXrbGHwesDZ3oihVHA4hbGOkjG7trK35uP07A9IQDI fptLQZ0CXIjgQghoHUtM2BUUjJ19jwKaMdX14BNAAIO6C0hJMElpl/ZTY7zGwa9S pBotxelpMHr4fE06BqDU5hfradBPJOjn0dg2xcqchYU67B8DqTYaLHwQh9XL1r8s 16IvcDlrpJf9N2f9G/V6SlgJlgZzVUfyeKIKQ47/AP+FsSv2rPpH6UgtDdIy8yqj IMyyXUNbvBNwZTC4bLd6NlrNIuLBLmUX7Ao96wldFbAc84uFc6iAoRrtPNdj2ec= =B7+E -----END PGP SIGNATURE-----
Ihar Hrachyshka wrote:
[...] I hope I've described the existing oral tradition correctly. Please comment on that, and if we're ok with the way it's written above, I'd like to update our wiki pages ([1] and [2]) with that.
That matches my version of the oral tradition. One point to note is that we should refrain from doing gratuitous oslo-incubator syncs, since the process is so painful :) Once oslo libraries graduate, they are handled through usual dependency version updates, which are not really encouraged in stable either. So this process should IMHO really be limited to critical bugs and security issues. -- Thierry Carrez (ttx)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 20/08/14 10:05, Thierry Carrez wrote:
Ihar Hrachyshka wrote:
[...] I hope I've described the existing oral tradition correctly. Please comment on that, and if we're ok with the way it's written above, I'd like to update our wiki pages ([1] and [2]) with that.
That matches my version of the oral tradition.
One point to note is that we should refrain from doing gratuitous oslo-incubator syncs, since the process is so painful :) Once oslo libraries graduate, they are handled through usual dependency version updates, which are not really encouraged in stable either. So this process should IMHO really be limited to critical bugs and security issues.
Hm. My (short) personal experience shows that in most cases synchronizations do not result in any pain. At least for modules that have settled a bit. I also think that spending time to cope with updates in oslo-incubator is beneficial for both oslo and affected projects. If anything, it reveals issues with underlying oslo code before we encounter a security issue or a major failure mode in incubator and then realize that we cannot easily sync the update to projects because they are too far from incubator reality. But, that's my envisioned ideal world. And it seems it's not the same as for other (more experienced) OpenStack developers. :) /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT9FhsAAoJEC5aWaUY1u57yH8IAObVX86zq75u81dfern6e3bK P34f8uDlDLSj/jbTvQUwyB17AaN4z0uvh+qxvc3R9p281Qu+RtZhdOgYJUn2szDi jvRq7ULyrIIiFFlQmChiik2+g8u3SK6HsiZzP+GBr86oJS7VUy0iDfHj+oz51LdI ZBxyzc/cL32uhoqKNUw0VRUS4EU2UXyCp4+opkQl+hxHT8PczG/spOA/d8P8W+F9 cPxGNdYiERv9rySshGk27X65Xh1ouqeAcLbAzO1HK57cLqXD+Y7HOJ8yM3thDcMP w16n6iyr88OIjW0igB/8R9pY83vK4CEaBhTvm7C4hhGre2RsqGCk6ZcOMIWvTtU= =b7CW -----END PGP SIGNATURE-----
2. For stable branches, the process is a bit different. For those branches, we don't generally want to introduce changes that are not related to specific issues in a project. So in case of backports, we tend to do per-patch consideration when synchronizing from incubator.
I'd call this cherry-sync: format-patch commit from oslo stable, update file and import paths and apply it on project's stable branch. That could be an oslo-incubator RFE: command option for update.py --cherry-pick COMMIT Cheers, Alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 There seems to be no objections to that wording, so I went forward and added it to [1], plus added the note about those rules to [2]. [1]: https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator [2]: https://wiki.openstack.org/wiki/StableBranch#Proposing_Fixes On 19/08/14 15:52, Ihar Hrachyshka wrote:
Hi all,
I've found out there are no clear public instructions on how to handle oslo-incubator synchronizations in master and stable branches neither at [1] nor at [2]. Though my observations show that there is some oral tradition around community on how we handle those review, as follows:
1. For master oslo-incubator sync requests, we tend to sync the whole modules or even all the modules that a project uses (unless some specific obstacles to do so). This is to use the latest and greatest code from Oslo subproject, fetch all possible bug fixes and goodies, and make the synchronized copy of it as similar to upstream (=oslo-incubator) as possible.
2. For stable branches, the process is a bit different. For those branches, we don't generally want to introduce changes that are not related to specific issues in a project. So in case of backports, we tend to do per-patch consideration when synchronizing from incubator.
3. Backporting for stable branches is a bit complicated process. When reviewing synchronization requests for those branches, we should not only check that the code is present in all consequent branches of the appropriate project (f.e. for Havana, in both Juno and Icehouse), but also that the patches being synchronized were successfully backported to corresponding stable branches of oslo-incubator. So the usual way of oslo-incubator bug fix is (in case of e.g. Neutron):
oslo-incubator (master) -> neutron (master) -> oslo-incubator (stable/icehouse) -> neutron (stable/icehouse).
[For Havana, it's even more complicated, introducing more elements in the backporting chain.]
I hope I've described the existing oral tradition correctly. Please comment on that, and if we're ok with the way it's written above, I'd like to update our wiki pages ([1] and [2]) with that.
[1]: https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist
[2]: https://wiki.openstack.org/wiki/StableBranch
Cheers, /Ihar
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUEyR2AAoJEC5aWaUY1u57QS4H+gPHfebOBKJJAdhSjTRkaR9/ cV6A/M+snCAmlL5YcdMNruwAqaotvXMmUiUL2Mdekne7GqLlTwAtSnDQxwvr7BYu m1Hu1/eRwVQZLS33UzvZRdAHJMlgD7Mq5p6w21yNKOVa+3wrXY+Q/JTAVv5i/pJ9 UQWTJpbE3DGT8j8B6jFrPbaMnjYjVrbHdGyvxqEaSdS0259kDSgSwULRmAilPRBd 3gIwZC1obqePkby7amQEIYKkPa53aFz2mSEPsWpaT2nYNLILCOcN5OLGNkdo1ksu 5gJ1hXx4MBuKbGALUO7QcdXgquXGv6O1hMq1GSi8bRsbxKbVn4XktsnS/ULqRSE= =lzyp -----END PGP SIGNATURE-----
participants (3)
-
Alan Pevec
-
Ihar Hrachyshka
-
Thierry Carrez