Talk:Development Team/Code Review - Revision history

Alsroot: /* Revised patches */

2010-12-18T05:17:49Z

Revised patches

← Older revision		Revision as of 01:17, 18 December 2010
Line 39:		Line 39:
	Sounds inpractical and needles complicated, from one point all email clients support thread, from another point, with mail basis patch tracking (using only email client) there is no way to have thread status.		Sounds inpractical and needles complicated, from one point all email clients support thread, from another point, with mail basis patch tracking (using only email client) there is no way to have thread status.
	If patch tracking systems can't detect current status w/o setting subjects it needs to be fixed, otherwise it becomes annoying from patch submitter pov.		If patch tracking systems can't detect current status w/o setting subjects it needs to be fixed, otherwise it becomes annoying from patch submitter pov.

			''v1->v2:'' also might be questionable, having it in git log is useless (since the full story is in email thread). At the same time, if there is a need out-of-git-log comments, it might happen in --compose mode.

Alsroot: /* Revised patches */ new section

2010-12-18T05:14:14Z

Revised patches: new section

← Older revision		Revision as of 01:14, 18 December 2010
Line 32:		Line 32:
	Feel free to improve the above text directly in the talk page. Add a watch to this		Feel free to improve the above text directly in the talk page. Add a watch to this
	page to note changes made by others.		page to note changes made by others.

			== Revised patches ==

			''add a version number to the subject prefix (e.g. git send-email --subject-prefix="PATCH v2 sugar")''

			Sounds inpractical and needles complicated, from one point all email clients support thread, from another point, with mail basis patch tracking (using only email client) there is no way to have thread status.
			If patch tracking systems can't detect current status w/o setting subjects it needs to be fixed, otherwise it becomes annoying from patch submitter pov.

Bernie: 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..."

2010-09-03T11:53:56Z

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..."

New page

== 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 [http://lxr.linux.no/linux/Documentation/SubmittingPatches 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.