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

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' stuff into 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
'nm-1-2' 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 a bugfix-only, stable branch.
This is also exactly what we did for 'nm-1-0' branch at the RHEL-7.2
time and although it has downsides, I think it is preferable to above
option.

Upstream is not going to maintain a bugfix-only 'nm-1-2' branch. If
somebody wants that, he must be prepared to do the work and maintain
such a "stable" branch based on 1.2.2 himself. Do note, that 'master'
is supposed to be backward compatible, and all the gazillion of changes
that happend there are considered to be an improvement. Thus, we bring
all those improvements to 'nm-1-2', not only bugfixes.
Also note, that after this large merge we are going to take the time to
test and fix possible regressions before releasing 1.2.4.
You can also think of 1.2.4 as a new backward compatible version of
NetworkManager and 'master' was the development branch towards that.

Now, instead of cherry-picking basically everything, re-merge 'master'
into 'nm-1-2'. The outcome is pretty 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`.
  + we anyway backport everything. Thus a real merge in our git history
    better represents what is happening.
  + with a real merge, git has a new merge-parent and future backports
    will less conflict.
  - we don't have a fine-grained history of cherry-picked patches on
    'nm-1-2'. Instead, there is only this one merge-commit. Of course,
    the real history is all here and comes from 'master', on HEAD^2.
  - it also means, if downstream wants to patch 1.2.2 release, it must
    find the appropriate patch on HEAD^2.
  - 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 out, and we can find regressions that
    this merge may cause.
  - RHEL-7.3 is even farther away and thus all the testing effort
    immediately benefits 'nm-1-2'.

Yet another alternative to a real merge or extensive cherry-picking would be
to do a `git merge --squash master`. However, I think that a real merge better
expresses what actually happened.

Conflicts:
    clients/cli/settings.c
    clients/common/nm-vpn-helpers.c
    configure.ac
    libnm-core/Makefile.am
    libnm-core/nm-vpn-editor-plugin.c
    man/common.ent.in
    po/pt_BR.po
    po/sv.po
    shared/nm-macros-internal.h
    shared/nm-test-utils.h
    shared/nm-version-macros.h.in
    src/devices/bluetooth/nm-bluez-device.c
    src/devices/nm-device-ethernet.c
    src/devices/nm-device.c
    src/devices/nm-device.h
    src/devices/wwan/nm-modem-broadband.c
    src/dhcp-manager/nm-dhcp-systemd.c
    src/dns-manager/nm-dns-dnsmasq.c
    src/dns-manager/nm-dns-manager.c
    src/dnsmasq-manager/tests/test-dnsmasq-utils.c
    src/nm-auth-subject.c
    src/nm-connection-provider.c
    src/nm-connection-provider.h
    src/nm-core-utils.c
    src/nm-ip4-config.c
    src/nm-ip6-config.c
    src/nm-manager.c
    src/platform/nm-fake-platform.c
    src/platform/nm-linux-platform.c
    src/platform/nm-platform-utils.c
    src/platform/nm-platform-utils.h
    src/platform/nm-platform.c
    src/platform/nm-platform.h
    src/ppp-manager/nm-ppp-manager.c
    src/settings/nm-settings.c
    src/tests/test-ip4-config.c
    src/vpn-manager/nm-vpn-connection.c

1 files changed, 1 insertions, 1 deletions

diff --git a/clients/tui/nmtui-edit.h b/clients/tui/nmtui-edit.h
index dae91cfac7..459011e10b 100644
--- a/clients/tui/nmtui-edit.h
+++ b/clients/tui/nmtui-edit.h
@@ -26,7 +26,7 @@ G_BEGIN_DECLS
 typedef gboolean (*NmtAddConnectionTypeFilter) (GType    connection_type,
                                                 gpointer user_data);
 
-NmtNewtForm *nmtui_edit (int argc, char **argv);
+NmtNewtForm *nmtui_edit (gboolean is_top, int argc, char **argv);
 
 void nmt_add_connection      (void);
 void nmt_add_connection_full (const char                 *primary_text,