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 <ramez.ha...@nokia.com> wrote: > > > On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: > > <snip> > > > >> 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 <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
