On Thu, Jun 3, 2010 at 09:07, Bernie Innocenti <ber...@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 http://producingoss.com/en/producingoss.html#patch-manager Regards, Tomeu > 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: > > ---cut--- > [sendemail] > chainreplyto = false > from = Bernie Innocenti <ber...@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 > ---cut--- > > The .gitaliases is a big time saver. For Sugar, I have the following > entries: > > ---cut--- > alias silbe Sascha Silbe <si...@sugarlabs.org> > alias tomeu Tomeu Vizoso <to...@tomeuvizoso.net> > alias erikos Simon Schampijer <si...@schampijer.de> > alias mstone Michael Stone <mich...@laptop.org> > alias anish Anish Mangal <anishmangal2...@gmail.com> > ---cut--- > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel