update proxmox-backup to 2.4.1-1

[MAFLO321]

• drop no-ksm patch

[MAFLO321]

~Proxmox backup server 2.4.0-2 is not yet released.~ I will remove "Draft" state of PR when it is released. -> done

[wofferl]

I have merged your 2.4.0-2 changes. Please push commits only after you have compiled and tested it successfully. Thanks for your work.

[MAFLO321]

First, thanks for merging :smile: .

I always compile and test the stuff I push. Just Proxmox never released the packages for 2.4.0-2 a directly went to 2.4.1-1, that's why I marked the PR as draft?

For the future, should I change my workflow:

• Option A:
  1. proxmox changes version in there git repo
  2. Contributor: update our patches locally and test it and prepare branch
  3. proxmox releases packages on pbs-no-subscription repo
  4. Contributor: create PR on this github project
  5. Maintainer: merge PR (or maybe adjust it or ask for changes)
• Option B (my current workflow):
  1. 7. Proxmox: changes version in their git repo
  2. Contributor: update our patches locally and test it and prepare branch
  3. Contributor: create Draft PR on this github project. (Optional: write a comment that the packages are not yet released by Proxmox) So the Maintainer or someone else can test the changes, know that someone is working on it and he/she does not need to research it on his/her own, and can update the patches further if needed.
  4. (optional) 7. Proxmox: changes version again in their git repo without releasing the package
     1. (optional) Contributor: update our patches locally and test it and prepare commit
     2. (optional) Contributor: force-push Draft PR branch
  5. Proxmox: releases packages on pbs-no-subscription repo
  6. Contributor: mark PR as ready for review on this github project
  7. Maintainer: merge PR (or maybe adjust it or ask for changes)

@wofferl What do you think about the two options for the future?

[wofferl]

This is not really a complex or professional project where you need guidelines or have to rush when new versions came out. In most cases it is only change the revisions.

The problem in this case was, that you removed the draft and rushed your changes for the 2.4.1 change, so you had to force-push multiple times to correct them.

This doesn't make it easier to track, so better to test and compile through first before pushing the changes.

[MAFLO321]

Okay, I will do my best, to not rush over and over again the next time. Thanks anyway.