Open Stack

Ihar Hrachyshka wrote:
> I'm concerned that in some cases [1] we merge patches in stable
> branches before they reach master. My understanding is that in general
> such approach may lead to multiple kinds of issues:
> 
> 1. if a master patch is not merged in the end due to negative review
> feedback, we will need to cope with a stable-only patch.

Actually, the main goal is to make sure we don't insert a regression:
bugs fixed in the stable branch should also be fixed on the development
release, and the easier way to ensure that is to block stable bugfixes
until master incorporates the same bugfix.

> 2. if a master patch is modified later before its merge, we need to
> cope with the need to apply last minute modifications to stable
> branches. In the worst cases, the difference won't even be noticed,
> and we'll result in unneeded differences between master and stable code.
> 
> 3. also, if a patch is merged into e.g. havana and not icehouse, and
> then a user upgrades to icehouse, he will see a regression due to the
> missing patch that was once fixed in a prev-stable release.
> 
> We could say that there are some cases where the strict ordering of
> backports is not applicable, like in [1]. Quoting Thierry,
> 
> "
> @Ihar: stable branch changes come in two categories. There are project
> bugfixes (which are straight backports of stuff that has to land in
> master to ensure we have no regression) and infrastructure patches (to
> keep the test infrastructure working on stable branches).
> The latter do NOT have to land in master: in most cases, they are not
> even applicable there. This is basically a branch-specific
> infrastructure patch to keep the stable branch running. The fact that
> it has a master "equivalent" is more of a coincidence. Not having that
> patch in master wouldn't be a regression.
> To answer your question, if the patch has to be reworked, that would
> result in subsequent patchsets.
> "
> 
> So some cases are not affected by problem (3), but still, (1) and (2)
> apply.

Let me elaborate on infra patches. Those are not bugfixes, nor is it
really affecting the source code. Those are changes in peripheral files
(which are often not even included in tarballs) so that the CI continues
to work on stable branches despite recent changes made to the
infrastructure.

In some cases those patches need to be applied to all branches, in some
cases just to a specific branch. So they are, by nature, branch-specific
original patches rather than backports: the concern in (1) doesn't
really apply IMHO.

The concern in (2) is still valid though: by proposing and merging those
branch-specific patches in parallel, if we realize that they are
insufficient, a follow-up patch may have to be applied to all branches.
Merging one first and then apply the same logic to the others would
avoid that. Note that the order doesn't really matter though: the
stable/havana patch could be the first one (temporarily breaking CI on
stable/havana actually hurts the project a lot less than temporarily
breaking CI on master). So I'd leave that ordering choice to the
Infrastructure person that pushes those patches, and not block them on
master landing. They know what they are doing.

Now, I understand that this is not documented at all, it's more of an
oral tradition within the stable branch team, and we need to properly
document that exception to the rules.

-- 
Thierry Carrez (ttx)