Re: [MeeGo-dev] Specification for OBS light project concept
On Tue, 2011-06-14 at 11:52 +0300, ext Dominig ar Foll wrote: > Hello, > > those who have discussed with me during the MeeGo Conference in San > Francisco, know that I have started a small project to create a Light > version of OBS. > > The goal of the project is to ease the access to OBS for embedded > developers and initial investigation team which have to select an > embedded OS, by creating a tool which follows their traditional > development process (working locally in chroot) but keeps the > compatibility with the OBS. > > Some of the module that we are planning could potentially be of interest > for the real OBS (called Full OBS in my spec). In particular the the > automatic creation of patch files from a modified chroot and the UI for > MIC2 could become generic features. All created new code will be GPL2. > > Your feedback is welcome. All discussion will take place on the MeeGo > distribution-tools mailing list. > > http://lists.meego.com/listinfo/meego-distribution-tools > > The file is on the MeeGo Wiki. > > http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > the discussion had been going on and on in a very good direction, good criticism in general some agree and some are against. So maybe we could move a bit further by discussing about the solution details. I believe the proposal from dominiq has good points but tend to replace OBS on the developer machine, yes maintaining compatibility but almost replacing it i would tend to see it as an overkill. I guess we need to re-describe the problem and start talking about how to best solve it please feel free to edit the page http://wiki.meego.com/Release_Infrastructure/devroot with your view of the problem and solution so we can move forward with the solution Dominique i think it's time that you break radio silence. -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, 2011-07-01 at 10:51 -0700, ext Shane Bryan wrote: > On Fri, Jul 01, 2011 at 09:47:46AM -0700, Ware, Ryan R wrote: > > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna wrote: > > > On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > > > > > >> can you state *why*, I asked before but I never got a reply. Please, > > >> take some time to explain: > > >> > > >> - Why is current OBS insufficient for your development model? Would > > >> running another instance of OBS not suffice? > > > according to developers, they see OBS as a perfect system to deliver for > > > integration cycles, but slow for hack,build,test cycles prior to > > > integrating into product > > > > That would be because OBS isn't the tool they are supposed to be using > > for that. It's not a tool for hacking and testing. It's not a > > version control system. Trying to use it for that would be akin to > > trying to write your Linux development code with Microsoft Word > > running in Wine. It might be possible, but was never the intent of > > the tool. > > > > They should be doing their development using their standard processes > > with their normal version control system and then submitting a release > > once they are done hacking and testing. > > First, please don't take my following comments as endorsement or > opposition of the proposal, as I am really not in a position to do so, > nor would my endorsement matter. Having made that clear... > > Ryan, while I agree that OBS is most definately not a VCS tool applicable > to daily code development, I would have to disagree with your (apparent) > generalization that development does not ever need to coincide or overlap > the use of the release/packaging tools. > > As a developer who is also a package owner and maintainer of other > packages, I most definately have struggled with the turn-around time > when creating new packages, or updating existing packages that have had > changes in their installed files and/or build/run deps. Very often I > am rapidly iterating through .yaml(.spec) changes, or tweaking patches, > to get either the build to work, rpmlint to pass, or installed files > in the right place/config to actually work. This is a tedious and > often trial-and-error based process for which finding ways to streamline > it would definately be welcomed. Yes, experience helps, but there are > always corner cases, so the problem, in general, exists for developers > who care to ensure their release tar balls are as easy to integrate into > MeeGo as possible. > > Now, having said that, I will note that I could probably count on two > hands (and maybe one foot) the number of times in the last two years > that I've really had my productivity impacted by these issues, and the > thought of having yet-another-[tool|process] to use and *still* needing > to use osc/OBS to actually get the package SR'd into a project/release > does not sound like a real improvement. > > As suggested by Auke, I'd rather see the issues addressed w/in the scope > of the existing tools. I would tend to agree with that, but at least one item hits as not a good candidate for solving on OBS side speeding up the builds, OBS build functionality always starts from scratch, meaning it would cleanup the buildroot and do a clean build. then it also depends on having the source in tarball then it would unpack it I am suggesting to speedup the build process by skipping the packing/unpacking, and build inplace without cleaning the buildroot (run make and make install but not make clean) thus not rebuilding what make script thinks is unchanged these tweaks would not be a good thing to implement in OBS because in production you don't want that, you'd sacrifice the speed for a clean and reliable build > > Just my experience and opinion, > -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, 2011-07-01 at 11:26 -0700, ext Andy Ross wrote: > On 07/01/2011 10:59 AM, Kok, Auke-jan H wrote: > > I think Ryan is spot on. Until you get out of the hack-n-slash > > phase, your main development model should just be git, and ignore > > downstream. > > Yeah, but I'm with Shane on this. There's a big gap right now between > "I have a sandbox build with a fix and a patch" and "I have a working > package in OBS". And that gap is filled with traps, all of which > involve round trips to a known-finicky web app: > > + Have to remember the spectacle syntax again. > > + Patch collides with others: have to muck with ordering and respin. > > + Oops, forgot to update changes file (or just typo the date, builds >kick back if the dates aren't monotonic) > > + Oops, built in a Trunk project branch when I should have branched >MeeGo:1.2:oss. > > + It's built, but won't install cleanly from the resulting repo >because the OBS build numbers are lower than the real version (quick >hack is to update a file a dozen times here), and it's something >like qt or libmeegotouch with frightening interpackage dependencies. > > + Get everything ready, and just to annoy you OBS asks for a *third* >commit message (one in the patch, one in the .changes file, and a >third for the SR). Look up the bug number one last time... > > Add to that the fact that OBS projects are sometimes heavily patched, > and there's no straightforward path to turn an OBS project into a > buildable sandbox tree. The adaptation kernels and qt are really bad > in this respect. You can't meaningfully work with upstream code at > all for some things. > > And on top of it all, setting up OBS itself is really non-trivial. I > think something like this tool would be very useful, honestly, though > I think it's likely to be a ton of work to maintain. > > Andy > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines have you looked at my proposal at http://wiki.meego.com/Release_Infrastructure/devroot i think it should tackle some of things you already mentioned -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, 2011-07-01 at 10:59 -0700, ext Kok, Auke-jan H wrote: > On Fri, Jul 1, 2011 at 9:47 AM, Ware, Ryan R wrote: > > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna wrote: > >> On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > >>> On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna > >>> wrote: > >>> > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > >>> >> Hello, > >>> >> > >>> >> those who have discussed with me during the MeeGo Conference in San > >>> >> Francisco, know that I have started a small project to create a Light > >>> >> version of OBS. > >>> >> > >>> >> The goal of the project is to ease the access to OBS for embedded > >>> >> developers and initial investigation team which have to select an > >>> >> embedded OS, by creating a tool which follows their traditional > >>> >> development process (working locally in chroot) but keeps the > >>> >> compatibility with the OBS. > >>> >> > >>> >> Some of the module that we are planning could potentially be of > >>> >> interest > >>> >> for the real OBS (called Full OBS in my spec). In particular the the > >>> >> automatic creation of patch files from a modified chroot and the UI for > >>> >> MIC2 could become generic features. All created new code will be GPL2. > >>> >> > >>> >> Your feedback is welcome. All discussion will take place on the MeeGo > >>> >> distribution-tools mailing list. > >>> >> > >>> >> http://lists.meego.com/listinfo/meego-distribution-tools > >>> >> > >>> >> The file is on the MeeGo Wiki. > >>> >> > >>> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > >>> >> > >>> > I also got similar (if not exactly) requirements from some of our > >>> > internal developers, I have drafted a wiki page describing the reasons > >>> > we think we need a different tool than just osc/obs and some details of > >>> > the proposed implementation > >>> > I would like to get more feedback to be able to make this tool usefull > >>> > form more than just our internal developers > >>> > > >>> > Dominig I think we can work together on something here, our approach is > >>> > much simpler than the one you propose > >>> > maybe we can find some middle ground. > >>> > >>> can you state *why*, I asked before but I never got a reply. Please, > >>> take some time to explain: > >>> > >>> - Why is current OBS insufficient for your development model? Would > >>> running another instance of OBS not suffice? > >> according to developers, they see OBS as a perfect system to deliver for > >> integration cycles, but slow for hack,build,test cycles prior to > >> integrating into product > > > > That would be because OBS isn't the tool they are supposed to be using > > for that. It's not a tool for hacking and testing. It's not a > > version control system. Trying to use it for that would be akin to > > trying to write your Linux development code with Microsoft Word > > running in Wine. It might be possible, but was never the intent of > > the tool. > > > > They should be doing their development using their standard processes > > with their normal version control system and then submitting a release > > once they are done hacking and testing. > > I'm having a hard time with this as well, and I did not still get an > answer from Dominig describing his specific concerns either, which > doesn't help. > > I think Ryan is spot on. Until you get out of the hack-n-slash phase, > your main development model should just be git, and ignore downstream. > This is what most developers do, and widely accepted as the most > flexible way to develop: You get to pick the development target, > replace components at will, and when you're ready to integrate, you > start with OBS. > > Those parts will not change, so adding an artificial step in between > where you're both developing and integrating, seems detrimental to me, > and just will add to the process overhead for developers: Now they > need to work with a 3rd toolset. my approach is to simplify the work they do but not introduce a third tool set or a artificial step a wrapper command that will allow them to create a chroot, update it when needed, build in the same way obs does (using obs build script) while modifying the build steps a bit to make it faster > > I can't think but this is a bad idea to spend a lot of time on. no it's not, think of different developers than your typical oss developers, as dominiq mentions he is focused on embedded developers, i am also dealing with developers that want to only focus on writing code and don't want to worry about how to build, which makes a init/build/test tool > > Auke -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, 2011-07-01 at 10:59 -0700, ext Kok, Auke-jan H wrote: > On Fri, Jul 1, 2011 at 9:47 AM, Ware, Ryan R wrote: > > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna wrote: > >> On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > >>> On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna > >>> wrote: > >>> > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > >>> >> Hello, > >>> >> > >>> >> those who have discussed with me during the MeeGo Conference in San > >>> >> Francisco, know that I have started a small project to create a Light > >>> >> version of OBS. > >>> >> > >>> >> The goal of the project is to ease the access to OBS for embedded > >>> >> developers and initial investigation team which have to select an > >>> >> embedded OS, by creating a tool which follows their traditional > >>> >> development process (working locally in chroot) but keeps the > >>> >> compatibility with the OBS. > >>> >> > >>> >> Some of the module that we are planning could potentially be of > >>> >> interest > >>> >> for the real OBS (called Full OBS in my spec). In particular the the > >>> >> automatic creation of patch files from a modified chroot and the UI for > >>> >> MIC2 could become generic features. All created new code will be GPL2. > >>> >> > >>> >> Your feedback is welcome. All discussion will take place on the MeeGo > >>> >> distribution-tools mailing list. > >>> >> > >>> >> http://lists.meego.com/listinfo/meego-distribution-tools > >>> >> > >>> >> The file is on the MeeGo Wiki. > >>> >> > >>> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > >>> >> > >>> > I also got similar (if not exactly) requirements from some of our > >>> > internal developers, I have drafted a wiki page describing the reasons > >>> > we think we need a different tool than just osc/obs and some details of > >>> > the proposed implementation > >>> > I would like to get more feedback to be able to make this tool usefull > >>> > form more than just our internal developers > >>> > > >>> > Dominig I think we can work together on something here, our approach is > >>> > much simpler than the one you propose > >>> > maybe we can find some middle ground. > >>> > >>> can you state *why*, I asked before but I never got a reply. Please, > >>> take some time to explain: > >>> > >>> - Why is current OBS insufficient for your development model? Would > >>> running another instance of OBS not suffice? > >> according to developers, they see OBS as a perfect system to deliver for > >> integration cycles, but slow for hack,build,test cycles prior to > >> integrating into product > > > > That would be because OBS isn't the tool they are supposed to be using > > for that. It's not a tool for hacking and testing. It's not a > > version control system. Trying to use it for that would be akin to > > trying to write your Linux development code with Microsoft Word > > running in Wine. It might be possible, but was never the intent of > > the tool. > > > > They should be doing their development using their standard processes > > with their normal version control system and then submitting a release > > once they are done hacking and testing. > > I'm having a hard time with this as well, and I did not still get an > answer from Dominig describing his specific concerns either, which > doesn't help. > > I think Ryan is spot on. Until you get out of the hack-n-slash phase, > your main development model should just be git, and ignore downstream. > This is what most developers do, and widely accepted as the most > flexible way to develop: You get to pick the development target, > replace components at will, and when you're ready to integrate, you > start with OBS. > > Those parts will not change, so adding an artificial step in between > where you're both developing and integrating, seems detrimental to me, > and just will add to the process overhead for developers: Now they > need to work with a 3rd toolset. my approach is to simplify the work they do but not introduce a third tool set or a artificial step a wrapper command that will allow them to create a chroot, update it when needed, build in the same way obs does (using obs build script) while modifying the build steps a bit to make it faster > > I can't think but this is a bad idea to spend a lot of time on. no it's not, think of different developers than your typical oss developers, as dominiq mentions he is focused on embedded developers, i am also dealing with developers that want to only focus on writing code and don't want to worry about how to build, which makes a init/build/test tool for them a good solution the customers for this tool are different than you > > Auke -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, 2011-07-01 at 09:47 -0700, ext Ware, Ryan R wrote: > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna wrote: > > On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > >> On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna wrote: > >> > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > >> >> Hello, > >> >> > >> >> those who have discussed with me during the MeeGo Conference in San > >> >> Francisco, know that I have started a small project to create a Light > >> >> version of OBS. > >> >> > >> >> The goal of the project is to ease the access to OBS for embedded > >> >> developers and initial investigation team which have to select an > >> >> embedded OS, by creating a tool which follows their traditional > >> >> development process (working locally in chroot) but keeps the > >> >> compatibility with the OBS. > >> >> > >> >> Some of the module that we are planning could potentially be of interest > >> >> for the real OBS (called Full OBS in my spec). In particular the the > >> >> automatic creation of patch files from a modified chroot and the UI for > >> >> MIC2 could become generic features. All created new code will be GPL2. > >> >> > >> >> Your feedback is welcome. All discussion will take place on the MeeGo > >> >> distribution-tools mailing list. > >> >> > >> >> http://lists.meego.com/listinfo/meego-distribution-tools > >> >> > >> >> The file is on the MeeGo Wiki. > >> >> > >> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > >> >> > >> > I also got similar (if not exactly) requirements from some of our > >> > internal developers, I have drafted a wiki page describing the reasons > >> > we think we need a different tool than just osc/obs and some details of > >> > the proposed implementation > >> > I would like to get more feedback to be able to make this tool usefull > >> > form more than just our internal developers > >> > > >> > Dominig I think we can work together on something here, our approach is > >> > much simpler than the one you propose > >> > maybe we can find some middle ground. > >> > >> can you state *why*, I asked before but I never got a reply. Please, > >> take some time to explain: > >> > >> - Why is current OBS insufficient for your development model? Would > >> running another instance of OBS not suffice? > > according to developers, they see OBS as a perfect system to deliver for > > integration cycles, but slow for hack,build,test cycles prior to > > integrating into product > > That would be because OBS isn't the tool they are supposed to be using > for that. It's not a tool for hacking and testing. It's not a > version control system. Trying to use it for that would be akin to > trying to write your Linux development code with Microsoft Word > running in Wine. It might be possible, but was never the intent of > the tool. that's exactly what i had in mind, i couldn't have said it better > > They should be doing their development using their standard processes > with their normal version control system and then submitting a release > once they are done hacking and testing. my goal is to simplify the sandbox development using a wrapper command and allowing it to read some info from OBS to be as close as possible to OBS's build result > > Ryan > > >> > >> - Why can't the current OBS software be enhanced to better provide the > >> needed features? > > in my solution we are trying to reuse osc/obs tools/apis to solve it not > > reimplement OBS > >> > >> Given that you and Dominig both state "it's needed", it should be > >> trivial to answer these questions. > > the way obs builds has a few slowing down points, of these are > > 1. you need to archive, then push it to obs, then obs would unpack to > > start building > > 2. everytime it biulds it starts from scratch, while if you oatch and > > rerun make, you would spare yourself some time in building > > > > and osc/obs allows you to build locally and reusing chroots yes but you > > need to do things manually, while as dominig states in his document that > > embeded developers are more comfortable with local build tools > > and it seems also that th espeed factor is very important for some QT > > developers > >> > >> Auke > > > > -- > > Ramez Hanna > > > > ___ > > MeeGo-dev mailing list > > MeeGo-dev@meego.com > > http://lists.meego.com/listinfo/meego-dev > > http://wiki.meego.com/Mailing_list_guidelines > > -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Thu, 2011-06-30 at 13:31 +0100, ext Robin Burchell wrote: > Hi, > > On 30/06/11 13:09, Ramez Hanna wrote: > > I also got similar (if not exactly) requirements from some of our > > internal developers, I have drafted a wiki page describing the reasons > > we think we need a different tool than just osc/obs and some details of > > the proposed implementation > > Do you have a link to this wiki page? > > -- > Robin Burchell > http://rburchell.com > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines forgot to put it in my first post, here it is http://wiki.meego.com/Release_Infrastructure/devroot -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna wrote: > > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > >> Hello, > >> > >> those who have discussed with me during the MeeGo Conference in San > >> Francisco, know that I have started a small project to create a Light > >> version of OBS. > >> > >> The goal of the project is to ease the access to OBS for embedded > >> developers and initial investigation team which have to select an > >> embedded OS, by creating a tool which follows their traditional > >> development process (working locally in chroot) but keeps the > >> compatibility with the OBS. > >> > >> Some of the module that we are planning could potentially be of interest > >> for the real OBS (called Full OBS in my spec). In particular the the > >> automatic creation of patch files from a modified chroot and the UI for > >> MIC2 could become generic features. All created new code will be GPL2. > >> > >> Your feedback is welcome. All discussion will take place on the MeeGo > >> distribution-tools mailing list. > >> > >> http://lists.meego.com/listinfo/meego-distribution-tools > >> > >> The file is on the MeeGo Wiki. > >> > >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > >> > > I also got similar (if not exactly) requirements from some of our > > internal developers, I have drafted a wiki page describing the reasons > > we think we need a different tool than just osc/obs and some details of > > the proposed implementation > > I would like to get more feedback to be able to make this tool usefull > > form more than just our internal developers > > > > Dominig I think we can work together on something here, our approach is > > much simpler than the one you propose > > maybe we can find some middle ground. > > can you state *why*, I asked before but I never got a reply. Please, > take some time to explain: > > - Why is current OBS insufficient for your development model? Would > running another instance of OBS not suffice? according to developers, they see OBS as a perfect system to deliver for integration cycles, but slow for hack,build,test cycles prior to integrating into product > > - Why can't the current OBS software be enhanced to better provide the > needed features? in my solution we are trying to reuse osc/obs tools/apis to solve it not reimplement OBS > > Given that you and Dominig both state "it's needed", it should be > trivial to answer these questions. the way obs builds has a few slowing down points, of these are 1. you need to archive, then push it to obs, then obs would unpack to start building 2. everytime it biulds it starts from scratch, while if you oatch and rerun make, you would spare yourself some time in building and osc/obs allows you to build locally and reusing chroots yes but you need to do things manually, while as dominig states in his document that embeded developers are more comfortable with local build tools and it seems also that th espeed factor is very important for some QT developers > > Auke -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > Hello, > > those who have discussed with me during the MeeGo Conference in San > Francisco, know that I have started a small project to create a Light > version of OBS. > > The goal of the project is to ease the access to OBS for embedded > developers and initial investigation team which have to select an > embedded OS, by creating a tool which follows their traditional > development process (working locally in chroot) but keeps the > compatibility with the OBS. > > Some of the module that we are planning could potentially be of interest > for the real OBS (called Full OBS in my spec). In particular the the > automatic creation of patch files from a modified chroot and the UI for > MIC2 could become generic features. All created new code will be GPL2. > > Your feedback is welcome. All discussion will take place on the MeeGo > distribution-tools mailing list. > > http://lists.meego.com/listinfo/meego-distribution-tools > > The file is on the MeeGo Wiki. > > http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > I also got similar (if not exactly) requirements from some of our internal developers, I have drafted a wiki page describing the reasons we think we need a different tool than just osc/obs and some details of the proposed implementation I would like to get more feedback to be able to make this tool usefull form more than just our internal developers Dominig I think we can work together on something here, our approach is much simpler than the one you propose maybe we can find some middle ground. -- Ramez Hanna ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
