Re: Frequency of build breaks ?
I recall some discussion concerning the August Tizen 3.0 release-- I think there were some packages that were not building then, not even on OBS. What I remember is that in those cases an older (upstream?) package was substituted to allow the image to be built. As I understood it at the time the intent was to produce a "best case" working image for development while acknowledging that packages *could* be broken. A good compromise, so long as you weren't dependent on one of the broken packages--but it could lead to unexpected surprises if you wanted to work on (or use as a client) one of the packages that wasn't building. I don't remember if there was any (official) list of packages that had been substituted. Paul Paul Hanchett --- Infotainment Engineer MSX on behalf of Jaguar Land Rover One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: phanc...@jaguarlandrover.com --- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 On Wed, Jan 29, 2014 at 4:50 AM, VanCutsem, Geoffroy < geoffroy.vancut...@intel.com> wrote: > On Tue, 2014-01-28 at 20:22 -0800, Hanchett, Paul wrote: > > There may be some semantics at play here, too. > > > > > > As I understand it, the releases that Tracy mentions are built from > > binaries produced by the OBS build system, and almost certainly won't > > be in sync with the repositories you'll get by doing a "repo > > sync"--OBS builds from gerrit-curated sources, not the development tip > > of the repositories (which is what you typically get with a sync...) > > Since GBS builds from the local repositories on your machine, the > > results of a GBS build won't necessarily line up with those from OBS. > This is correct if you use the following procedure: > - $repo init -u review.tizen.org:/scm/manifest -b tizen -m ivi.xml > - $repo sync > In this case, the difference will be that some git repositories may/will > be ahead of what is in OBS (i.e. this will be the case if new code has > been merged following a review but not yet pushed to OBS by the > maintainer using 'gbs submit'). > > If you wish to clone the *exact* source code for a daily (or any other) > image, you could use the manifest file that is published alongside such > image, e.g.: > -For all packages available in the repo: > > http://download.tizen.org/releases/daily/tizen/ivi/ivi/latest/builddata/manifest/tizen_20140128.20_ia32.xml > - For all packages that are pre-installed in the image (subset of > above): > > http://download.tizen.org/releases/daily/tizen/ivi/ivi/latest/images/ivi-mbr-i586/tizen_20140128.20-ivi-mbr-i586.manifest.xml > > > > > > > (At least, I *think* it's true that syncing repositories gets the > > latest that's been checked in, not the latest approved in gerrit...) > That's correct as per my understanding. > > > > > > This is definitely an oversimplification, but I think it's true as far > > as it goes. I'm sure others will point out any inaccuracies! ;-) > > > > > > Paul > > > > > > > > > > Paul Hanchett > > --- > > Infotainment Engineer > > MSX on behalf of Jaguar Land Rover > > One World Trade Center, 121 Southwest Salmon Street, 11th Floor, > > Portland, Oregon, 97204 > > > > Email: phanc...@jaguarlandrover.com > > --- > > > > Business Details: > > Jaguar Land Rover Limited > > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF > > Registered in England No: 1672070 > > > > > > On Tue, Jan 28, 2014 at 2:16 PM, Graydon, Tracy > > wrote: > > Hi Mark, > > > > Well, much depends on how you define "build breaks." If we are > > talking about the relative stability of images, which is what > > I think you are saying, then yes, it definitely goes up and > > down depending on what we are trying to accomplish at a given > > point in the development cycle. > > > > You don't mention which "latest" versions you are using, so I > > will outline the various sources for images with their > > relative stability/quality levels: > > > > Snapshots: http://download.tizen.org/snapshots/tizen/ivi/ivi/ > > > > These are "intermediate" builds that result from accepting new > > changes into Tizen:IVI over the course of the day. These are > > images that we DO NOT recommend you use. When developers > > submit changes, they may check these images and the build logs > > to sanity check their changes. However, there is absolutely no > > guarantee that these images will boot, muchless perform as > > expected. They are strictly "use at your own risk." > > > > Daily Releases: > > http://download.tizen.org/releases/daily/tizen/ivi/ivi/ > > > > These are the culmination of the days' changes. Release > > Engineering "smoke tests" these to ensure that they meet some
Re: Frequency of build breaks ?
On Tue, 2014-01-28 at 20:22 -0800, Hanchett, Paul wrote: > There may be some semantics at play here, too. > > > As I understand it, the releases that Tracy mentions are built from > binaries produced by the OBS build system, and almost certainly won't > be in sync with the repositories you'll get by doing a "repo > sync"--OBS builds from gerrit-curated sources, not the development tip > of the repositories (which is what you typically get with a sync...) > Since GBS builds from the local repositories on your machine, the > results of a GBS build won't necessarily line up with those from OBS. This is correct if you use the following procedure: - $repo init -u review.tizen.org:/scm/manifest -b tizen -m ivi.xml - $repo sync In this case, the difference will be that some git repositories may/will be ahead of what is in OBS (i.e. this will be the case if new code has been merged following a review but not yet pushed to OBS by the maintainer using 'gbs submit'). If you wish to clone the *exact* source code for a daily (or any other) image, you could use the manifest file that is published alongside such image, e.g.: -For all packages available in the repo: http://download.tizen.org/releases/daily/tizen/ivi/ivi/latest/builddata/manifest/tizen_20140128.20_ia32.xml - For all packages that are pre-installed in the image (subset of above): http://download.tizen.org/releases/daily/tizen/ivi/ivi/latest/images/ivi-mbr-i586/tizen_20140128.20-ivi-mbr-i586.manifest.xml > > > (At least, I *think* it's true that syncing repositories gets the > latest that's been checked in, not the latest approved in gerrit...) That's correct as per my understanding. > > > This is definitely an oversimplification, but I think it's true as far > as it goes. I'm sure others will point out any inaccuracies! ;-) > > > Paul > > > > > Paul Hanchett > --- > Infotainment Engineer > MSX on behalf of Jaguar Land Rover > One World Trade Center, 121 Southwest Salmon Street, 11th Floor, > Portland, Oregon, 97204 > > Email: phanc...@jaguarlandrover.com > --- > > Business Details: > Jaguar Land Rover Limited > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF > Registered in England No: 1672070 > > > On Tue, Jan 28, 2014 at 2:16 PM, Graydon, Tracy > wrote: > Hi Mark, > > Well, much depends on how you define “build breaks.” If we are > talking about the relative stability of images, which is what > I think you are saying, then yes, it definitely goes up and > down depending on what we are trying to accomplish at a given > point in the development cycle. > > You don’t mention which “latest” versions you are using, so I > will outline the various sources for images with their > relative stability/quality levels: > > Snapshots: http://download.tizen.org/snapshots/tizen/ivi/ivi/ > > These are “intermediate” builds that result from accepting new > changes into Tizen:IVI over the course of the day. These are > images that we DO NOT recommend you use. When developers > submit changes, they may check these images and the build logs > to sanity check their changes. However, there is absolutely no > guarantee that these images will boot, muchless perform as > expected. They are strictly “use at your own risk.” > > Daily Releases: > http://download.tizen.org/releases/daily/tizen/ivi/ivi/ > > These are the culmination of the days’ changes. Release > Engineering “smoke tests” these to ensure that they meet some > basic requirements before publishing. i.e. The daily should > boot, come up to the expected UI or console, depending on the > image requirements, be able to run webapps, and not do > anything too weird that isn’t already a known issue. We > consider these images to be worthy of a full QA testing run. > While these images are considered to be more stable than > snapshots at at least the level of having passed our smoke > testing. That does not mean that there are not regressions or > new bugs lurking there. QA does their testing and opens bugs > accordingly against anything they find. Additionally, overall > stability and usability may be affected by integration of new > components, features, or major changes to things like > security, smack, rpm, webkit, weston, wayland, etc. We expect > the initial integration of these things to be a little bumpy > as we get things working. So you will definitely see flux in > quality and stability here, especially early on in the > development cycle. Typically this irons out to some degree as > we get closer to a major release and we go more into bug-fix > mode and do less integration work. >
