New upstream version 1.49.90 upstream/1.49.90

1 files changed, 136 insertions, 23 deletions

diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index 2eeb75b0..5a75ee81 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -6,38 +6,51 @@ Issue tracker: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/is
 Help other maintainers with the triage following these guidelines. This way, it
 will be easier to find issues that require attention.
 
-- Assign an issue to yourself if you are going to take care of providing the
-  required help. Assign it to another person if he/she is more suitable to help,
-  but do this quite rarely so we take care of not overloading to anyone.
+- Workflow: indicate the current stage with the corresponding label:
 
-- Add suitable labels to indicate the state of open issues:
+  - `workflow::triage`: needs triage to determine whether is a bug, an RFE or we
+    should close it.
+
+  - `workflow::investigation`: has been triaged but more info is needed to start
+    working on a fix. This step can be skipped if enough information is provided
+    during triage.
+
+  - `workflow::devel`: on development (or waiting for it).
+
+  - Closed: the issue is already solved, either via a code fix or via providing
+    the required info. Also if the request is clearly incorrect or doesn't fit
+    at all in the project.
+
+- Assignee: assign the issue to the person that is working on it. This will
+  remove the `unassigned` and `help-needed::*` labels.
+
+- Manual labels: add suitable labels to indicate the state of open issues:
 
   - `need-info`: waiting for info or feedback from anyone.
 
+  - `good-first-issue`: the task is simple and well suited for a first time
+    contributor.
+
+  - `triaged::bug` / `triaged::RFE`: type of issue.
+
   - `need-discussion`: something is not clear about what to do, or about if
     something has to be done at all. The problem should be discussed by the
     maintainers and/or with the reporter and/or other interested parts.
 
