The format of the patch comments is as follows
- comment line comes before the patch it belongs to
- comment line consists of multiple tags in the form of foo:bar
- it must include the following tags:
owner:joe_bloggs
joe_bloggs is the patch owner's user id on opensolaris.org as listed here: project observers
date:YYYY-MM-DD
this is the date the patch was originally created; don't update it when you update the patch
type:foo
where foo is one of:
- feature
- a patch that adds new functionality
- branding
- OSD or Solaris specific customizations, changes to default configuration
- doc
- documentation related changes
- l10n
- localization related changes
- bug
- everything else
No spaces before or after the ":"
- it should include bugzilla or bugster ids if exist:
bugzilla:123456[,234567...] bugster:6543210[,6654321...] doo:1432[,4234]
separate multiple bugids by commas, as shown above. "doo" means defect.opensolaris.org. It's okay (in fact good) to have more than one of bugzilla, bugster and doo ids. If there is no bugid, you should file one, preferably upstream. Possible exceptions are feature and some branding patches, but it doesn't hurt to have a bugid for those either.
Please don't add bugster:none or bugzilla:none. If there no bugid of any kind, just don't add any bugzilla/bugster tags.
- don't exceed 80 chars, break the comment into multiple lines instead
- if the patch is upstream but there is no bugid (because it was sent to a mailing list or uses some exotic bug tracking mechanism, or the patch was taken from upstream), you can add the following tag to make the patch "green":
state:upstream
- any additional text in the comment lines preceding the Patch line will appear in the comments column of the reports
Examples
# date:2006-08-16 bugster:6460249 owner:harrylu type:feature Patch14: gnome-panel-14-support-alacarte.diff # date:2006-09-14 bugster:6463604 owner:harrylu type:branding Patch2: libgnomeui-02-crash-no-bugbuddy.diff # owner:calumb date:2006-11-01 type:branding # bugster:6564332,6756345,2343423 bugzilla:234234,654564,231233 Patch23: gnome-panel-23-ui-improvements.diff # owner:erwannc date:2008-08-27 type:bug doo:3111 Patch4: pango-04-unnamed-unions.diff
Advanced stuff
- for modules that use bugzilla, add this tag to the top of the spec file (under owner):
# bugdb: bugzilla.something.org
where something is the project name, e.g. bugzilla.freedesktop.org
- for modules that don't use bugzilla (e.g. sourceforge), the patch report cannot find out the bug status from the bugids. You can add a link to the bug tracked in the bugdb tag. If the link ends with a "/" or an "=", the bugid will be appended to form a link to the bug. E.g.
# bugdb: http://sourceforge.net/tracker/index.php?func=detail&group_id=8874&atid=108874&aid=
In this case, the bug ids can use the bugzilla or the bugid tag, e.g.
# owner:laca date:2006-10-22 bugid:12312312 type:bug
More info
What is "branding"?
In general, branding patches:
- make changes that expose Sun/Solaris/OpenSolaris branded images or messages
- change the default setting/configuration/behaviour
- disable parts of a package that we do not intend shipping
The following are great examples of branding patches:
- changing a Launch menu entry to match the UI spec
- changing the default theme to Nimbus
- setting up default url handlers or mime type handlers
- adding a bookmark or changing the starting page in firefox
The following do not qualify as branding:
- a patch that is needed to build some code on Solaris: if it doesn't build, it's a bug! Should be fixed upstream.
- a patch that makes some code work better or faster on Solaris: these are also bugs and should be fixed upstream.
- a patch that adds mediaLib support to gtk: this is a feature patch