Format of Patch Comments at OpenSolaris.org

You are not signed in. or register.

Project: Java Desktop System: A GNOME-based desktop

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
JDS 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...]
```
separate multiple bugids by commas, as shown above. it's okay (in fact good) to have both bugzilla and bugster ids if there is no bugid, consider filing one. exceptions are feature and possibly some branding patches, but it doesn't hurt to have a bugid for those either. doc l10n and normal bugs should be filed upstream.
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

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