GNOME/Patches

From openSUSE

We deal with lots of packages, and lots of patches inside those packages, so this page serves as a way to better organize the patches and the way we deal with them.

Patch Standards

Patches need to be marked in the .spec files with a well-known format to be able to run automatic tools on them, in order to generate reports, patch counts and other interesting information. They also need to be named consistently.

Patch Markup (also called "Tagging Patches")

To facilitate the use of automatic tools -- and to help future packagers -- we have agreed on using the following categories for our patches:

• Fixes: these are normal fixes and are divided into two categories:
  • Fixes for openSUSE-specific things, that upstream maintainers won't be interested in.
  • Fixes for SLED-specific things, that upstream maintainers won't be interested in and that are not needed in openSUSE.
  • Fixes for the upstream sources that should be upstreamed.
• Features: new features added to the packages, also divided into two categories:
  • Features for openSUSE-specific things (AppArmor integration, for instance) with no interest for upstream maintainers.
  • Features for SLED-specific things with no interest for upstream maintainers or openSUSE.
  • Features that should be upstreamed. It is important, whenever we write this kind of new features, to coordinate with upstream maintainers, so that we develop something that would be, mostly without changes, accepted upstream. It is a lot of work to, once a new feature is done, rework it to fit upstream maintainers' willings, so it is better to know exactly from the beginning what they would expect for such a new feature.
• Special cases: we often have patches that get commented out temporarily because they failed to apply to the latest sources, and the patches need to be rebased.

To mark our patches to follow this convention, we have came up with a standard to mark them in the .spec file, following the format below:

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc1234 bgo456789
Patch1: fix-for-opensuse-specific-things.patch
# PATCH-FIX-SLED fix-for-sled-specific-things.patch bnc9876 bgo321549
Patch2: fix-for-sled-specific-things.patch
# PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch bnc2345 bgo567890
Patch3: fix-for-upstream-sources.patch
# PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch bnc3456 bgo678901
Patch4: feature-for-opensuse-specific-things.patch
# PATCH-FEATURE-SLED feature-for-sled-specific-things.patch bnc6543 bgo543210
Patch5: feature-for-sled-specific-things.patch
# PATCH-FEATURE-UPSTREAM feature-for-upstream.patch bnc4567 bgo789012
Patch6: feature-for-upstream.patch
# PATCH-NEEDS-REBASE old-patch.patch bnc1234
#Patch7: old-patch.patch

Finally, we can include email addresses, so it'll be easier to figure out who wrote a patch if we have questions later, and free-form comments after " -- ".

That is:

# PATCH-{FIX|FEATURE}-{OPENSUSE|SLED|UPSTREAM} name-of-file.patch bncb.novell.com_bug_number bgob.gnome.org_bug_number you@example.com -- this patch makes things totally awesome

If there are related bugs in Novell, GNOME, or other bugzillas, please add them, it will help us, with the automatic tools we are writing, to get more accurate information.

Here are some of the abbreviations we use:

We can define more abbreviations later if and when they prove necessary.

One bug entry is usually sufficient, although if there are two (it's common for a patch to be related to a bugzilla.novell.com bug and a bugzilla.gnome.org bug) then it's preferable to list both.

Some patches fix bugs that aren't explicitly recorded anywhere. The right thing to do in this case requires some judgment on the part of the packager, but here are some ideas:

• If a release is imminent, create a bug for it. This is usually a requirement, and even if it weren't, it's still the right thing to do.
• If a release is a long way off and the bug has already been fixed upstream, note in the comment that it's already fixed in svn (or whereever) and the patch will go away when we next upgrade.

Patch Naming

All new patches should end with the extension '.patch'.

Whether a patch's name should start with the name of the package it applies to is a matter of debate or style. When in doubt, follow the convention used in the package you're hacking on.

An exception to this exists: patches that fix warnings that the compiler emits due to bogus code are frequently named 'abuild.patch'.

The patchlevel -- that is, will a patch be applied with -p0 or -p1? -- isn't important. Create patches however they're comfortable for you.

Tools

We are writing some tools to help us dealing with the hundreds of packages and patches we maintain, and are trying to make use of the public infrastructure (rather than the private one on internal SuSE machines) so that anyone can use these tools.

OSC plugins

We are working on plugins for osc to use the information in our patch annotations. We have more detailed information about these plugins at the GNOME/OSC_plugins page.

Other tools

The sky's the limit here. Contributions of new plugins or standalone tools (osc isn't necessarily a good fit for all the tools we want) are more than welcome. Share your scripts, your emacs lisp programs, whatever!

Upstreaming patches

Here is a list of packages and the patches included within them (right now, only the files are listed, so it might be not all patches listed are really used in the package).

Idea for how to present the patch list

Alphabetical table of packages and a sparkline / bar chart of how many patches there are

                s = "opensuse-specific"
                u = "to send upstream"
                f = "fix for upstream", etc.

 * abiword     [ss][uuuu][fffff]     (11 patches)
 * alacarte    [ssss][uuuuuu][fff]   (14 patches)
 * gtk2        [sssss][uuu][ffff]    (12 patches)

Each package name is a link to a detailed list of that package's patches.

Notes on patches

This info is here temporarily. We'll move it to annotations in the spec files, as described above, after 10.3 is released and we can change specfiles easily.

gnome-panel

• Bug #72924 corresponds to 309721 upstream - add lockdown for moving panels.