Absolutely correct, Paul. :) From: <Hanchett>, Paul <phanc...@jaguarlandrover.com<mailto:phanc...@jaguarlandrover.com>> Date: Tuesday, January 28, 2014 at 8:22 PM To: Tracy Graydon <tracy.gray...@intel.com<mailto:tracy.gray...@intel.com>> Cc: Mark De Roussier <mark.derouss...@symphonyteleca.com<mailto:mark.derouss...@symphonyteleca.com>>, "ivi@lists.tizen.org<mailto:ivi@lists.tizen.org>" <ivi@lists.tizen.org<mailto:ivi@lists.tizen.org>> Subject: Re: Frequency of build breaks ?
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: phanc...@jaguarlandrover.com<mailto: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 <tracy.gray...@intel.com<mailto:tracy.gray...@intel.com>> 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 ivi@lists.tizen.org<mailto:ivi@lists.tizen.org> 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 <mark.derouss...@symphonyteleca.com<mailto:mark.derouss...@symphonyteleca.com><mailto:mark.derouss...@symphonyteleca.com<mailto:mark.derouss...@symphonyteleca.com>>> Date: Wednesday, January 15, 2014 at 6:10 AM To: "ivi@lists.tizen.org<mailto:ivi@lists.tizen.org><mailto:ivi@lists.tizen.org<mailto:ivi@lists.tizen.org>>" <ivi@lists.tizen.org<mailto:ivi@lists.tizen.org><mailto:ivi@lists.tizen.org<mailto:ivi@lists.tizen.org>>> 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 mark.derouss...@symphonyteleca.com<mailto:mark.derouss...@symphonyteleca.com><mailto:mark.derouss...@symphonyteleca.com<mailto:mark.derouss...@symphonyteleca.com>> www.symphonyteleca.com<http://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><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 IVI@lists.tizen.org<mailto:IVI@lists.tizen.org><mailto:IVI@lists.tizen.org<mailto:IVI@lists.tizen.org>> https://lists.tizen.org/listinfo/ivi _______________________________________________ IVI mailing list IVI@lists.tizen.org<mailto:IVI@lists.tizen.org> https://lists.tizen.org/listinfo/ivi _______________________________________________ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
