[Sugar-devel] review process changes
tomeu at tomeuvizoso.net
Thu Jun 3 06:19:38 EDT 2010
On Thu, Jun 3, 2010 at 09:07, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Thu, 03-06-2010 a las 11:55 +1000, James Cameron escribió:
>> I don't see a way to make each module a project. The Patchwork project
>> "sugar" would have to encompass all Sugar modules and activities.
>> Patchwork prevents me from adding another project "paint" that shares
>> the same mailing list.
>> Bernie, do you agree with my assessment of Patchwork in this respect?
> I don't know Patchwork well enough to tell. I've installed it on request
> of Andres and others, but quite frankly I don't feel any necessity to
> augment the traditional email workflow with a web application.
> To track patches addressed to me, I simply keep them marked as unread
> until I've taken action, like I would do with any other message. Other
> people may prefer to use the "flag" bit or custom tags.
> To find reviews and new versions of the same patch, I simply use
> threading in my email client. To help maintain correct threading, both
> "git send-email" and "git format-patch" provide an --in-reply-to option
> to specify the Message-Id of the review.
> To help distinguish among several projects in the same mailing-list,
> git-format-patch provides a handy "--subject-prefix" option which we can
> set to sugar-toolkit, sugar-artwork, and so on.
> In the rare case that a patch really falls through the crack, whoever
> posted can simply resend it after a few days, or ping.
> Note: it's important to specify the maintainer(s) as --to of the patch,
> plus the mailing-list as --cc.
> This is the complete workflow for submitters:
Thanks, this is really useful. A few observations:
- how to link tickets and patches? One way is to always end the commit
message with a link to the bug: http://bugs.sugarlabs.org/ticket/1622
This is what git-bz does automatically. With proper email search, you
can get all tracmail and patch reviews with a single search.
- queue control: I still feel it will be harder to find the right
patch to review but at the same time, in all the other projects I
submit patches to, I need to ping people in irc to get them reviewed.
Should we move from a system with a strict queue to a ping-based
system? If so, we may need a "patch manager" as mentioned in
> 1) commit your changes
> git commit -s -v foo.py
> 2) create a patch
> git format-patch --subject-prefix=sugar-toolkit --in-reply-to=123456 -1
> 3) send patch to maintainer and mailing list
> git send-email --to erikos --cc sugar-devel 0001-foo.patch
> 4) wait for maintainer grant Acked-by tag
> while !acked(): sleep(1)
> 5) adjust patch to append any tags obtained (Reviewed-by, Tested-by, Acked-by...)
> git commit --amend
> 6) rebase and push to centralized repo
> git pull --rebase
> git push
> Steps 5-6 can be carried on by anyone.
> git-send-email can be fine-tuned for maximum comfort. This is my
> global .gitconfig:
> chainreplyto = false
> from = Bernie Innocenti <bernie at codewiz.org>
> aliasesfile = /home/bernie/.gitaliases
> aliasfiletype = mutt
> # requires a local SMTP server
> #smtpserver = /usr/sbin/sendmail
> # when smtp is blocked
> smtpserver = smtp.codewiz.org
> smtpuser = bernie
> smtpssl = true
> The .gitaliases is a big time saver. For Sugar, I have the following
> alias silbe Sascha Silbe <silbe at sugarlabs.org>
> alias tomeu Tomeu Vizoso <tomeu at tomeuvizoso.net>
> alias erikos Simon Schampijer <simon at schampijer.de>
> alias mstone Michael Stone <michael at laptop.org>
> alias anish Anish Mangal <anishmangal2002 at gmail.com>
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
More information about the Sugar-devel