On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > These are really the only high-priority outstanding issues with develop as > it stands (aside from translation and broader testing). And the process of > code review does not appear to be working for me, I have a patch for the > first of these issues which has languished for months.
Sorry about that. Using the mailing list for code review is great because everyone can be involved in the process. But we also need to figure out a way to keep trac of patches that needs review. I think we should figure out a way to use trac in combination with mailing lists to achieve that effect. I started a wiki page for this reason a few days ago but I have not had time to come up with a proposal yet: http://wiki.sugarlabs.org/go/CodeReview Anyone feels like thinking this through and come up with a proposal for discussion? > From where I'm > sitting, it would be nice if checkin capability on joyride were more > liberally granted (with some specific community norms about self-review), > and the strict third-party review requirement were a filter when > cherrypicking changes FROM joyride, not into it. I think commit rules are and should keep to be dictated at the upstream project level. The solution to slow reviews is not to abolish them or to delay them in the distribution process. I think we can resolve the issue by making to-review patches easier to track and by getting more peers for the glucose modules. I also would like to understand if this is happening generally or just for the patches you are mentioning. I had not heard people complaining about slow reviews so far. Marco _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar