#203: Document commit procedures -----------------------+----------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: critical | Milestone: Olena 2.1 Component: Olena | Version: 2.0 Resolution: | Keywords: -----------------------+----------------------- Changes (by levill_r):
* version: 1.0 => 2.0 * component: Trac => Olena * milestone: Olena 2.2 => Olena 2.1
Old description:
There are just too many mistakes in commits. The LRDE Guidelines warns about many of them, but IMHO it is not enough.
A draft summary:
- Read comments from other about your patches (and patch proposals), and
take them into account.
- Use tools, but don't be fooled by them (know their limits): Vcs, `svn-
wrapper`, etc. A flaw in a tool is not an excuse for a dirty patch.
- Learn what a (good) !ChangeLog entry is.
- Kwow why !ChangeLogs matter (whatever their form), both technically
and legally.
- Learn how to fix !ChangeLogs correctly.
- Resist to the temptation to commit too fast.
- Don't break things: run `make` (and possibly `make check`) before
committing.
- Do not commit too many things at once: one idea/one task = one
commit.
- Reread you patches before sending them.
- Use ispell (when writing documentation).
- Learn how to use `git-svn` (or `git`, if it is available) instead of
`svn`.
- Learn from others: some tools take time to understand and master
(Make, Autoconf, Automake, shells, etc.).
Olena Teammates shall print and read this page once complete.
`HACKING` may be a good place to store this information.
New description:
There are just too many mistakes in commits. The LRDE Guidelines warns about many of them, but IMHO it is not enough.
A draft summary: * Read comments from others about your patches (and patch proposals), and take them into account. * Use (and write) tools, but don't be fooled by them (know their limits): custom generators, etc. A flaw in a tool is not an excuse for a dirty patch. * Learn what a (good) `ChangeLog` entry/commit message is is. * Know why `ChangeLogs`/commit messages matter (whatever their form), both technically and legally. * Learn how to fix `ChangeLogs` correctly. * Resist to the temptation to push your changes too fast. * Don't break things: run `make` (and possibly `make check`) before committing. * Use development branches continuous integration (i.e. our !TeamCity infrastructure). * Do not commit too many things at once. The rule of thumb here is: one idea/task = one commit. Git make this easy, using e.g. `git add -i` or `git gui`. * Reread you patches before sending them (use `git diff [--cached]`, `git gui`, etc.) * Spell check your patches, especially the documentation (use `ispell`, `M-x ispell` in Emacs, etc.) * Learn from others: some tools take time to be understood and mastered (Make, Autoconf, Automake, shells, etc.).
`HACKING` may be a good place to store this information.
--
Comment:
Update the (outdated) description.