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