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: [email protected] ------------------- 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 < [email protected]> 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: [email protected] > > ------------------- > > > > 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 > > <[email protected]> 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. > > > > These images are great for looking at new features being > > integrated, major changes to existing things, etc. Depending > > on your needs, these may or may not be suitable for your > > development work. Their can, and will be, things wrong in > > these images, and the degree of borkage will vary. > > > > Milestone Releases: > > http://download.tizen.org/releases/milestone/tizen/ivi/ > > > > These images are the most stable and reliable of the lot. > > While that is true, the level of polish of these images may > > also vary depending on how significant the integration work > > was for a given development cycle. The more intrusive or > > significant the changes, the more likely you are to see some > > oddball issues. i.e. If we integrate a whole new UI between > > milestones, the latest may not have the same degree of polish > > on it overall since it is just newly integrated. That said, we > > expect these images to be relatively stable and to be suitable > > to develop against. > > > > As such, Milestone images are the ones we advise people to use > > for development. You can always add the repos for daily or, if > > you like to live on the edge, the snapshot repos, to zypper > > install updates to things you are interested in looking at. Of > > course, as things move toward the next milestone release, > > depending on what you are interested in, changes can be > > significant enough to make it infeasible to zypper in the > > changes you want. In that case, I would recommend falling back > > to a daily release and working against that. > > > > Obviously there is no hard and fast answer. Much depends on > > what you need to do at a given time. In general, I would > > recommend starting with the most recent Milestone release and > > then falling back to a daily release if you can't get what you > > need with the Milestone due to significant changes. The test > > reports that are published to [email protected] might also > > give you some ideas of what daily releases might be worth your > > time to look at, too. > > > > I hope that answers your question with enough useful info to > > go on. :) Please give a yell if I can clarify anything or you > > have more questions. > > > > Tracy > > Release Engineering > > > > From: Mark De Roussier > > <[email protected]<mailto: > [email protected]>> > > Date: Wednesday, January 15, 2014 at 6:10 AM > > To: "[email protected]<mailto:[email protected]>" > > <[email protected]<mailto:[email protected]>> > > Subject: Frequency of build breaks ? > > > > > > Hi folk, > > > > first of all, I'd like to make clear that I'm not seeking to > > pass judgment on anyone or any thing here, just trying to > > understand the situation so that I can choose the most > > appropriate development strategy for myself. > > > > I'm doing proof of concept work, and I don't know exactly > > whereabouts in the source this will take me. So I want to have > > a local build of everything, so that I can poke around > > wherever I need to, and am able to create my own images. > > > > I could choose to base my work on a Release. There are pros > > and cons to this. My current preference is a continuous > > integration strategy, whereby I sync regularly with latest. > > This way I avoid a 'big bang' merge/integration further down > > the line, if it turns out I need or want some new > > functionality that's on the way. > > > > But this does not work so well if the latest is often broken. > > I understand that it's 'bleeding edge' and that functionality, > > particularly at the system level, may or may not function > > properly - I'm just referring to being able to build things > > here. > > > > I've experienced three build breaks now in the i586 build in > > the last 4 working days. One has been resolved, two appear to > > still be there. So my question is, is this normal ? Or are > > things particularly fragile right now ? Or am I doing > > something wrong ( not sure what - I've not changed any code > > yet... ) ? If this is just normal, I'll switch to the latest > > release as a base, and go from there. > > > > Thanks, > > Mark > > > > > > MARK DE ROUSSIER > > Team Lead > > > > Symphony Teleca > > Sunley House, 46 Jewry Street, Winchester, Hampshire, SO23 8RY > > Phone: +441962891219, Fax: +441962868867 > > > > [email protected]<mailto: > [email protected]> > > www.symphonyteleca.com<http://www.symphonyteleca.com> > > > > Teleca Limited, a company registered in England & Wales, > > registration number 2773878, registered office at Sunley > > House, 46 Jewry Street, Winchester, Hampshire SO23 8RY. VAT > > registration number GB 674 6583 90 > > > > > > Follow what's going on at Symphony Teleca's blog on > > www.symphonyteleca.com/blog<http://www.symphonyteleca.com/blog>. > Please consider the environment before you print. > > > > Notice to recipient: This e-mail (including any attachments) > > is meant for the intended recipient only, may contain > > confidential and proprietary information, and is protected by > > law. If you received this e-mail in error, please immediately > > notify the sender of the error by return e-mail, delete this > > communication and any attachments, and shred any printouts. > > Unauthorized review, use, dissemination, distribution, copying > > or taking of any action based on this communication is > > strictly prohibited. > > > > > > > > _______________________________________________ IVI mailing > > list [email protected]<mailto:[email protected]> > > https://lists.tizen.org/listinfo/ivi > > _______________________________________________ > > IVI mailing list > > [email protected] > > https://lists.tizen.org/listinfo/ivi > > > > > > > > _______________________________________________ > > IVI mailing list > > [email protected] > > https://lists.tizen.org/listinfo/ivi > > Intel Corporation NV/SA > Kings Square, Veldkant 31 > 2550 Kontich > RPM (Bruxelles) 0415.497.718. > Citibank, Brussels, account 570/1031255/09 > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. >
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
