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.
(At least, I *think* it's true that syncing repositories gets the latest that's been checked in, not the latest approved in gerrit...) 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
