Pulp Backport Release Strategy

[iballou]

Hello community,

The Pulp and Katello teams recently had a meeting about Pulp’s backporting strategy. There recently had been a few cases where Katello couldn’t accept Pulp fixes because they included too many changes to safely accept into older versions of Katello. That is bad for all parties involved, so we wanted to find an improvement.

During the meeting we considered the option of waiting to backport until a direct request comes in from a stakeholder like Katello. One issue there for the Pulp team is that there may end up being too many conflicting release requests between stakeholders. Plus, the Pulp community wouldn’t receive as many backports as they may have.

So, the decision we landed on was to proactively backport fixes with a couple guidelines. The changes being backported should be communicated clearly to stakeholders. For example, with Katello/Satellite, Bugzilla issues will be created for Pulp issues that are related. The backport releases should also be kept as small as reasonably possible to reduce the risk of regression.

I’m speaking here for the greater Pulp team, so please chime in if I missed any important details. Also, we would love to hear comments from the community about handling backport releases!

Best,
Ian

[quba42]

@iballou

For example, with Katello/Satellite, Bugzilla issues will be created for Pulp issues that are related.

Is there already some example of a Bugzilla issue shadowing some Pulp issue (just to get a better idea of what that looks like)?

@iballou

The backport releases should also be kept as small as reasonably possible to reduce the risk of regression.

Does this simply mean doing frequent Z-releases with only a small number of fixes each, or are we talking more about the selection of bugfixes for backport (i.e. only backport bugfixes that are small self contained changes to a couple of lines in a single file)?

[dralley]

Is there already some example of a Bugzilla issue shadowing some Pulp issue (just to get a better idea of what that looks like)?

Basically just a tag on the github issue with a link to the bugzilla, and a corresponding link back to the github on the BZ.

@quba42

Does this simply mean doing frequent Z-releases with only a small number of fixes each, or are we talking more about the selection of bugfixes for backport (i.e. only backport bugfixes that are small self contained changes to a couple of lines in a single file)?

The first one. If you upgrade from one z-stream to another it needs to be easy to QA those releases which means, preferably, a limited number of changes in each one.