-  - `triaged`: if the problem is properly explained and understood. Add also
-    one of the labels `bug` or `RFE` as corresponds.
-  
-  - `help-wanted`: request external contributors to work on this. If it's a
-    simple fix, add `good-first-issue` too.
-
-  - `work-in-progress`: anyone is already working on a Merge Request, so others.
-
   - `blocked`: the issue is waiting for something that blocks its progress
 
   - `close-proposed`: there are good reasons to reject the request (explain
-    those reasons when adding the label). If after a reasonable time there is no
-    additional info that is good enouch to reconsider it, the issue will be
-    closed.  
-    It is not mandatory to always use this tag before closing an issue, but
-    usually desirable.
+    those reasons when adding the label) but a chance to others to provide
+    reasons against it is desired.  
+    It is not mandatory to always use this tag.
+  
+  - `Spam`: mark as spam, blocking the author. See [damspam](https://gitlab.freedesktop.org/freedesktop/damspam/-/blob/main/README.md?ref_type=heads).
 
-- Close an issue if the problem is already solved, either via a code fix or via
-  some information that has been provided. Also if the request is clearly
-  incorrect or doesn't fit at all in the project.
+- Automatic labels: some labels are automatically added and removed by a bot and
+  the maintainers don't need to care much about them. The label `stale` is
+  used for issues without activity for a long time. The labels `unassigned` and
+  `help-needed::{triage, investigation, devel}` are used for issues without an
+  assignee.
 
 
 Merging Merge Requests
@@ -159,14 +172,114 @@ In practice when we want to backport new API from main we have two options:
   19d7e66099ee43f47d6be0e740dc710fc365d200. Then, on main we add duplicate
   symbols with commit 5eade4da11ee38a0e7faf4a87b2c2b5af07c5eeb.
 
-### Reimporting systemd
+
+NetworkManager release process
+------------------------------
+
+It's mostly automated by [release.sh](contrib/fedora/rpm/release.sh).
+
+Before running the script:
+- For stable releases, remember to backport all commits with "Fixes:" tag that
+  are applicable. Use the [find-backports](contrib/scripts/find-backports)
+  script to find them.
+- Start all the jobs in the latest Gitlab pipeline of the right branch. The
+  script checks that they ran successfully.  
+  Tiers 1 and 2 must pass, failed Tier 3 jobs can be fixed after the release.
+
+The script also takes care of choosing the right version number depending on the
+release type that you specify, like devel, rc1, rc, major, major-post, etc.
+Run the script with `--help` to see all options.
+
+Notes:
+- You need access to master.gnome.org, see [here](https://handbook.gnome.org/infrastructure/accounts.html).
+- The GPG key used to sign the tags must be exported to a keyserver.
+
+Versioning scheme, automatically handled by the script (version numbers are
+called MAJOR.MINOR.MICRO):
+- Development releases has an odd MINOR version number (i.e. `1.47.2`).
+- Stable releases has an even MINOR version number (i.e. `1.48.1`).
+- Release candidates (RC) are tagged like `1.48-rc1`, `1.48-rc2`, etc. But in
+  NM's internal code they looks like `1.47.90`, `1.47.91`, etc. (MINOR is one
+  number less, and MICRO is >= 90).
+
+The main differences between the different kind of releases are:
+- Development releases: for depelopment and testing purposes only.
+- Release candidates (RC): stabilization phase before a stable release. Normally
+  there are one or two RCs with ~2 weeks cadence. More RCs can be releases if
+  they are needed.
+- Stable releases: Releases within the same stable branch should remain very
+  stable while fixing important bugs, backported from `main`. New features are
+  added very rarely.
+
+Stable branches are branched out from `main` to prepare the first release
+candidate (RC) of the next stable branch. These branches are called `nm-MAJOR-MINOR`
+(i.e. `nm-1-48`). As they are used to release stable versions, the last number
+is always even.
+
+There are some additional tasks that the script doesn't handle:
+- For RC releases:
+  - The NEWS file should reflect a curated summary of the changes that the new
+    stable release will include.
+  - The release should be announced on the mailing list.
+- For stable releases:
+  - The official documentation must be updated on the website when there is a new
+    stable release. Use the [import-docs.sh](https://gitlab.freedesktop.org/NetworkManager/networkmanager.pages.freedesktop.org/-/blob/main/scripts/import-docs.sh)
+    script from the website's repo.
+  - The release should be announced on the mailing list.
+
+
+VPN plugins and nm-applet release process
+-----------------------------------------
+
+The same versioning scheme and release process is used for the VPN plugins,
+nm-applet (including nm-connection-editor) and libnma.
+
+Note that each of them is hosted in its own repository, but this is documented
+here to avoid duplication, as the process is the same for all (at least for
+those that we maintain).
+
+Also note that there are no stable branches or development versions. Everything
+is developed on main, and releases are done on main.
+
+Versioning scheme (version numbers are called MAJOR.MINOR.MICRO):
+- Small changes increments only the MICRO number.
+- Bigger changes or new features increments the MINOR number.
+- There is no strict criteria to define what change is small or big, but try to
+  adhere mostly to [semantic versioning](https://semver.org/).
+- Use only even numbers for MINOR, skipping odd ones. That way we use the same
+  versioning scheme than the main NM project despite there are no development
+  versions here.
+
+When doing a release, follow this process:
+1. Ensure that `NEWS` file is up to date.
+2. Increment the version in `configure.ac`, commit and tag the commit. Example:
+   `git tag -s 1.2.8 -m 'Tag 1.2.8'`.
+3. Ensure that you are on the right commit and create the tarball:
+   `git clean -fdx && ./autogen.sh && make distcheck`
+4. Upload the tarball: `scp ./*-*.tar.xz "$user@master.gnome.org:"`
+5. Login to `master.gnome.org` and run `ftpadmin install`.  
+   Ensure the new tarballs show up at https://download.gnome.org/sources/
+   (happens after a short delay)
+6. Announce the release on the mailing list.
+
+Notes:
+- You need access to master.gnome.org, see [here](https://handbook.gnome.org/infrastructure/accounts.html).
+- The GPG key used to sign the tags must be exported to a keyserver.
+
+
+Reimporting systemd
+-------------------
 
 See [here](src/libnm-systemd-shared/README.md#reimport-upstream-code).
 
-### Copr repository
+
+Copr repository
+---------------
 
 See [here](contrib/scripts/nm-copr-build.sh).
 
-### gitlab-ci Pipelines
+
+Gitlab-ci Pipelines
+-------------------
 
 See [here](.gitlab-ci/README.md).