File: ChangeLog

package info (click to toggle)
gnome-session 3.32.0-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental
  • size: 4,216 kB
  • sloc: ansic: 15,207; xml: 969; sh: 45; python: 18; makefile: 17
file content (50 lines) | stat: -rw-r--r-- 2,390 bytes parent folder | download | duplicates (16)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
=== ChangeLog discontinued ===

 With the move to git, this module is switching from a ChangeLog file to
 relying on commit messages to provide change history. Please write commit
 messages in the format described at http://live.gnome.org/Git/CommitMessages

 Below is a copy of this format:

=== begin example commit ===
tag: Short explanation of the commit

Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too brief.
=== end example commit ===

  - The commit message is mainly for the other people, so they should be able
    to understand it now and six months later. 

  - Always add a brief description of the commit to the _first_ line of the
    commit and terminate by two newlines (it will work without the second
    newline, but that is not nice for the interfaces).

  - First line (the brief description) must only be one sentence and should
    start with a capital letter unless it starts with a lowercase symbol or
    identifier. Don't use a trailing period either. Don't exceed 72 characters.

  - You can prefix the first line with one tag, to make it easier to know to
    which part of the module the commit applies. For example, a commit with
    "fish: Make it work with newer fortune" in the gnome-panel module clearly
    applies to the fish applet.

  - The main description (the body) is normal prose and should use normal
    punctuation and capital letters where appropriate. Normally, for patches
    sent to a mailing list, the body is copied from there. This main
    description can be empty if the change is self-explanatory (eg: "Add DOAP
    file").

  - When committing code on behalf of others use the --author option, e.g. git
    commit -a --author "Joe Coder <joe@coder.org>".

  - When referring to a bug, you can use this form: bgo#12345. Use bgo for
    bugzilla.gnome.org, but you can also reference bugs in other bug trackers:
    rh means bugzilla.redhat.com, bnc means bugzilla.novell.com, lp means
    launchpad.net, etc. Whenever possible, use the full URL of the bug, though.

  - When a commit closes a bug, the commit message should contain a line like:
    Closes: http://bugzilla.gnome.org/show_bug.cgi?id=12345
    or simply:
    http://bugzilla.gnome.org/show_bug.cgi?id=12345