systemd/README: improve readme

src/libnm-systemd-shared/README.md

@@ -1,27 +1,29 @@
 libnm-systemd-shared
 ====================
 
-This is a fork of systemd source files that are compiled
+This is a fork of systemd source files that are compiled as a static library
-as a static library with general purpose helpers.
+with general purpose helpers.
 
-We mainly need this for [../libnm-systemd-core/](../libnm-systemd-core/),
+We mainly need this for [../libnm-systemd-core/](../libnm-systemd-core/), which
-which contains systemd library with network tools (like DHCPv6).
+contains builds network tools that we use (our internal DHCPv6 library).
 
-We should not use systemd directly from our sources, beyond what
+We should not use systemd directly from our sources, beyond what we really need
-we really need to make get libnm-systemd-core working.
+to make get libnm-systemd-core working. That means, although the systemd code
+contains many useful utility functions, we should not use them beyond what we
+really need, because one day we want to drop this code again.
 
 
 Reimport Upstream Code
 ----------------------
 
-We want to avoid deviations in our fork, and frequently re-import
+We want to avoid deviations in our fork, and frequently re-import latest
-latest systemd version (every 4 to 8 weeks). The reason is that we
+systemd version (every 4 to 8 weeks). The reason is that we frequently should
-frequently should check whether important fixes were done in upstream
+check whether important fixes were done in upstream systemd, and the effort of
-systemd, and the effort of doing that is half the work of just reimporting.
+doing that check is half the work of a full reimport.  Also, by reimporting
-Also, by reimporting frequently, we avoid deviating hugely (instead we only deviate
+frequently, we avoid deviating hugely and fall back too much.
-largely).
 
-Of course this is cumbersome. We should replace systemd code with something else.
+Of course this is cumbersome. We therefore should avoid using the systemd code
+as much as we can, and work towards dropping it altogether.
 
 To do a re-import, do:
 
@@ -36,16 +38,20 @@ To do a re-import, do:
 - checkout `main` branch, and `git merge systemd`. Fix all issues, test,
   repeat.
 
-- open merge request, check that all tests pass. In particular, enable build
+- open merge request, check that all tests pass. In particular, enable build on
-  on all test distributions.
+  all test distributions in gitlab-ci.
 
-- push `main` and `systemd` branch.
+- push `main` and `systemd` branches. Compare how it was done during past imports.
 
 ### Hints
 
-- Eagerly commented out the unused function.
+- Eagerly commented out unused functions definitions with `#if 0` and `#endif`.
-- Patching header is best avoided, #if 0  and #endif  function patching should
+- Patching header files is best avoided and keep function declarations.
-  only be used in the C source.
+- We may create some dummy header files in `src/libnm-systemd-{shared,core}/sd-adapt-\*/`
-- We may create some dummy files in
+  if that is a suitable way to get the code to compile, while having minimal modifications
-  `src/libnm-systemd-{shared,core}/sd-adapt-\*/` for resolving the compiling
+  to systemd code.
-  error (missing header file)
+- Let git be aware of the merge history. Git can help you to better resolve merge conflicts.
+  For example, a plain rebase of the branch on `main` will result in conflicts. Instead,
+  create a temporary branch and merge the code (no rebase). With the help of the history,
+  git will not run into conflicts during merging. Then, the merged git-tree contains the
+  desired content of the files.