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

[Andrés Ambrois]

On Friday 07 May 2010 04:26:45 pm Aleksey Lim wrote:
> On Fri, May 07, 2010 at 02:44:04PM -0400, Bernie Innocenti wrote:
> > El Fri, 07-05-2010 a las 16:43 +0000, Aleksey Lim escribió:
> > > 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.
> > 
> > In kernel land, when someone wants their patch to be applied to the
> > stable series they just Cc the maintainer of the stable series when
> > sending the patch to lkml.
> > 
> > Then, each subsystem maintainer has their own favorite ways to manage
> > incoming patches. Linus said once that he just presses one key in mutt
> > to save each patch he likes to a directory "to_apply" that he later
> > examines.
> > 
> > Andrew Morton and others use more advanced patch queue management tools
> > such as Guilt and StGit:
> > 
> >  http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/man/
> >  http://www.procode.org/stgit/
> > 
> > 
> > Personally, I use a hierarchy of four directories to remember
> > outstanding patches to be sent to various upstream projects:
> > 
> >   http://people.sugarlabs.org/bernie/patches/
> 
> Thats all ok for personal usage, but what about usecases like:
> 
> * release manager decided to shift patch from 0.88 to 0.90 release cycle
>   how it could be processed in ml scheme, should release manage send
>   email to appropriate thread, should every interested developer setup
>   his personal env to see all time current (not value from initial
>   post) targeted release
>   
> * some is seeing commit in `git log` and wants to see discussion thread
>   in existed scheme, every (in ideal) commit should have ticket number
> 
> Thats why I'm thinking about having some kind of duplication to
> bugs.sl.o as easy way to know about current status.
> 
> BTW bugs.sl.o sends all posts to bugs@, we can direct posts from tickets
> that contain patches to devel@ and implement back direct from ml to
> bugs.sl.o (if someone prefers only ml).

Seems like this was design to help with some of these worries:
http://ozlabs.org/~jk/projects/patchwork/

You can see it in action at http://patchwork.kernel.org.

+1 to synchronizing Trac with the ML and vice versa.

> > We could also take the habit to mark patches in the subjects with tags
> > such as "[0.84] [0.86]".
> > 
> > Hopefully, the current mess of 3 or 4 versions of Sugar to be supported
> > in parallel is only transient: if we're successful in reconciling
> > deployments with upstream, there should be only one version of Sugar in
> > maintenance mode and one under active development.
> > 
> > -- 
> >    // Bernie Innocenti - http://codewiz.org/
> >  \X/  Sugar Labs       - http://sugarlabs.org/
> > 
> 
> -- 
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 

-- 
  -Andrés
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100507/9b7f7eb4/attachment.pgp