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 <[email protected]> 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. Just my experience and opinion, -- Shane... _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
