[Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17

[Aleksey Lim]

On Fri, May 07, 2010 at 11:17:36AM -0400, Bernie Innocenti wrote:
> El Thu, 06-05-2010 a las 23:55 +0200, Sascha Silbe escribió:
> > On Wed, May 05, 2010 at 01:49:23PM +0200, Tomeu Vizoso wrote:
> > 
> > > We are also scheduling some time to go through the review queue on
> > > Tuesday May 11th afternoon (UTC) and on Monday May 17th. Would be
> > > great if patch submitters could check that their patches have followed
> > > the current process and also that any volunteers pre-reviewed the
> > > code, some links follow:
> > >
> > > http://wiki.sugarlabs.org/go/0.88/Roadmap
> > > http://wiki.sugarlabs.org/go/Development_Team/Code_Review
> > > http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines
> > 
> > Does that mean that all patches that are destined for 0.88.x and were 
> > reviewed on the mailing list need to go through review again and thus 
> > need to have a ticket created for them, have the patch attached to the 
> > ticket and mailing list review comments cut&pasted into the ticket?
> 
> Patches posted to the list quickly received a lot of feedback, including
> testing and reviews. Unless this was the only way to get them ack'd by a
> maintainer, I'd rather not go back to bury all our patches into the bug
> tracker where they don't get nearly as much exposure.

My only concern about mailing list scheme is that I as component
maintainer will have to setup my mail client to effectively track
patches that should go to particular release e.g. patches to current dev
branch, patches to backport to some of released branches. It is easy w/
bugs.sl.o since there are special fields. We can provide such useful
info in email posts but it should be handled somehow in various email
clients.

Not sure how this issue is handled in projects like xorg or kernel,
at the end we can ask patch submitters to create a ticket if they want
their patches to be included to particular release or even better, in
git post commit scripts, update/create appropriate ticket.

> For informational purposes, it may make sense to also attach or link the
> patches to the ticket... this is orthogonal with we conduct our review
> process.
> 
> Here's an example of a project that allows reviews to be done both in
> the bug tracker and on the mailing list:
> 
>  http://www.x.org/wiki/Development/Documentation/SubmittingPatches
> 
> However, most patches go through the list these days. I asked on
> #xorg-devel if there were some rationale behind the switch, and these
> are the answers I got:
> 
> <bernie> ajax, daniels, whot: was there a public discussion when xorg
> switched from doing reviews in bugzilla to doing them in the mailing
> list?
> <remi|work> bernie, it was more or less happening that way already,
> since git makes it so easy to send patches via email
> <ajax> probably in the notes about whichever xdc that was where we
> talked about it...
> <alanc> I'm not sure there was a lot more analysis beyond "this is what
> the Linux kernel process is, so this is the way git was designed to work
> and the process a lot of the same developers already have to deal with
> for DRI, and it works there, while we clearly aren't reviewing the
> patches in bugzilla that get ignored there for years"
> 
> -- 
>    // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
> 
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-- 
Aleksey