Although this package uses format 3.0 (quilt), it does not directly reuses the
upstream release because we want to build using our custom ./build_all.sh
script. Instead, we create a "fake" orig tarball that contains only what we
need using the debian/create-orig.sh script.

Minor upgrades
##############

Updating from minor version releases (ie. 24.10.xxxx to 24.10.yyyy) can be
done quite effectively. Note that this needs to be done in the ubuntu/latest
branch first before any SRU backports are considered.

1. Download the MLNX_OFED_SRC-debian-24.10.yyyy.tgz file from upstream.

2. Create the orig tarball from the upstream archive:
   $ ./debian/create-orig.sh ../MLNX_OFED_SRC-debian-24.10-yyyy.tgz

3. Move the created orig tarball outside of the package:
   $ mv mofed-modules_24.10.yyyy.orig.tar.xz ../

   and import the orig tarball using git-buildpackage:
   $ gbp import ../mofed-modules_24.10.yyyy.orig.tar.xz

4. Inspect the upstream changes for any packaging changes:
   $ git show upstream/latest

   These changes should be reflected in the debian/build_all.sh script to
   reduce the delta we have with the upstream packaging scripts to a minimum.

5. Inspect the upstream changes for any copyright changes:
   $ git show upstream/latest

   Changes in licensing should be reflected in the d/copyright file. This
   might be new files with their own licenses, old files that have been
   removed, or existing files that have seen their license change.

6. Check that the list of built modules is still correct by building the
   DKMS modules and comparing them to the existing list:

   $ ./debian/build_all.sh $(uname -r) /lib/modules/$(uname -r)/build/
   $ ./debian/gen-dkms-conf-mod-entries.sh| diff -u - debian/dkms.in

   If there is a difference then the debian/dkms.in file needs to be updated.

7. Generate a new d/changelog entry with the correct version:
   $ gbp dch -N 24.10.yyyy-0ubuntu1 -D plucky -c

8. Tag the changelog commit:
   $ gbp tag

9. Push the commits and the tags to the git repository:
   $ gbp push

Major upgrades
##############

Updating from major versions is more involved than minor updates. One of the
reasons is that the source and binary package contains the major version in
their name, allowing for multiple major versions to coexist in the archive.

Additional steps should be taken compared to the minor upgrade path:

1. Create a blank d/changelog with the proper source package name and version.

2. Create and import the orig tarball (same as in minor upgrades)

3. Rename the binary packages to contain the updated major version.

4. Follow the remaining verification steps from the minor upgrade list.
