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 <[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. 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 <[email protected]> > > > > _______________________________________________ > > MeeGo-dev mailing list > > [email protected] > > http://lists.meego.com/listinfo/meego-dev > > http://wiki.meego.com/Mailing_list_guidelines > > -- Ramez Hanna <[email protected]> _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
