Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
On Thu, May 6, 2010 at 23:55, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: 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 cutpasted into the ticket? As the process in the wiki explains (linked above), a link to the archived thread is enough. Just make sure that the maintainer has somewhere the patch as proposed for merging. Regards, Tomeu CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCgAGBQJL4zrkAAoJELpz82VMF3Dak9AIALGRERRnDFMB51lNYj1YTHdF hDYHxFuJSEmlyVZsDi2DTzyBanqjxaCX9uss+zWatZLMNqCqWxTu+2ZjWk7uAqFu GE0ACpcneGKi24z3Dsvp/+jfDM53/S2frSuFUpWyZ03nzZSXbVEBYQczHqFWOWoo n+sYnP/UXGvt057Yl2hEx14LZOGGrrzx8ngKp5hoWukQXfEQibx1Q1QsMNfSIT8d kVwxyzQGDoqA4tWB7gwaTX2Zml2mkl/pLgHH7jXJ0hPlj2LuQbc3TOFhNAjoze4p Brx0EACKvHwSTeu2oh4L+SbFR2kH0ohMa1YHorNRvSD1vWZRnDW8t4bQa2sHreA= =i6lm -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
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 cutpasted 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. 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 11:17 -0400, Bernie Innocenti escribió: 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 cutpasted 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. 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 And also: dottedmag bernie: full bugmail log is usually read by much smaller amount of developers than the development mailing list, this seems to be a critical distintction. antrik bernie: simple answer is that anything that requires even the slightiest extra work considerably reduces the chance anyone will take the trouble -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
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 cutpasted 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
On Fri, May 7, 2010 at 12:43 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 11:17:36AM -0400, Bernie Innocenti wrote: Patches posted to the list quickly received a lot of feedback, including Patches via the mailinglist are great. Has my vote :-) My only concern about mailing list scheme is that I as component maintainer will have to setup my mail client to effectively track patches Good point. We can ask on the git list where Junio keeps track of maint, and pu (proposed updates), all on one list. In general, people mention below the fold (git discards anything in the commit msg after a left-aligned -- separator) which branch is meant to. On the git list we also use a number of tools that make life easier -- I cannot remember the name but we have a bot that scans the mailing list and extracts patches and keeps track of unapplied ones. On the linux kernel, the mailing list usually hints at the appropriate branch ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 16:43 +, 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/ 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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
On Fri, May 07, 2010 at 02:44:04PM -0400, Bernie Innocenti wrote: El Fri, 07-05-2010 a las 16:43 +, 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
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 +, 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- -Andrés -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 16:34 -0300, Andrés Ambrois escribió: * some is seeing commit in `git log` and wants to see discussion thread in existed scheme, every (in ideal) commit should have ticket number In the kernel, I usually search for lkml few words from the comment. You could even click I'm feeling lucky most of the times. Traceability of patches in the absence of a bug tracker is really a non-issue even for projects a lot bigger and more mature than Sugar. 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 can try install it and see what we can get out of it. If nobody else volunteers to do it, I'll give it a shot this w/e. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
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 cutpasted into the ticket? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
Hi, Simon and me discussed when to release 0.88.1 and are targeting for May 18, thus having tarballs ready on May 17. Do the other maintainers agree? 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 Cheers, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
