[Sugar-devel] review process changes

James Cameron quozl at laptop.org
Wed Jun 2 21:55:22 EDT 2010


On Wed, Jun 02, 2010 at 11:45:57AM +0200, Tomeu Vizoso wrote:
> On Thu, May 27, 2010 at 08:44, James Cameron <quozl at laptop.org> wrote:
> > On Wed, May 26, 2010 at 01:48:17PM +0200, Tomeu Vizoso wrote:
> >> == 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?
> >
> > 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.
> 
> Created an account, I guess we can make each module in
> http://wiki.sugarlabs.org/go/Development_Team/Release/Modules a
> project with their own maintainers?

I've added you as a "maintainer" of "sugar" using the admin interface.

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?

> > 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.
> 
> This gets messy very quickly and would be a sad regression from the
> existing system.

I don't think so.  Quite frequently I'm looking at tickets with patches
that aren't the latest version.

> Patchwork's queue doesn't display what is thought to
> be the patch awaiting review? If so, submitters could check by
> themselves that the reviewer is going to look at the correct patch.

Now that you have access, you can test this.  It displays what is
selected.  Whether a patch is superceded or not depends on someone
noticing that and marking the patch that way in the incoming patches
view.

http://patchwork.sugarlabs.org/project/sugar/list/

> >> * 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.
> 
> That sounds like another regression to me, cannot do better than that?

I don't know.

> Thanks a lot for your comments. What about the other patch submitters?
> Are they happy with the system in place?

Good question.

-- 
James Cameron
http://quozl.linux.org.au/


More information about the Sugar-devel mailing list