On Fri, Jul 1, 2011 at 9:47 AM, Ware, Ryan R <[email protected]> wrote: > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna <[email protected]> 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 <[email protected]> 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. I can't think but this is a bad idea to spend a lot of time on. Auke _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
