backport everything from master to nm-1-2



all: merge branch 'master' into nm-1-2

Since releasing 1.2.0, we maintain a stable branch 'nm-1-2' and implement
new features on 'master'. Occasionally, we backport patches by
cherry-picking from 'master'.

While developing RHEL-7.3, we want essentially all those features
and fixes from 'master' also show up in final RHEL-7.3, because that
largely determines our priorities.

One way to get 'master' to RHEL-7.3, would be to release 1.4.0, and
bring that to RHEL-7.3. The downside is, that we already have
downstreams as a user of 'nm-1-2' branch (Ubuntu 16.04 LTS).
Obviously, there are many useful and important fixes on 'master' that
also should reach downstream. Would downstream also rebase with us to
1.4.0? Do we want to invest the effort to heavily maintain both a
'nm-1-4' and 'nm-1-2' branch upstream? After releasing 1.4.0, upstream
has less motivation for the additional work to maintain an old-stable
branch. So I think this either means more work for upstream, or less
upstream help with old-stable branch. The latter possibly also means
a worse expirience for 'nm-1-2' users.

The alternative is to bring 'nm-1-2' to RHEL-7.3, but that means
we backport essentially everything from 'master'. Of course, that
temporarily destabilizes our 'nm-1-2' somewhat (our 'master' is in
a decent shape, so it shouldn't be that bad).
It also means, that 'nm-1-2' will see large development/backporting
efforts and thus our upstream stable branch isn't what one would
traditionally consider stable.
This is also exactly what we did for 'nm-1-0' branch and RHEL-7.2
and although it has downsides, I think it is preferable to a stale
'nm-1-2' branch. If downstream really wants something "stable" based
on 1.2.2, it must do the work to maintain it.

Now, instead of cherry-picking basically everything, re-merge 'master'
into 'nm-1-2'. The result is similar, the difference is:

  + doing it in one rush is considerabily less work, and you can easily
    verify that the backports are correct via `git diff master`.
  + since it's a real merge of everyting, future backports will less
    likely see conflicts, because git has a new merge-parent that is
    much closer to both 'nm-1-2' and 'master'.
  - we don't have a fine-grained history of cherry-picked patches on
    'nm-1-2'. Instead, there is only this one merge-commit.
  - it also means, if downstream wants to patch 1.2.2 release, it must
    find the appropriate patch on master.
  - the large merge plays less nice with git-annotate and git-bisect, but
    still acceptable.

I think the time to do this is good, because
  - 'master' is in a relatively good shape
  - there are many useful fixes to backport
  - 1.2.4 is still a bit away, and we can find regressions that
    this merge causes.
  - RHEL-7.3 is even farther away and thus all the testing effort
    immediately benefits 'nm-1-2'.

An alternative to a real merge would be to do a `git merge --squash master`.
However, as we really merge everything, it seems more appropriate to preserve
the history which helps git to find a better merge-parent for future backports.


In a way, it is similar but different from:


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]