On Wed, May 26, 2010 at 01:48:17PM +0200, Tomeu Vizoso wrote: > == Changes I would like to see == > > * Having _all_ reviews in the mailing list. The process already allows > patches to be sent and discussed in the mailing list, but restricts it > to "new feature[s] and reasonably big".
It also says under 2000 lines does not need breaking into separate commits. ;-) I think it is not good to set such limits, instead rely on feedback during review. > * Reduce the time spent creating and changing tickets in Trac A command line interface would be nice. I'm on a high latency connection, working from outback Australia. > == Issues I need help with == > > * How can a maintainer keep track of his queue with something like > http://bugs.sugarlabs.org/wiki/TomeuReviewQueue if patches are sent to > the list? Bernie has suggested Patchwork. I've investigated it some more ... Initial configuration: You should do this; visit http://patchwork.sugarlabs.org/ ... register ... wait for e-mail ... login ... tell Bernie or myself your username, we shall add you as a "maintainer" of "sugar" using the admin interface ... until then your username is not available in the list of delegate targets. Ongoing usage ... triage: You should do this; http://patchwork.sugarlabs.org/project/sugar/list/ ... for patches that are New, click on them, delegate to a maintainer, can be done by you or by other users of patchwork. Ongoing usage ... maintainer todo list: You should do this; http://patchwork.sugarlabs.org/user/todo/ ... displays the patches that the maintainer has in their TODO list. Things to note: - "maintainer" in Patchwork means you have the right to approve patches for a "project". - temporarily Patchwork instance has all user profiles marked as "maintainer", but this should change later. - other successful projects using Patchwork typically have a one to one mapping between mailing list and git repository. We don't have that. > * How can we make sure that patches don't fall through the cracks? That remains a problem with any process, and was a problem with the existing process, and the Patchwork tool should provide a partial control. Patchwork will help maintainers track the state of a patch external to mail applications. > * How can I know if the patch I'm staring at is the latest version? Check for later mail by same author (if they did not post mail, that's their fault), check for a repository or branch offer. > * How can we make easy to go from git blame to the review thread, the > bug report and the feature page? Search your mail for the patch hash and display the results as a thread? I use mairix for this, with mutt as the display engine. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel