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
