On 07/06/2011 12:14 PM, Ramez Hanna wrote:
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<[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.
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
I don't see a reason why one could not add a "no-clean-buildroot" option
to the builder in OBS to solve this. Having this option does not mean it
has to be used when OBS is used as a buildbot for production.
Related: Another option that would be nice for OBS to have in this area
is to start from a base image/rootfs (instead of building it up from
scratch each time).
--
Jon Nordby - www.jonnor.com
Software Developer, Openismus GmbH - www.openismus.com
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
