[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
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.
-----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
- 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:
- 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.
- 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.
- 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.
Cheers, /Ihar
participants (3)
-
Alan Pevec
-
Ihar Hrachyshka
-
Thierry Carrez