User:Mizdebsk/HowToSubmitPatches

If you want to submit patch for a package where I (Mikolaj Izdebski, mizdebsk) am maintainer please follow the following rules. This will make it much easier for me to apply the patch. These rules also apply to cases where I'm not maintainer of the package but you want me to apply a patch as a provenpackager.

The guidelines

1. Use Bugzilla. If there is already an open bug for the issue your patch is solving then please attach the patch as an attachment, otherwise create a new bug report. Do NOT submit patches directly by email or to mailing lists unless I agreed in advance. There are plenty of reasons for using Bugzilla, I don't want to rant here about that.
2. The patch should be created against current master branch in git repository, even if the bug is reported against a stable release. Don't submit patches against stable releases, I will rebase your patch if needed. This is because all development should be done in rawhide.
3. The patch should be in git mailbox format. You can use git format-patch to create such patches. While standard patch would theoretically be possible too I prefer git patches because they allow you to be credited as the author of the patch.
4. The patch should include proper changelog as described in packaging guidelines. It's a good practice to include bug number in the changelog (for example: Resolves: rhbz #12435)
5. The patch should bump the RPM release tag unless it is updating to new upstream version (in which case there should be version bump instead). If release bump was not needed I will adjust your patch. The reason for this is that release bump might be needed at the time the patch is applied even if it was not needed at the time the patch was created. Besides that needles release bumps don't cause bugs while missing bumps do.
6. The patch should not introduce new rpmlint warnings to the package. It's a generally a good practice to run rpmlint at least on your spec file before you submit the patch.
7. If you submit a new patch replacing previous patch(es) (for example a fixed or improved version of an older patch) please make sure that the previous patch(es) are marked as obsoleted. This makes it more clear which patch is correct and should be considered for inclusion in the package.
8. Please add keyword Patch to the bug. This will bring my attention to the bug and increase its priority on my TODO lists. If I'm not the owner or maintainer of the component and you want me to fix the bug (as provenpackager) then please add me to CC list (mizdebsk@redhat.com).