Commit Digest/Guidelines: Difference between revisions

From KDE Community Wiki
(initial addition of suggested new guidelines)
 
(modified typo and added introduction)
Line 1: Line 1:
==Goal of this page==
Composing better inclusion guidelines for reviewing commits for the Commit Digest. The source of the original guidelines can be found [https://github.com/dannyakakong/Enzyme/wiki/Inclusion-Guidelines-%28Review%29 here].
==Original Guidelines==
==Original Guidelines==


Line 6: Line 10:


In general add messages to the Commit Digest if they:
In general add messages to the Commit Digest if they:
1. are interesting (in general these messages have a longer text describing them),
# are interesting (in general these messages have a longer text describing them),
2. fix a bug, are an optimization or add a feature (for the user); this is in particular the case when there is a "broken box" symbol in the lower right corner of the message,
# fix a bug, are an optimization or add a feature (for the user); this is in particular the case when there is a "broken box" symbol in the lower right corner of the message,
3. new or significantly improved icons.
# new or significantly improved icons.


Generally do not include messages if they:
Generally do not include messages if they:
1. are back-ports, i.e., the message basically appears two times (then do not include the backported version),
# are back-ports, i.e., the message basically appears two times (then do not include the backported version),
2. are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
# are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
3. are about CMake or desktop files, documentation changes (w/o bug number)
# are about CMake or desktop files, documentation changes (w/o bug number)
4. are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing )
# are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing )


==New Guidelines==
==New Guidelines==
Line 30: Line 34:
# are back-ports, i.e., the message basically appears two times (then do not include the backported version),
# are back-ports, i.e., the message basically appears two times (then do not include the backported version),
# are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
# are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
# are about CMake or desktop files, documentation changes (w/o bug number),
# are about CMake or desktop files, documentation changes (without bug number),
# are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing ),
# are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing ),
# are fixes or additions to a localization (w/o bug number)
# are fixes or additions to a localization (without bug number)
# introduce trivial changes such as the resizing of a line-edit or changes in button placement.
# introduce trivial changes such as the resizing of a line-edit or changes in button placement.

Revision as of 20:37, 28 December 2010

Goal of this page

Composing better inclusion guidelines for reviewing commits for the Commit Digest. The source of the original guidelines can be found here.

Original Guidelines

There is no definitive set of rules when to include a commit message and when not. However, the following gives some guidelines.

Hint: you can always investigate a commit further by clicking on the commit id. This gives you helpful details about which files were modified and allows for a line by line comparison of the source code.

In general add messages to the Commit Digest if they:

  1. are interesting (in general these messages have a longer text describing them),
  2. fix a bug, are an optimization or add a feature (for the user); this is in particular the case when there is a "broken box" symbol in the lower right corner of the message,
  3. new or significantly improved icons.

Generally do not include messages if they:

  1. are back-ports, i.e., the message basically appears two times (then do not include the backported version),
  2. are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
  3. are about CMake or desktop files, documentation changes (w/o bug number)
  4. are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing )

New Guidelines

On average about 5% of all commits in a week will be included in the commit digest. This means that those who review the commits should choose carefully which commits should be included. There is no definitive set of rules when to include a commit message and when not. However, the following gives some guidelines.

Hint: you can always investigate a commit further by clicking on the commit id. This gives you helpful details about which files were modified and allows for a line by line comparison of the source code.

In general add messages to the Commit Digest if they:

  1. are interesting (in general these messages have a longer text describing them),
  2. fix a bug, are an optimization or add a feature (for the user); this is in particular the case when there is a "broken box" symbol in the lower right corner of the message,
  3. new or significantly improved icons.

Generally do not include messages if they:

  1. are back-ports, i.e., the message basically appears two times (then do not include the backported version),
  2. are refactorings, internal clean-ups, additions to the API (unless they seem to be interesting, e.g., a whole new API for Nepomuk),
  3. are about CMake or desktop files, documentation changes (without bug number),
  4. are about unit tests ( http://en.wikipedia.org/wiki/Unit_testing ),
  5. are fixes or additions to a localization (without bug number)
  6. introduce trivial changes such as the resizing of a line-edit or changes in button placement.