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 ramez.ha...@nokia.com ___ 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 ramez.ha...@nokia.com 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 ramez.ha...@nokia.com 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 ramez.ha...@nokia.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Ramez Hanna ramez.ha...@nokia.com ___ 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 ryan.r.w...@intel.com wrote: On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna ramez.ha...@nokia.com 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 ramez.ha...@nokia.com 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 ramez.ha...@nokia.com ___ 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 ryan.r.w...@intel.com wrote: On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna ramez.ha...@nokia.com 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 ramez.ha...@nokia.com 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 ramez.ha...@nokia.com ___ 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 ramez.ha...@nokia.com ___ 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 ramez.ha...@nokia.com ___ 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 ramez.ha...@nokia.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
