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

[Aleksey Lim]

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

> 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