Format of Patch Comments

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