Hi, https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=th%2Fnm-1-2-merge QUOTE ===== 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: https://mail.gnome.org/archives/networkmanager-list/2016-May/msg00085.html https://git.gnome.org/browse/network-manager-openvpn/commit/?id=ccd275d266f92524d9ef5ebd48d66845daa8b5c5 Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part