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

[Aleksey Lim]

On Fri, May 07, 2010 at 04:34:56PM -0300, Andrés Ambrois wrote:
> 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.

Personally, I like scheme w/ such synchronization, because:

* we have central place w/ full history - bugs.sl.o
* we don't compel people to find/setup/implement new schemes to
  effective bugs tracking on their machines, they can just use bugs.sl.o
* having special checkbox for bugs.sl.o tickets, we can direct any (not
  only patches) ticket to devel@ to get wider feedback

> > > 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



-- 
Aleksey