Talk:Development Team/Code Review

From Sugar Labs
Revision as of 07:53, 3 September 2010 by Bernie (talk | contribs) (Created page with "== Experimental workflow for doing reviews on mailing-list == * On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Experimental workflow for doing reviews on mailing-list

  • On the submitter end:
 git commit -s
 git format-patch -1
 git send-email --to maintainer --cc list foo.patch
  • Anyone who sees the patch can reply with inline comments. Multiple reviews are welcome.
  • The reviewer can conclude the message with one of these tags:
 Acked-by: Joe Hacker <jhacker@sugarlabs.org>
 Reviewed-by: Joe Hacker <jhacker@sugarlabs.org>
 Tested-by: Joe Hacker <jhacker@sugarlabs.org>
  • Only module maintainers and peers can ack a patch. In case someone has doubts about the meanings of the above tags, here's the detailed description.
  • If submitter has commit access to the repository, he/she amends the patch to incorporate

suggestions and to append any collected tags to the changelog:

 git commit --amend
 git push
 (submitters with multiple patches in their queue may need to rebase or switch to a clean branch)
  • In case the patch closes a bug in Trac, submitter closes the bug mentioning the commit ID as usual

If a module maintainer does not wish to approve patches submitted by email, simply state it, so we don't needlessly disappoint contributors. If a submitter still prefers the old workflow, they can keep filing patches in the bug tracker as before.

Feel free to improve the above text directly in the talk page. Add a watch to this page to note changes made by others.