From Fedora Project Wiki
(Created page with "If you want to submit patch solving existing bug where I (Mikolaj Izdebski, <code>mizdebsk</code>) am maintainer please follow the following rules. This will make it much easi...")
 
m
Line 6: Line 6:
 
# The patch should be in git '''mailbox format'''. You can use <code>git format-patch</code> 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.
 
# The patch should be in git '''mailbox format'''. You can use <code>git format-patch</code> 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.
 
# The patch should include '''proper changelog''' as described in packaging guidelines.
 
# The patch should include '''proper changelog''' as described in packaging guidelines.
# The patch should bump the RPM '''release tag''' 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 needles release bumps don't cause bugs while missing bumps do.
+
# 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 needles release bumps don't cause bugs while missing bumps do.
 
# The patch should not introduce new '''<code>rpmlint</code> warnings''' to the package. It's a generally a good practice to run <code>rpmlint</code> at least on your spec file before you submit the patch.
 
# The patch should not introduce new '''<code>rpmlint</code> warnings''' to the package. It's a generally a good practice to run <code>rpmlint</code> at least on your spec file before you submit the patch.
 
# 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.
 
# 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.
 
# Please add '''keyword <code>Patch</code>''' 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 (<code>mizdebsk@redhat.com</code>).
 
# Please add '''keyword <code>Patch</code>''' 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 (<code>mizdebsk@redhat.com</code>).

Revision as of 08:09, 6 March 2013

If you want to submit patch solving existing bug 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. 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.
  2. 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.
  3. The patch should include proper changelog as described in packaging guidelines.
  4. 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 needles release bumps don't cause bugs while missing bumps do.
  5. 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.
  6. 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.
  7. 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).