| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html | ||
| asac | ho | 13:30 |
|---|---|---|
| ogra_ | hohoho | 13:30 |
| asac | :) | 13:30 |
| asac | ogasawara: you run this track, right? | 13:30 |
| ogasawara | asac: yep | 13:31 |
| asac | ogasawara: when will we boot the room? | 13:31 |
| ogasawara | asac: I usually start it up about 15min before | 13:31 |
| asac | in 20 minutes early enough? | 13:31 |
| asac | cool | 13:31 |
| ogasawara | asac: then I ping the url here | 13:31 |
| asac | good | 13:32 |
| ogasawara | asac, didrocks: https://plus.google.com/hangouts/_/hoaevent/AP36tYejx4a57LGNk7fbW9HeUUpDvo-i-SHKLuRhKzSha-qxFpMxUA?authuser=0&hl=en | 13:46 |
| didrocks | thanks ogasawara | 13:46 |
| asac | ok lets see if this thing works here | 13:47 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Landing process rules for ubuntu Touch | Url: http://summit.ubuntu.com/uds-1403/meeting/22174/core-1403-landing-process-touch/ | ||
| asac | bfiller: https://plus.google.com/hangouts/_/hoaevent/AP36tYejx4a57LGNk7fbW9HeUUpDvo-i-SHKLuRhKzSha-qxFpMxUA?authuser=0&hl=en | 13:51 |
| olli_ | hi folks | 13:53 |
| asac | hi olli_ | 13:57 |
| karni | Someone could drop the presentation URL into the session pad, once it's over. | 14:05 |
| asac | karni: will get it posted afterwards | 14:07 |
| karni | elopio: you might want to mute yourself | 14:07 |
| karni | asac: thanks! | 14:07 |
| elopio | sorry. I'm muted now | 14:07 |
| asac | dont want to interrupt didier | 14:07 |
| dobey | anyone who is not talking should mute themselves | 14:07 |
| dobey | in every session :) | 14:07 |
| karni | elopio: np | 14:07 |
| ogra_ | hmm, cant get video here | 14:08 |
| tedg | ogra_, didier is signing Hollywood music, so it's restricted. | 14:09 |
| ogra_ | heh, well, it doesnt load on yourtube (nor in the embedded thing) | 14:09 |
| sergiusens | ogra_, I restarted firefox for it to work... | 14:09 |
| * ogra_ only gets a spinner . | 14:09 | |
| ogra_ | sergiusens, igh ... certainly wont do that | 14:10 |
| ogra_ | (too many open things here, cant restart it) | 14:10 |
| rickspencer3 | didrocks, for the "fix ready" line ... | 14:10 |
| ogra_ | (other videos work fine ) | 14:10 |
| sergiusens | ogra_, pkill firefox and restart | 14:10 |
| rickspencer3 | does that include reversions? | 14:10 |
| sergiusens | ogra_, will restore all your tabs :-) | 14:10 |
| ogra_ | sergiusens, i will lose several oppen endit forms | 14:10 |
| ogra_ | *edit | 14:11 |
| sergiusens | ogra_, you are so complicated :-P | 14:11 |
| ogra_ | and i can play any other video on youtube, just this one doesnt load at all | 14:11 |
| rickspencer3 | ogra_, maybe try joining the hangout? | 14:11 |
| xnox | .. | 14:12 |
| ogra_ | rickspencer3, cant from this device ... | 14:12 |
| xnox | autopilot did for sure catch failures. | 14:12 |
| ogra_ | heh | 14:12 |
| dobey | ogra_: try shift-reload to reload without cache? | 14:12 |
| ogra_ | it also produced a lot | 14:12 |
| ogra_ | dobey, all tried | 14:12 |
| dobey | ogra_: i've found i have to do that for all the uds videos when the session actually starts | 14:12 |
| sergiusens | QUESTION: with most apps moving to autopilot and most test being against apps; is there a plan for the ci train to accommodate that? | 14:13 |
| sergiusens | or is the focus going to move to running autopilot on system components (osk, unity8, uitoolkit) | 14:13 |
| sergiusens | yes we can | 14:14 |
| didrocks | asac: rick is talking! | 14:14 |
| sergiusens | lol | 14:14 |
| dobey | i can hear rick! | 14:15 |
| geddy | we can hear him | 14:15 |
| balloons | lol | 14:15 |
| sergiusens | we can hear rickspencer3 | 14:15 |
| sergiusens | asac, restart your hangout | 14:15 |
| lool | asac: you need to stop talking | 14:15 |
| bregma | laaaaag! | 14:15 |
| lool | asac: you're watching the youtube stream or something | 14:15 |
| asac | sergiusens: well, leann also cant | 14:15 |
| sergiusens | yeah; the delay doesn't help :-) | 14:15 |
| rickspencer3 | know we know why asac and ogasawara are so productive | 14:15 |
| ogasawara | heh | 14:15 |
| asac | :P | 14:16 |
| lool | are they leaving 2 minutes in the future? | 14:16 |
| lool | *living | 14:16 |
| asac | oh i remember i installed the hangout block feature | 14:16 |
| asac | for rick | 14:16 |
| kenvandine | haha :) | 14:16 |
| xnox | rickspencer3: clearly some people clicked "ignore this person" button =)))))))))) </kidding> | 14:16 |
| rickspencer3 | whatever works! | 14:16 |
| tedg | It seems like a lot of the delay is in rebuilding images. But it seems like building multiple images is just a matter of CPU time. | 14:16 |
| tedg | Can we build images for "instant revert" proactively? | 14:17 |
| xnox | tedg: that's getting fixed, by moving cd building into launchpad and have a full pull of all builders which will be able to build image per each silo. | 14:17 |
| asac | tedg: image building is only 1/4th of the time | 14:17 |
| xnox | s/pull/pool/ | 14:17 |
| asac | the testing is what takes a long time (4-6h) | 14:17 |
| ogra_ | image builds take ~1h | 14:17 |
| asac | we a) work on allowing parallel testing which will allows us to pipeline | 14:17 |
| tedg | That actual building. But let's say we built all the image combinations. So we were just choosing which one. | 14:17 |
| tedg | i.e. there's already an image without a certain silo landed. | 14:18 |
| asac | b) later do swarm testing so it will take just 1h or even less | 14:18 |
| asac | swarm waits for emulator | 14:18 |
| olli_ | kgunn, wasn't the number of silos somethnig you mentioned in an earlier conversation | 14:18 |
| dobey | x86 emulator will make testing a lot faster | 14:18 |
| asac | tedg: we have a bottleneck in our official image build infra | 14:18 |
| tedg | asac, By swarm you mean AP with gemgem? | 14:18 |
| asac | ogra_ knows what that bottleneck is | 14:18 |
| ogra_ | do we ? | 14:18 |
| asac | tedg: well, taking 10 phones and running one AP on each instead of sequence | 14:18 |
| asac | as an example | 14:18 |
| kgunn | olli_: yes, more specifically - dedicated silo, available all the time to a team/proj | 14:18 |
| asac | ogra_: we cant produce multiple images in parallel, right? | 14:19 |
| asac | people told me we wait for buildd cloud | 14:19 |
| ogra_ | asac, ah, right, they get queued ... | 14:19 |
| asac | ogra_: what part of infra cant do parallel? | 14:19 |
| kgunn | olli_: but this is what didrocks calls "airline" vs train ....so some x amount of infrastructure or change to it needed to accomplish that | 14:19 |
| ogra_ | but that part of the build only takes 20-25min | 14:19 |
| tedg | Can we "swarm test" manual testing by using the QA test tracker? | 14:19 |
| ogra_ | so we could raise the frequency a bit | 14:19 |
| tedg | Basically make one entry per-image like we do with daily CDs? | 14:19 |
| asac | tedg: we could look at swarming manual testing, but problem is that with manual testing the testers need to be calibrated | 14:20 |
| asac | so you cannot just test once in a month one test case | 14:20 |
| asac | usually you will report confusing things etc. | 14:20 |
| asac | our problem is really getting the AP results asap | 14:20 |
| tedg | Sure, but couldn't the calibrated testers just test the cases that are raised by the swarm? | 14:21 |
| rickspencer3 | I wonder if there is a way to make reversion faster and more reliable, but without slamming upstream trunk | 14:21 |
| asac | rickspencer3: we revert without slamming upstream trunk | 14:21 |
| rickspencer3 | like could we keep copies of the last binaries around and put those into the image or something | 14:21 |
| asac | rickspencer3: reverts are done in archive | 14:21 |
| rickspencer3 | ? | 14:21 |
| rickspencer3 | right, I think that's a good thing that we want to keep | 14:21 |
| rickspencer3 | but maybe we could make rollbacks easier and keep that goodness | 14:22 |
| tedg | I guess for me I'd say we want rollbacks quicker so that they can be decisive and make it so that other things can land. | 14:22 |
| rickspencer3 | in other words, can we make it so that there is nothing that is "hard to rollback" | 14:22 |
| xnox | rickspencer3: old binaries are available from librarian, but there is no guarantee they are installable when everything else moved on. Using old version binaries works for e.g. image-based upgrades. But doesn't help other silos/packages (they still see higher/broken version) or apt-get based machines. | 14:22 |
| rickspencer3 | xnox, but could we not calculate all the binaries that changes in the rollback? | 14:23 |
| asac | i think we could do it by grapping old binaries, but it becomes pretty tricky for everything not a leave package | 14:23 |
| asac | grepping | 14:23 |
| * ogra_ thinks we just need to become better with testing so we dont have to roll back *after* something entered | 14:23 | |
| asac | err :) you know what i mean | 14:23 |
| xnox | rickspencer3: from legal point of view, we build from the archive, as we publish matching source-code for those versions. | 14:23 |
| xnox | rickspencer3: calculation could be done, but it would need verification that it indeed doesn't regress. | 14:24 |
| rickspencer3 | that doesn't seem like a blocker, I mean, the source code is available in the commit history | 14:24 |
| rickspencer3 | so it should be easy to get the source that is published | 14:24 |
| xnox | rickspencer3: what i have seen with reverts, is that revert happened without consulting the uploader (myself), which is a no-win revert as it re-introduces fixed things. | 14:24 |
| rickspencer3 | to be clear, my implementation is maybe not good, but I think it's worth thinking about how to do rollbacks smarter | 14:24 |
| pmcgowan | Question: are all regressions treated equally or is there some analysis of minor regression vs major feature landed and needs to be released | 14:24 |
| tedg | rickspencer3, +1 | 14:25 |
| cjwatson | I think we *are* doing rollbacks quite smartly, and people are asking for them to be done more quickly but less smartly ... | 14:25 |
| cjwatson | that's the strong impression I get | 14:25 |
| rickspencer3 | cjwatson, interesting point | 14:25 |
| tedg | For me I'd like rollback, etc, to be more automatic. Not a "someone decides how important" it's just a part of the machine. | 14:26 |
| xnox | rickspencer3: the way we do reverts, of a single package, not a full revert to previous image number, it still needs to go though full testing. As it's a new state. It has been identified to resolve /a regression/, but it's rarely verified fully to not introduce any /new regression/ as those reverts don't go through full test-plan. | 14:26 |
| cjwatson | the pushback always seems to be in cases when we're in the middle of doing proper root-cause analysis | 14:26 |
| rickspencer3 | more quickly but also still smart sounds good | 14:26 |
| tedg | So then things move on quickly. | 14:26 |
| rickspencer3 | cjwatson, I'm curious why that impacts the developers, I would think didr0cks could do a rollback to keep the image green while the developers keep going with their root cause anlaysis | 14:26 |
| rickspencer3 | what am I missing? | 14:26 |
| xnox | didrocks: QUESTION: why reverts don't go through silo and a full test-plan execution? | 14:27 |
| cjwatson | rickspencer3: I've suggested before that this could trivially be done by having a separate PPA that we copy old versions into | 14:27 |
| rickspencer3 | interesting | 14:27 |
| cjwatson | and having that pinned through the roof in the image build process | 14:27 |
| rickspencer3 | in the meantime, profile before you optimise | 14:27 |
| cjwatson | so far my suggestion has been largely ignored though *shrug* | 14:27 |
| * ogra_ sighs ... no dice for me with the video, even on another machine with different DSL connection :/ | 14:27 | |
| rickspencer3 | the 5 hour automated test lag is clearly where we should focus | 14:27 |
| pmcgowan | cjwatson, then the image does not match trunk or archive, is that a concern? | 14:27 |
| cjwatson | pmcgowan: I think that's fine as long as we keep the list of active rollbacks small | 14:28 |
| cjwatson | which should be good engineering practice anyway | 14:28 |
| olli_ | QUESTIONS: one thing that Google CI supposedly does well is to relate code changes to relevant test cases automatically and then run only that subset (automated). Have we any plans on targeting testcases more precisely? | 14:28 |
| xnox | rickspencer3: re:automated lag - it takes less than 5 hours on armhf emulator, yet adding emulator to ci has been stalled it seems. | 14:28 |
| rickspencer3 | xnox, I thought you were going to add x86 emulator so that we could quickly scale out automated testing | 14:29 |
| tedg | didrocks, asac, can we come up with a metric for "risky" so that people can understand it? | 14:30 |
| xnox | rickspencer3: armhf emulator is available and it scales well on top of openstack. x86 emulator is in progress in bring up. | 14:30 |
| tedg | i.e. not assigned by people, but by an algorithm | 14:30 |
| xnox | rickspencer3: i made intial proposal to add amr emulato to jenkins / ci, and someone from #ci was working on it, but no updates for a few weeks now. | 14:30 |
| xnox | s/amr emulato/arm emulator/ | 14:31 |
| sergiusens | rickspencer3, when you want to talk mute asac and unmute when done; should provide better sync and collision avoidance :-) | 14:31 |
| ogra_ | :) | 14:31 |
| xnox | didrocks: QUESTION: there was full-train stop, which did delay python2-removal for example. | 14:31 |
| rickspencer3 | just like irl | 14:31 |
| ogra_ | duct tape ? | 14:31 |
| asac | ah rick is talking | 14:32 |
| asac | hehe | 14:32 |
| didrocks | asac: yeah :) | 14:32 |
| didrocks | asac: will tell you here | 14:32 |
| didrocks | (I hope someone can relay the question in the hangout, I've my slides focused) | 14:33 |
| asac | for me the definition of risky landing could be: if your testplan is affected by current regressions, you are at risk of landing more regressions | 14:33 |
| asac | that you dont see | 14:33 |
| tedg | I don't think it does. I think we need a way to ensure that "risky" is transparent. If you can't measure it, it really can't be part of the determination. | 14:33 |
| asac | so its not so much where in the stack you are, but its kind of correlated | 14:33 |
| rickspencer3 | </soapbox> | 14:33 |
| asac | tedg: is that a comment on my proposal of risk above? | 14:34 |
| cjwatson | measure> yeah, absolutely; I get the sense that the "risky" category is kind of prejudice / based on something that happened months ago | 14:34 |
| asac | feel thats pretty measurable. you have a risky landing if your component testplan is currently not 100% green | 14:34 |
| cjwatson | sometimes, anyway | 14:34 |
| tedg | rickspencer3, Isn't that really for images that get released to users. For instance, we're not going to do a daily release to all users. I think we need a different level for daily and to-user releases. | 14:34 |
| ogra_ | often enough, yeah | 14:34 |
| asac | i think with this it will usually correlate on where you are on the stack | 14:34 |
| asac | but it wouldnt be just "you are low, so you are risky" | 14:34 |
| tedg | asac, I'm not sure what you mean by "component testplan" | 14:35 |
| ogra_ | tedg, the testplan for the component you maintain | 14:35 |
| asac | tedg: every component like mir has a testplan. thats manual checks + a set of autopilots that folks run in the silo | 14:35 |
| tedg | Yes, but how is that "green or not" ? | 14:35 |
| ogra_ | tedg, either your change passes or not | 14:35 |
| balloons | I think even in normal states, it's difficult because nothing can merge to trunk | 14:35 |
| tedg | We have no place that it's getting recorded. It's "green" in someone's head. | 14:35 |
| asac | tedg: if you can run all the manual checks and autopilots tha tyou need for your landing in the current image and it is 100% succeess | 14:35 |
| asac | its green | 14:35 |
| balloons | trunk should not be the same as the archive | 14:36 |
| asac | tedg: no its recorded | 14:36 |
| asac | the manual part not. but the APs | 14:36 |
| ogra_ | well, the manual part is kind of as well | 14:36 |
| asac | right. | 14:36 |
| ogra_ | by you setting the silo stuff | 14:36 |
| tedg | asac, So if all the APs for a component is green, you consider it non-risky? | 14:36 |
| asac | but we haven't figured how to ensure people that have testplans know whether their manual testplan is currently affected | 14:36 |
| ogra_ | if you say "tests passed" we have to assume your manual tests worked | 14:36 |
| asac | tedg: all APs that you need to run for a component landing ... which is more than just the AP for that component | 14:37 |
| balloons | under a normal process, you would have a release branch, a development branch, and feature branches. Features land into development, and occasionally you would push those then to a release branch | 14:37 |
| asac | tedg: e.g. if you land mir we also run a bunch of app APs, unity8 AP etc. | 14:37 |
| asac | tedg: so the APs in the component testplan being green == non-risky in the sense of phonecon1 | 14:37 |
| tedg | asac, How is that list generate? | 14:37 |
| tedg | generated? | 14:37 |
| ogra_ | tedg, you as the developer define it | 14:37 |
| asac | tedg: we start with a good initial guess out of experience ... | 14:37 |
| asac | tedg: and if we identify that something slipped through, we grow that list | 14:38 |
| asac | tedg: we try to not start with the complete list of reverse dependencies to stay efficient | 14:38 |
| olli_ | kgunn, isn't that how Mir is working atm? | 14:38 |
| ogra_ | you have to provide an initial testplan when getting the silo | 14:38 |
| tedg | asac, Where is it recorded? | 14:38 |
| asac | tedg: supposed to be recorded in the testplan | 14:38 |
| ogra_ | tedg, on the landing sheets | 14:38 |
| xnox | .. | 14:38 |
| cjwatson | tedg: https://wiki.ubuntu.com/Process/Merges/TestPlan/<foo> | 14:38 |
| * asac is brave and reconnects | 14:39 | |
| sergiusens | a year and a bit ago we had the concept of a release commit which only then would push to our archive (which was a PPA at that time) | 14:39 |
| xnox | e.g. with ubuntu-ui-toolkit we tried to land 17 branches in one go, which ofcourse, failed to merge and 4 branches did conflict between themself. | 14:39 |
| ogra_ | tedg, when you request a silo, you have to link your testplan ... when you did the testing, you have to note in the silo spreadsheet that it passed (or not) | 14:39 |
| sergiusens | so people could merge to trunk and _release_ when it's ready | 14:39 |
| asac | \o/ i can hear rick :) | 14:39 |
| xnox | and therefore was pain to land, as there was no sensible conflict resolution. 4 branches got kicked out, and eseentially landed one by one, weeks later. | 14:39 |
| cjwatson | rickspencer3: anything that provides an API to anything else has a clear incentive to get things into the archive so that they can land changes that depend on new APIs, IME | 14:40 |
| tedg | So, I'm confused. So for every image, QA takes the list of every silo landing and generates a list of APs to run. | 14:40 |
| ogra_ | tedg, no | 14:40 |
| tedg | Where is the list of AP tests that'll be run on that image? | 14:40 |
| cjwatson | rickspencer3: (e.g. I had a strong incentive to get libclick landed so that I could start landing the things that depend on that) | 14:40 |
| ogra_ | tedg, for your very own changes you use the silo ... | 14:40 |
| ogra_ | tedg, you do your testing, if your testing passes you can land it in the archive | 14:40 |
| sergiusens | cjwatson, yeah, that's when stopping the line is the most burden | 14:41 |
| xnox | .. | 14:41 |
| ogra_ | tedg, images are built out of sync here | 14:41 |
| cjwatson | right, it's terrible for anything with multi-level stacking | 14:41 |
| tedg | Or 100's of MR's queued... | 14:41 |
| ogra_ | tedg, and the images run *all* AP tests automatically before we consider them releasable | 14:41 |
| kgunn | olli_: yes - mir works this way today on lp:mir/devel | 14:42 |
| kgunn | and lp:mir | 14:42 |
| ogra_ | tedg, so if at that point a regression is found in the component you landed, we roll it back (or as you to) | 14:42 |
| ogra_ | *ask | 14:42 |
| tedg | I'm confused. So project X is risky if any run of that it declares in its test plan has failed. | 14:42 |
| dobey | all projects are risky | 14:42 |
| ogra_ | right | 14:42 |
| tedg | So how do I determine if my project is risky? | 14:43 |
| ogra_ | the issue when your testplan passes but the image one doesnt is most likely that your testplan misses something | 14:43 |
| dobey | tedg: if it has code, it's risky :) | 14:43 |
| cjwatson | tedg: I think there's some talking past each other here; some people seem to be talking about risky projects, others about risky landings | 14:43 |
| olli_ | tedg's project are always risky | 14:43 |
| rickspencer3 | tedg, I think that the landing team tells you if it's risky | 14:43 |
| cjwatson | those are obviously quite different things | 14:43 |
| rickspencer3 | and what olli says ;) | 14:43 |
| * ogra_ would like to get away from that "risky/non risky" stuff | 14:43 | |
| cjwatson | rickspencer3: but that should be based on science | 14:43 |
| cjwatson | and vaguely predictable | 14:43 |
| ogra_ | the issue we have is that the first level testing isnt good enough very often | 14:43 |
| rickspencer3 | cjwatson, indeed, I was subtly pointing out a potential problem | 14:44 |
| dobey | to mee, it just seems like CI needs to be more async | 14:44 |
| ogra_ | if that is 100% reliable, you wont have to roll back ever | 14:44 |
| tedg | I think it should be predictable, but I'd settle for transparent at this point :-) | 14:44 |
| cjwatson | rickspencer3: *nod* | 14:44 |
| rickspencer3 | I do wonder if there is some kind of rdepends that we can run that predicts such things | 14:44 |
| rickspencer3 | like, a certain weight of things that depend on you equals risk level or something | 14:44 |
| ogra_ | not really, since we are working image based | 14:44 |
| dobey | more async and more automation | 14:45 |
| ogra_ | one of the probs is that you test on the last image that was built... the stuff that you land lands in the next image that gets built ... | 14:45 |
| ogra_ | which means you have other changes that go in alongside .... | 14:46 |
| ogra_ | which can change the whole situation amnd stability | 14:46 |
| tedg | Sure, but that doesn't effect how risky the project itself is. | 14:46 |
| xnox | .. | 14:46 |
| xnox | ideally we'd have integration branch for landing, ahead of the landing. | 14:46 |
| dobey | tedg: ideally, every package/project would be treated as equally risky | 14:47 |
| ogra_ | tedg, no, but you have to asses the risk always in combination with all the other changes | 14:47 |
| sergiusens | I agree with Saviq and want to add that merging a component of yours that depends on changes on many other projects (like mir or unity8) you sort of block everyone | 14:47 |
| sergiusens | it's silo-cked | 14:47 |
| ogra_ | heh | 14:47 |
| dobey | and you eliminate the thinking about whether something is risky or not, because everything is | 14:47 |
| kgunn | lol | 14:47 |
| cjwatson | the problem with this is that it puts massive friction on improving our core | 14:47 |
| kgunn | "silo-cked" word of the day | 14:47 |
| cjwatson | now, it also puts massive friction on breaking our core | 14:47 |
| rsalveti | sergiusens: it'd still be an issue if we had devel/release branches | 14:47 |
| cjwatson | so I get the trade-off, but still | 14:47 |
| rsalveti | would not block trunk, but the issue would still be around | 14:48 |
| sergiusens | rsalveti, oh, I'm not stating solutions today; just wanted ane xcuse to say silo-cked :-) | 14:48 |
| cjwatson | cf. the gigantic project of Qt 5.2 | 14:48 |
| dobey | sergiusens: and then the silo-ns will nuke us all | 14:48 |
| ogra_ | ++ | 14:48 |
| rickspencer3 | maybe risky = time since landing + weight of rdepends + history of regressions caused | 14:49 |
| sergiusens | it was rsalveti :-P | 14:50 |
| rickspencer3 | ? | 14:50 |
| rickspencer3 | oops | 14:50 |
| rickspencer3 | sorry sergiusens and rsalveti :) | 14:50 |
| sergiusens | np | 14:50 |
| asac | yeah, but rsalveti said "i dont want my team to do that" :) | 14:50 |
| rsalveti | another guy from south america :P | 14:50 |
| sergiusens | we ar the same team and have the same opinion | 14:50 |
| cjwatson | rickspencer3: also I think some judgement of the actual changes should be involved | 14:50 |
| rickspencer3 | size of patch? | 14:50 |
| sergiusens | it's been this way for us since we started this project | 14:50 |
| cjwatson | the stuff that's already in the image, well, we've accepted the risk | 14:50 |
| kgunn | 2 other "small" things i would ask for today - self service reconfigure & not locking silo's on project use (only lock landing) | 14:50 |
| rickspencer3 | maybe risky = time since landing + weight of rdepends + history of regressions caused + size of patch? | 14:50 |
| kgunn | asac: ^^ | 14:51 |
| sergiusens | but there are some corners where we might consider flag days perhaps | 14:51 |
| rsalveti | asac: because we want to share the responsibility, and we can't afford having someone coordinate trunk/release merges | 14:51 |
| sergiusens | as much as the android bump was tested; it wasn't enough; and qt 5.2 will have a similar problem most likely | 14:51 |
| rickspencer3 | sergiusens, yup, exactly | 14:51 |
| rickspencer3 | and that's not necessarily representing failure conditions | 14:52 |
| cjwatson | sergiusens: risk-aversion is a continuum - it doesn't IMO make sense to crank the dial all the way to one side | 14:52 |
| rickspencer3 | some things are just tough | 14:52 |
| ogra_ | sergiusens, thats what i'm saying all the time above ... we need to get our pre-testing better | 14:52 |
| cjwatson | the problem is that any time something goes wrong people ask "how could we have avoided this" | 14:52 |
| cjwatson | which is healthy in one sense | 14:52 |
| rickspencer3 | cjwatson, well, we have the promotion as the ultimate safe gaurd | 14:52 |
| cjwatson | but it means it's very hard to say "sometimes, it just wouldn't have been worth the degree of friction required to catch this" | 14:52 |
| slangasek | managers enforcing releases once a week> that means the managers have to have eyes on all the individual components that their team has touched, right? | 14:52 |
| rickspencer3 | so, it seems to me that the "risk" really comes down to a lag between promoted images | 14:52 |
| ogra_ | rickspencer3, but we most of the time only discover the issues at that point | 14:52 |
| ogra_ | which is what causes us to roll back | 14:52 |
| tedg | We could have sync points where everyone makes sure to have a release. | 14:53 |
| dobey | i would land MPs in trunk as fast as possible, and automate daily releases and testing | 14:53 |
| slangasek | also, what if one team is ready to do their weekly release, and it needs a change to a package from another team, and the other team has staged changes that are not yet releasable? | 14:53 |
| ogra_ | we need to get better (a lot) on the first test run and with the first test plan in the line | 14:53 |
| xnox | rickspencer3: i'm ok for integration branches, but it shouldn't be an open-ended branches, but e.g. "next-landing" branch which would be limited to what is desired to land, not something open ended. Once it's full, it must land before merging more stuff into it. | 14:53 |
| rickspencer3 | ogra_, right, I guess I'm saying that just because we do a landing and we find issues, it's not a freak out situation | 14:53 |
| cjwatson | tedg: we could have them every six months :) | 14:53 |
| rickspencer3 | ogra_, I think we all agree with that | 14:53 |
| tedg | cjwatson, I was going to propose some interim ones, we could call them alpha/beta ;-) | 14:53 |
| rsalveti | once we get the x86 emulator we'll at least the get the test results sooner | 14:53 |
| cjwatson | tedg: heresy | 14:53 |
| rickspencer3 | as I say, it seems that we are good at keeping the impact to us as developers | 14:53 |
| rickspencer3 | and that promotion protects users | 14:53 |
| rsalveti | and another issue is that we can't yet give a custom image to be tested like the ones we have in the dashboard | 14:53 |
| ogra_ | rsalveti, but the x86 emulator will test x86 binaries | 14:53 |
| rsalveti | most of the issues are arch-indep | 14:54 |
| ogra_ | we will only see over time how reliable that even is | 14:54 |
| cjwatson | ogra_: it's still catch a lot of things | 14:54 |
| cjwatson | *it'll | 14:54 |
| ogra_ | sure | 14:54 |
| cjwatson | the click problems over the last couple of days would absolutely have been caught by that | 14:54 |
| cjwatson | for instance | 14:54 |
| ogra_ | yep | 14:54 |
| mardy | bfiller: +1 | 14:54 |
| rsalveti | like, if I want to land hybris or android, I'd like to be able to create a custom image and give it to be automatically tested | 14:54 |
| ogra_ | but i assume there will still be many false positives | 14:54 |
| cjwatson | it'll get better over time | 14:55 |
| ogasawara | didrocks, asac: gotta start wrapping up... | 14:55 |
| ogasawara | didrocks, asac: as I'll need to shut down this hangout in a few mins | 14:55 |
| ogra_ | rsalveti, use rootstock until cjwatson's PPA builds start working then | 14:55 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Networking Health-Check | Url: http://summit.ubuntu.com/uds-1403/meeting/22215/core-1403-networking-healthcheck/ | ||
| tedg | I think it's important that we keep branches to releases for maintenance. | 14:55 |
| didrocks | ogasawara: ok, got it, just have 30s to say | 14:55 |
| ogasawara | cyphermox: will get your hangout up as soon as this one is done | 14:55 |
| ogasawara | didrocks: ack | 14:55 |
| rsalveti | ogra_: my issue is not creating the image, but using that to be automatically tested :-) | 14:55 |
| cyphermox | ogasawara: ah, ok | 14:55 |
| tedg | We are supporting those releases and need to base off of those. | 14:56 |
| * stgraber waves | 14:56 | |
| tedg | But we use symbolic naming in LP for that. | 14:56 |
| rsalveti | so later on we can have landing silo ppa -> image -> dashboard (tested with the x86 emulator) | 14:56 |
| ogra_ | rsalveti, well, doanac is working on a "home use utah" for that | 14:56 |
| tedg | lp:foo goes to lp:~team/foo/trunk.14.04 | 14:56 |
| rsalveti | ogra_: right, but that's a feature I asked before we started trusty :-) | 14:56 |
| ogra_ | heh | 14:56 |
| dobey | tedg: that's a bit annoying though | 14:56 |
| sergiusens | ogra_, I think that utah is mostly done; at least my tools plan is to ask him to test against that :-P | 14:57 |
| cjwatson | you can often create the maintenance branches for older series lazily | 14:57 |
| cjwatson | lots of projects never need them | 14:57 |
| ogra_ | sergiusens, well, you dont really want to run systemsettle so testing locally will only take 1h instead of 3-4 | 14:57 |
| tedg | Sure, I find that's easy for us, but people who are more drive-by have a more difficult time finding those points. | 14:57 |
| dobey | merging to trunk and releasing to archive/image being separate, but closely knit, seems like the best solution to me | 14:58 |
| xnox | rickspencer3++ | 14:58 |
| pmcgowan | rickspencer3, +1 | 14:58 |
| sergiusens | ogra_, oh, these take 4h so I might be in full blown mode ;-) | 14:58 |
| ogra_ | sergiusens, yeah, its awful | 14:58 |
| xnox | cjwatson: lp:project/stable | 14:58 |
| rickspencer3 | does anyone notice the artwork behind didrocks | 14:58 |
| xnox | (not need to encode the codename) | 14:58 |
| rickspencer3 | those are by his wife, julie, she's an amazing artist | 14:58 |
| dobey | rickspencer3: i have yeah | 14:58 |
| Saviq | :) | 14:58 |
| ogra_ | rickspencer3, she has an afro haricut ? | 14:59 |
| rsalveti | haha, indeed | 14:59 |
| ogra_ | oh ... "by his" | 14:59 |
| ogra_ | :) | 14:59 |
| rickspencer3 | yeah, the "by" is an important word there ;) | 14:59 |
| pmcgowan | next sessions are starting fwiw | 14:59 |
| * didrocks move the camera to make more ad :p | 14:59 | |
| dobey | the session ended 5 minutes ago guys :) | 15:00 |
| ogra_ | haha, you need to put prices on | 15:00 |
| ogra_ | should we schedule a followup session ? | 15:00 |
| sergiusens | bfiller, asac for automerge; the auto tests were ran | 15:00 |
| ogasawara | cyphermox: sorry for the delay, I'm proding these guys to wrap up | 15:00 |
| cyphermox | ogasawara: I m following that session no worries | 15:01 |
| cyphermox | mine will be short and sweet I think | 15:01 |
| rickspencer3 | maybe do it on the phone mailing list or something? | 15:01 |
| asac | sergiusens: i know :) | 15:01 |
| asac | rickspencer3: sure. | 15:01 |
| sergiusens | just reconfirming | 15:01 |
| asac | thanks guys | 15:01 |
| didrocks | thanks | 15:01 |
| asac | was a good session ... and i was even able to hear rickspencer3 at some point :) | 15:01 |
| ycheng | hi, presentation URL please | 15:02 |
| ogasawara | https://plus.google.com/hangouts/_/hoaevent/AP36tYeAxqTjWsaQHLR0uYFiN-6eEqJ4Hl0KAOI1HFX3gsnQNtpEug?authuser=0&hl=en | 15:02 |
| ogasawara | cyphermox et al ^^ | 15:02 |
| xnox | cyphermox: down with bluez-gstreamer! can i go and drop that from ubuntu-desktop?! =) | 15:05 |
| asac | jfunk-canonical: bfiller: kgunn: can you guys give a bullet list of what features "trunk" comes by with beyond review bot and automerge? | 15:07 |
| cyphermox | xnox please don't | 15:07 |
| xnox | cyphermox: =( | 15:08 |
| awe__ | cyphermox, do you know whether or not upstream is working on P2P support? | 15:09 |
| * xnox is on like a minute delay on the stream =) | 15:10 | |
| xnox | cyphermox: thanks for your reply ;-) | 15:10 |
| * ogra_ cant watch this stream either :( | 15:10 | |
| cyphermox | ogra_: why is that? | 15:13 |
| rsalveti | ogra_: just join instead | 15:13 |
| ogra_ | no idea, the live streams dont work for me | 15:13 |
| ogra_ | i canm watch any other video on yourtube and i can join the hangouts, but i cant watch the stream | 15:13 |
| asac | didrocks: you have the presentation URL? | 15:21 |
| didrocks | asac: sure, https://docs.google.com/a/canonical.com/presentation/d/1G4eWxQ8OnwPMXFJFefYdRTKuKZd_Da9Zh2W_X5XRJCc/edit#slide=id.p | 15:22 |
| asac | karni: ^^ | 15:22 |
| karni | thank you! | 15:22 |
| xnox | .. | 15:26 |
| xnox | who is making clicking noises ?! =))))) | 15:26 |
| stgraber | I think it's cyphermox, everyone else is mutedd (but me, but I'm not the source) | 15:27 |
| cyphermox | no, not me | 15:27 |
| ogra_ | must be tony then | 15:27 |
| ogra_ | no | 15:28 |
| stgraber | nope, everyone else but cyphermox are muted now :) | 15:28 |
| ogra_ | definitely cyphermox | 15:28 |
| ogra_ | he needs a can of oil ;) | 15:28 |
| xnox | stgraber: too late, photronix went live with articles saying we are updating bluez to 5 and pulseaudio to latest for 14.04 lts =)))) | 15:30 |
| xnox | </joking> | 15:31 |
| awe__ | xnox! ;D | 15:31 |
| awe__ | http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/ | 15:35 |
| rsalveti | it'll be fun | 15:40 |
| ogra_ | totally | 15:40 |
| rsalveti | do we need bluez5 for our first device? :-) | 15:40 |
| cyphermox | rsalveti: no we don't. it was only awe pestering me about bluez5 before, for HSP/HFP ;) | 15:46 |
| rsalveti | right | 15:53 |
| ogasawara | rsalveti: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng?authuser=0&hl=en | 15:53 |
| ogasawara | rsalveti: assuming you're attending the Qt5 session next | 15:53 |
| rsalveti | yup | 15:53 |
| rsalveti | thanks | 15:53 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Establish forward plan for Qt5 versioning | Url: http://summit.ubuntu.com/uds-1403/meeting/22158/core-1403-qt5-versioning/ | ||
| * ScottK is here. | 15:55 | |
| cjwatson | Cool. Do you want to / can you join the hangout? | 15:57 |
| rsalveti | Mirv: pmcgowan: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng?authuser=0&hl=en | 15:57 |
| didrocks | asac: ^ | 15:58 |
| * sergiusens notices that all the interesting sessions are today | 15:58 | |
| * sergiusens at least for him | 15:58 | |
| sergiusens | ... at least for me | 15:58 |
| didrocks | sergiusens: … at least for you | 15:58 |
| didrocks | :) | 15:58 |
| didrocks | kidding, same for me | 15:58 |
| ScottK | probably. | 15:59 |
| ScottK | Can someone invite me into the hangout? | 16:01 |
| asac | ScottK: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng | 16:02 |
| asac | doesnt work? | 16:02 |
| asac | ogasawara: can you invite ScottK | 16:02 |
| asac | ? | 16:02 |
| * lool listens to stream | 16:02 | |
| ogasawara | ScottK: I can invite you. let me know the email you prefer I use. | 16:02 |
| sergiusens | Mirv, just use the devel list for updates | 16:04 |
| Mirv | sergiusens: yep, CC:d then later on there, but devel is the correct place indeed | 16:08 |
| ScottK | I'm on and off the hangout. | 16:08 |
| ogra_ | now you are on | 16:09 |
| ogra_ | :) | 16:09 |
| cjwatson | I'm watching IRC from time to time, at least | 16:10 |
| cjwatson | So happy to relay if need be | 16:12 |
| ScottK | Can anyone hear me when I talk? | 16:14 |
| ogra_ | nope | 16:14 |
| ogra_ | i cant see you either anymore | 16:14 |
| ogra_ | (you are there but camera seems off) | 16:14 |
| ScottK | I turned my camera off to cut bandwidth. | 16:14 |
| xnox | <xnox> cjwatson: i'd expect each major qt 5.x release to have something major in it ;-) and it did harm us not moving to 5.1 first. We only started fixing 5.1 issues post 5.1 got released, thus those fixes landed in 5.2 only. | 16:15 |
| xnox | <xnox> ditto our 5.2 fixes are landing in 5.3 only. | 16:15 |
| xnox | <xnox> cjwatson: ideally, we'd have touch images with 5.3-trunk available under test. | 16:15 |
| ScottK | zero regression tolerance is a recipe for failure. | 16:15 |
| xnox | similarly how we test openstack-trunk on ubuntu-server all the time. | 16:15 |
| cjwatson | ScottK: I haven't heard any audio from you on the HO so far | 16:15 |
| xnox | (and on top of 12.04 LTS as well, since we backport openstack to last LTS) | 16:17 |
| ScottK | K. can we ask people to be quiet for a moment and I'll talk. | 16:17 |
| cjwatson | (moment) | 16:18 |
| ScottK | sure | 16:18 |
| cjwatson | word-in-edgeways problems :) | 16:19 |
| ScottK | also Qt5 going through the landing process effectively makes it a Canonical only process. | 16:20 |
| cjwatson | ScottK: you probably want to speak slightly slower - intelligible here but there's periodic feedback or something | 16:21 |
| ogra_ | yes, you come across very choppy | 16:21 |
| slangasek | ScottK: really can't understand you :/ | 16:22 |
| slangasek | ScottK: can you type on IRC and we'll relay? | 16:22 |
| ScottK | k | 16:22 |
| ScottK | need to pick a version, land it early, and work through the issues. | 16:23 |
| ogra_ | not sure that works with the no-regression-policy we have for phone | 16:23 |
| slangasek | ScottK: if the "issues" are that the phone image is completely unusable for 2 months of the cycle, that's not acceptable for the phone development | 16:23 |
| slangasek | which AIUI was the state we were actually in | 16:24 |
| cjwatson | ogra_: I'm arguing that that is a policy that is not actually required in all cases | 16:24 |
| cjwatson | I understand why we got there | 16:24 |
| cjwatson | But it's a continuum | 16:24 |
| ogra_ | cjwatson, probably ... its not my policy :) | 16:24 |
| slangasek | right | 16:24 |
| cjwatson | We don't *have* to push the dial all the way to one side | 16:24 |
| ScottK | landing the planned major Qt5 release post FF is not acceptable either. | 16:24 |
| cjwatson | It's a choice to do so | 16:24 |
| cjwatson | ScottK: *nod* | 16:25 |
| slangasek | ScottK: agreed, but just saying that we'll land it come what may and work through the regressions is also not tenable | 16:25 |
| cjwatson | those are two ends of a scale | 16:25 |
| cjwatson | there exists a middle ground; a couple of weeks ago we'd have had some regressions but the phone image wouldn't have been completely unusable | 16:25 |
| cjwatson | there are definitely issues that arise from doing so, but they're maybe a bit more amenable to actually being fixed/worked-around | 16:26 |
| ScottK | lost the call | 16:26 |
| Mirv | manual test results https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdGI4dGllUUxyZGxhc0tZWFhqNnJaaFE#gid=0 | 16:26 |
| Mirv | for the app store apps | 16:27 |
| cjwatson | ScottK: (it never ceases to amaze me what a flaky platform we use for vUDS, but anyway ...) | 16:27 |
| ogra_ | ++ | 16:27 |
| ScottK | can't get back on. | 16:27 |
| cjwatson | the youtube stream has some delay but would at least let us relay back and forward | 16:27 |
| cjwatson | sorry :-/ | 16:28 |
| xnox | cjwatson: slangasek: ideally we'd be testing /next/ trunk-qt on ongoing basis. Cause at the moment, we have no idea how much qt 5.3 is broken at the moment. | 16:28 |
| ScottK | One team shouldn't be able to unilateral lyrics block everyone else | 16:28 |
| pmcgowan | +1 | 16:28 |
| slangasek | ScottK: there's no disagreement on that | 16:28 |
| ScottK | back on | 16:29 |
| ScottK | I like that. | 16:29 |
| ScottK | I'd also like to talk about the process for updating the packages. | 16:30 |
| xnox | cjwatson++ | 16:31 |
| slangasek | Mirv: fwiw, on that list, seagullstrike is the app that requires a rebuild for the Qt5.2 float ABI change | 16:32 |
| slangasek | Mirv: (and com.ubuntu.terminal is the other, which is perhaps not listed there because it's a core app?) | 16:32 |
| cjwatson | ScottK: the landing-silo thing, or branch handling? | 16:33 |
| cjwatson | (or something else) | 16:33 |
| sergiusens | slangasek, we control terminal, so it's easy to get done at least | 16:33 |
| Mirv | slangasek: yep, terminal app has a bug about rebuild needed http://is.gd/pNalUg | 16:33 |
| slangasek | Mirv: ok - just wanting to make sure you know that seagullstrike is expected to be red until it's rebuilt | 16:33 |
| slangasek | (dunno if anyone's reached out to the app developer) | 16:34 |
| lool | Mirv: will it be uploaded to the silo too? | 16:34 |
| Mirv | slangasek: yes, popey has marked it as "ABI Change" "Yes" in the spreadsheet | 16:34 |
| sergiusens | lool, silos for click apps aren't implemented if that's what you are asking | 16:34 |
| slangasek | Mirv: ah, great | 16:34 |
| Mirv | lool: terminal's a click app so it needs recompilation in the store | 16:35 |
| xnox | .. | 16:36 |
| xnox | we use private symbols and headers, thus we don't have abi/api compat guarantee. | 16:36 |
| didrocks | xnox: right | 16:36 |
| ScottK | cjwatson the landing silo thing | 16:36 |
| pmcgowan | xnox, didrocks for apps we do, apps dont use private stuff | 16:37 |
| lool | Mirv: ah terminal is click, right | 16:37 |
| davmor2 | too much work unless you can automated it 100% | 16:37 |
| lool | had forgotten we had converted all core apps | 16:37 |
| cjwatson | I suspect the answer there is going to involve making landing silos less Canonical-only - after all most of the bits are open in some ways, there are just some obstructions | 16:37 |
| cjwatson | they are genuinely useful for being able to assemble a bunch of pieces out of band and then land in one go | 16:38 |
| pmcgowan | but thats a good point actually, as system stuff shares the runtime | 16:38 |
| * ogra_ never thought of them as canonical only | 16:38 | |
| ScottK | back on | 16:38 |
| cjwatson | it's easy for Canonical people not to notice the problems, I suspect | 16:38 |
| ogra_ | true | 16:38 |
| ScottK | the qreal/float thing is a one time bad deal. | 16:38 |
| cjwatson | for instance can non-Canonical people see the spreadsheet? | 16:38 |
| didrocks | cjwatson: yeah, I took great care of that | 16:39 |
| sergiusens | cjwatson, I was told was | 16:39 |
| didrocks | they can even run the jobs | 16:39 |
| * sergiusens checks | 16:39 | |
| cjwatson | do they have the slightest idea where it is? :-) | 16:39 |
| ogra_ | heh, no | 16:39 |
| didrocks | the only thing that will be potentially conflicting is the "assignement to silos" | 16:39 |
| * sergiusens verified train spread works as anon | 16:39 | |
| ScottK | I can see the spreadsheet | 16:39 |
| didrocks | cjwatson: I don't think they read/opened emails on that for instance, so I would doubt about it | 16:39 |
| cjwatson | so, I mean if the answer is that the landing silos genuinely *aren't* Canonical-only then that's good news; I'm not sure I can recall ever seeing a landing from somebody non-Canonical though | 16:40 |
| sergiusens | didrocks, did you get that url shortner I asked for the train? :-) | 16:40 |
| ScottK | as a practical matter they are Canonical. | 16:41 |
| cjwatson | they are basically just branches + PPAs + automation, so it's not something that's fundamentally alien to our community processes | 16:41 |
| ogra_ | right | 16:41 |
| ogra_ | but we need to make them known broadly | 16:41 |
| cjwatson | but they are definitely unfamiliar to non-C core-devs | 16:41 |
| didrocks | sergiusens: I did https://wiki.ubuntu.com/citrain | 16:41 |
| sergiusens | didrocks, awesome | 16:41 |
| didrocks | sergiusens: thanks for the hint! :) | 16:42 |
| sergiusens | np | 16:42 |
| ScottK | maybe not at the same time | 16:46 |
| ogra_ | at the same release | 16:47 |
| ScottK | I think parallel install is going to be really hard. | 16:47 |
| ScottK | yes. by release time. | 16:48 |
| ogra_ | (thought i'm not sure how that will work anyway, touch is basically on a rolling setup already ... totally decoupled from releases) | 16:48 |
| cjwatson | channels | 16:48 |
| ScottK | no upstream support for parallel install | 16:48 |
| cjwatson | I mean it's not *that* different | 16:48 |
| ogra_ | well we dont stick to anything on the release schedule | 16:48 |
| cjwatson | sure, the touch team basically ignores saucy now, but so do lots of desktop/server developers :) | 16:48 |
| cjwatson | we didn't have much of a feature freeze in warty either | 16:49 |
| ogra_ | and with the zero regression stuff we could even drop releases altogether | 16:49 |
| cjwatson | releases aren't just for stability | 16:49 |
| ScottK | I think the main issue was the zero regression tolerance. | 16:49 |
| ogra_ | and just go on rolling | 16:49 |
| cjwatson | they're also for people not having to deal with UI changes except at fixed points | 16:49 |
| cjwatson | talk to somebody running a university's IT department sometime :) | 16:50 |
| cjwatson | changing the interface around in the middle of a PhD student's degree is bad news :) | 16:50 |
| ScottK | we should jointly agree on a target version. | 16:50 |
| slangasek | ScottK: parallel install would be hard, but I think it's something Canonical recognizes we have to eat the work on if that's what's required | 16:50 |
| ogra_ | heh, indeed | 16:50 |
| slangasek | ScottK: do you think agreement will always be possible? | 16:50 |
| cjwatson | I suppose it would have to be a sysroot approach, but UGH | 16:51 |
| ScottK | slangasek: probably. | 16:51 |
| ScottK | Kubuntu will want the latest Qt5, but will need the minimum KF5 version (5.2 now) | 16:52 |
| ScottK | 14.10 we hope to release with a Qt5 desktop. | 16:53 |
| ogra_ | we too :) | 16:53 |
| ScottK | we just need to remember to have the UDS session to decide | 16:55 |
| ScottK | sure | 16:55 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html | ||
| ScottK | I don't know the future requirements | 16:55 |
| ScottK | I have to go. | 16:56 |
| ScottK | Thanks | 16:56 |
| ogra_ | bye | 16:56 |
| cjwatson | ScottK: thanks, very much appreciate your time | 16:56 |
| asac | tanks | 16:56 |
| didrocks | thanks | 16:56 |
| asac | thanks :) | 16:57 |
| slangasek | ah, lunch time | 17:01 |
| * slangasek looks at the sun in the sky | 17:01 | |
| asac | slangasek: ;) | 17:17 |
| asac | get a burger :P | 17:17 |
| ogra_ | and sunglasses | 17:25 |
| ogasawara | https://plus.google.com/hangouts/_/hoaevent/AP36tYfEyF4H5Ix4D_-PoNwjYSGwFkAqsn02jmgkcL9I_Ff1WUTbeg?authuser=0&hl=en | 17:49 |
| ogasawara | for those planning to join the next "Stable Core for Ubuntu Touch" session | 17:50 |
| ogasawara | asac: ^^ | 17:50 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Stable Core for Ubuntu Touch platform beyond 14.04 | Url: http://summit.ubuntu.com/uds-1403/meeting/22162/core-1403-stable-core-platform-for-touch-beyond-14.04/ | ||
| asac | rsalveti: ^^ | 17:53 |
| asac | cjwatson: slangasek: ^^ | 17:53 |
| ogra_ | bah, break already over ? | 17:53 |
| rsalveti | hangout link? | 17:54 |
| didrocks | rsalveti: https://plus.google.com/hangouts/_/hoaevent/AP36tYfEyF4H5Ix4D_-PoNwjYSGwFkAqsn02jmgkcL9I_Ff1WUTbeg?authuser=0&hl=en | 17:54 |
| rsalveti | didrocks: thanks | 17:55 |
| ogra_ | gah | 17:56 |
| ogra_ | i cant click the join button under the checkmark ... no scrollbars in the HO window | 17:56 |
| * ogra_ has to F11 it to go fullscreen and get the last 2cm needed for that | 17:57 | |
| ogra_ | how crappy | 17:57 |
| rickspencer3 | o/ all | 18:00 |
| rickspencer3 | hey, I'd like to join the stable core discussion, but don't see the button | 18:01 |
| rickspencer3 | could the leader please paste me a link? | 18:01 |
| rickspencer3 | nm | 18:01 |
| rickspencer3 | I guess I was too impatient :) | 18:01 |
| ogra_ | we had to discuss if we ant you in there first :P | 18:02 |
| achiang | o/ | 18:02 |
| cjwatson | BTW I have to step out of this session at about the :30 mark, sorry | 18:03 |
| ogra_ | easy ... we just need to double the staff :) | 18:04 |
| xnox | s/Core/SDK/ ? | 18:07 |
| ogra_ | nope | 18:07 |
| ogra_ | OS | 18:07 |
| xnox | ack. | 18:09 |
| xnox | cjwatson: i mean we can be taking 5.2.x | 18:10 |
| ogra_ | xnox, we plan 5.3 | 18:10 |
| cjwatson | the consensus in the Qt session was that we were in practice going to want 5.3 | 18:11 |
| lool | dont we want to start planning for multiple 5.x versions in parallel? | 18:11 |
| xnox | lool: cjwatson: yeah, i'd rather see qt be part of HWE packs (e.g. same way we SRU/package kernels and x11) | 18:12 |
| cjwatson | I don't think that's realistic for 14.04 | 18:12 |
| cjwatson | coinstallation is a lot of work | 18:12 |
| cjwatson | maybe for future releases at some point | 18:12 |
| cjwatson | but I don't think we can be working on that basis | 18:12 |
| lool | not for 14.04, no | 18:13 |
| asac | ScottK: following current session? | 18:13 |
| lool | but we could arrange for having multiple qt runtimes in the future | 18:13 |
| asac | ScottK: would you guys have problems getting 5.3 on trusty? | 18:13 |
| lool | even if the 14.04 one stays where it is | 18:13 |
| cjwatson | that's trusty post-release, for clarity | 18:14 |
| cjwatson | aiu | 18:14 |
| cjwatson | i | 18:14 |
| asac | yes | 18:14 |
| asac | SRU | 18:14 |
| asac | cjwatson: why would qt5.2 be in main in trusty? | 18:14 |
| cjwatson | qt5 is ridiculously far down dependency stacks | 18:14 |
| cjwatson | it's in main *now* | 18:14 |
| cjwatson | main is closed under dependency, once you pull it in somewhere it's in, it's almost impossible to avoid | 18:15 |
| cjwatson | of course only some parts of it are in main | 18:16 |
| cjwatson | qtdeclarative doesn't happen to be, say | 18:16 |
| cjwatson | but I don't think it's a useful distinction to try to draw | 18:16 |
| ScottK | I think Qt5 major version post-release update is very risky. | 18:18 |
| ScottK | We don't even do minor version updates in Qt4 (We have an MRE for KDE, but not for Qt) | 18:19 |
| ScottK | asac: ^^^ | 18:19 |
| slangasek | ScottK: is that risky to the things you're doing in 14.04, or are you just pointing out that it may be risky for unity8? | 18:20 |
| slangasek | or are you concerned about risk to other, out-of-archive work someone may be doing based on 14.04? | 18:20 |
| ScottK | We aren't using Qt5 for Kubuntu in 14.04. | 18:21 |
| ScottK | So from a Kubuntu perspective, it's a don't care. | 18:21 |
| slangasek | right, but there were going to be out-of-archive ppa things using it | 18:21 |
| ScottK | With my SRU hat on though, I think it's an incredibly bad idea. | 18:21 |
| slangasek | so with respect to those, would qt5.2->5.3 risky? | 18:21 |
| ScottK | yes | 18:21 |
| slangasek | oh | 18:22 |
| slangasek | interesting | 18:22 |
| slangasek | so I think we would never take this as an SRU unless we did have the compatibility question locked down | 18:22 |
| ScottK | The history with Qt and second digit updates in Qt4 and Qt5 is not great. | 18:22 |
| ScottK | Just because things are binary compatible, doesn't mean you won't have rendering issues or such. | 18:22 |
| cjwatson | that's indeed the kind of thing that the phone is hitting with 5.0->2 | 18:23 |
| ScottK | I recall cases where API changed because it was the only way to fix a bug. | 18:23 |
| cjwatson | (aiui, I haven't been following very closely 'cos not my field) | 18:23 |
| ScottK | mine nether, but not surprising | 18:23 |
| cjwatson | the other path though is that apps can still be developed targeting the 14.04 api | 18:24 |
| xnox | .. | 18:25 |
| xnox | rickspencer3: but our software store is a single store at the moment, thus people _will_ get e.g. updated core-apps. | 18:25 |
| rickspencer3 | xnox, right, but that's *good* | 18:25 |
| rickspencer3 | people want updated apps | 18:25 |
| xnox | rickspencer3: thus my point is people want updated experience. | 18:26 |
| rickspencer3 | xnox, :) | 18:26 |
| xnox | rickspencer3: everyone wants latest android Kool Koolaid on 4 year old phones. | 18:26 |
| rickspencer3 | yeah | 18:26 |
| achiang | yes, agree with xnox | 18:26 |
| ogra_ | ++ | 18:27 |
| rickspencer3 | I think that ScottK's experience is a little chilling | 18:27 |
| rickspencer3 | it kind of violates a core assumption | 18:27 |
| ogra_ | for the phone we should simply stop doing releases ... and just go on rolling | 18:27 |
| ogra_ | imho | 18:27 |
| xnox | rickspencer3: as long as framework5/kde (provided out of band) is considered when preparing 14.04 updates, i see no reason _not_ to e.g. update qt5.3/mir/platform-api/unity8 in 14.04 LTS. | 18:27 |
| ScottK | I only recall one case of an API change bugfix in Qt being an issue, but it could happen again. | 18:27 |
| rickspencer3 | ogra_, what is the difference between what we are doing on phone and a rolling release? | 18:27 |
| xnox | rickspencer3: e.g. we did backport _a lot_ performance of unity7 into 12.04.1 / 12.04.2. | 18:28 |
| ogra_ | rickspencer3, on ubuntu release day we will move one image to the stable channel and call it "release" | 18:28 |
| tedg | Why is it dark for didrocks but not for asac ? | 18:28 |
| asac | tedg: dark? | 18:28 |
| ScottK | xnox: That's not at all consistent with Ubuntu SRU policy. I think the policy makes sense as is. | 18:28 |
| tedg | asac, Night time | 18:28 |
| apw | he lives in a cellar perhaps | 18:29 |
| xnox | ScottK: right, and we'd need to handle it like we handle other security-regression and sru-regressions, by resolving that. | 18:29 |
| ScottK | xnox: You're missing my point. A major update like that is not suitable for an SRU. Period. | 18:29 |
| didrocks | tedg: no, it's dark for people in europe :) | 18:29 |
| ScottK | The way you avoid regressions is by not doing it. | 18:29 |
| slangasek | ScottK: for me, a precondition on taking this as an SRU would be showing that we can land it /in the devel series/ without the kind of pain and anguish we've had for 5.0->5.2 | 18:30 |
| slangasek | if you're saying that's not realistic, then I don't think we would even consider pushing it into 14.04 | 18:30 |
| xnox | i think the above pre-condition slangasek points out is a good one. | 18:31 |
| ScottK | It likely won't be as painful as 5.0 -> 5.2, but I don't think SRUable is relistic. | 18:31 |
| xnox | slangasek: but would you hold back 5.3 from 14.10 altogether in that case? | 18:31 |
| cjwatson | re releases on the phone, I think the value there is having a stable branchpoint in the case that we find ourselves wanting to do things that don't necessarily align with carrier QA requirements | 18:31 |
| slangasek | xnox: we would not, because it's inappropriate for us to block Kubuntu; but we might decide to stay with 5.2 on the phone | 18:31 |
| tedg | Usually it's not a "week" or something like that. It's a few weeks of testing. Things like full RF testing, etc. | 18:31 |
| ScottK | Copy 5.2 to a PPA and move on. | 18:32 |
| cjwatson | I'm afraid I have to leave at this point - I have an immovable thing I'm taking my daughter to this evening | 18:32 |
| slangasek | no, it would not be ppa | 18:32 |
| slangasek | we would work out the parallel installability of qt versions | 18:32 |
| cjwatson | I dropped a few more comments to Steve which he may or may not want to feed in | 18:32 |
| ogra_ | cjwatson, enjoy (if it is something enjoyable indeed) | 18:32 |
| cjwatson | astronomy lecture, so yes | 18:33 |
| ogra_ | :) | 18:33 |
| cjwatson | I'll catch up with the video later | 18:33 |
| tedg | I think with convergence it means sharing resources as much as possible. | 18:35 |
| tedg | For instance we have a schedule from imports from Debian. | 18:36 |
| tedg | Would Touch have a different schedule? | 18:36 |
| ogra_ | we already have a different schedule | 18:36 |
| slangasek | tedg: imports from Debian should never impact the phone, positively or negatively, and we should have adequate CI in place to ensure this | 18:37 |
| tedg | I'd say we should fix that the opposite why you're suggesting :-) | 18:37 |
| rickspencer3 | I agree in principle with ogra | 18:37 |
| t1mp | when we reach the convergence and have a single ubuntu release for desktop/server/phablet, then we have to follow the "ubuntu" (desktop/server) releases | 18:37 |
| t1mp | right? | 18:37 |
| tedg | slangasek, That's hopeful, really. I mean it's new versions, new bugs happen. | 18:37 |
| ogra_ | t1mp, why not the other way round ? | 18:37 |
| slangasek | tedg: bugs happen but should be caught by integration tests before we promote images | 18:38 |
| ogra_ | swithc ubuntu to be more rolling | 18:38 |
| didrocks | ogra_: +1 | 18:38 |
| ScottK | ogra_: Didn't we already have that conversation. Let's not have it again so soon. | 18:38 |
| tedg | slangasek, *should* :-) | 18:38 |
| t1mp | ogra_: does that include stop having an LTS release? | 18:38 |
| ogra_ | t1mp, no | 18:38 |
| ScottK | If I wanted to run Debian Unstable, I would. | 18:38 |
| ScottK | (or even testing) | 18:38 |
| slangasek | ogra_: we discussed that already, and it was rejected | 18:38 |
| t1mp | ogra_: so you'd have an LTS and a newer rolling version | 18:38 |
| ogra_ | t1mp, you pick one image out of the always stable set and call it LTS :) | 18:39 |
| ScottK | Can we please not do this again. | 18:39 |
| slangasek | saying "Mozilla does rolling updates and the sky hasn't fallen" ignores the fact that this is actually bad for users | 18:39 |
| t1mp | ogra_: yes, but if there are, for example, security issues, you want to patch the LTS | 18:39 |
| t1mp | ogra_: without bringing in all the new stuff from the rolling release | 18:39 |
| ScottK | t1mp: You're just repeating arguments we already had. | 18:39 |
| t1mp | ScottK: yes I'm realizing that | 18:39 |
| xnox | rickspencer3: do we have the u-name yet?! =)))) | 18:40 |
| ScottK | It's at least a month early for that. | 18:41 |
| t1mp | ScottK: I didn't follow the discussion too much the previous time. But I'll just wait see what the people who thought about it come up with :) | 18:41 |
| xnox | rickspencer3: well, you have the device kernel, which is non-changing. | 18:41 |
| xnox | rickspencer3: you will get new libc for example. | 18:41 |
| t1mp | *wait and see | 18:41 |
| t1mp | ScottK: did the previous discussion include phone images? | 18:43 |
| ScottK | No, but it's doesn't change the fundamental argument. | 18:43 |
| t1mp | phones have different requirements, I think you want an LTS on a server, but rolling on a phone (no LTS) | 18:45 |
| xnox | rickspencer3: kernels is a bad example, as we have per-device kernels, no devices run "linux-generic". | 18:45 |
| ChickenCutlass | rickspencer3: the only real reason to move to a new android is mainly to support new hardware where the drivers only exist there. | 18:45 |
| tedg | Seems like it'd be pretty optimistic, as for instance a new init system requires kernel features. | 18:46 |
| tedg | Let's talk about the kdbus transition | 18:46 |
| * ScottK doesn't want rolling on a phone. I'd like something to have been tested and integrated before it lands on the handset I'm using. | 18:47 | |
| slangasek | ScottK: I think you're misunderstanding what "rolling" means here | 18:47 |
| ScottK | Perhaps. | 18:47 |
| xnox | rickspencer3: our update channels are on per-device basis, thus e.g. stable/mako stable/maguro both (typically) have latest rootfs, yet device tarballs are different and can be on per-device cadence. | 18:48 |
| slangasek | it's taken as gospel that any update is tested and integrated before it hits the stable channel; but that stable channel will update at a much higher cadence than 6mo | 18:48 |
| ogra_ | xnox, not true ... maguro doesnt (it could though) | 18:48 |
| xnox | ogra_: there is no ubuntu-archive, or system-image update limitation. | 18:48 |
| ogra_ | (which in turn proves we can just lock one single device to a version ) | 18:49 |
| t1mp | ScottK: new features are tested and integrated, and then land in rolling. So new features go there, but new features don't go in LTS | 18:49 |
| ogra_ | xnox, right, it was a decision we made | 18:49 |
| xnox | ogra_: furthermore decision to drop maguro, is not a technical one, since cyonagenmod did port it to 4.4 base. | 18:49 |
| ScottK | OK. | 18:49 |
| ogra_ | yep | 18:49 |
| rsalveti | xnox: they did, but full of critical bugs | 18:49 |
| rsalveti | and that's why google didn't decide to support it officially | 18:49 |
| xnox | rsalveti: sure. but we can reupload older android base as android-maguro and build the old 4.2 android image for it. (we don't want to, cause it's not a meizu/bq :P) | 18:50 |
| rsalveti | xnox: atm, yes | 18:50 |
| achiang | how do people opt-in to unity8 on desktop today? | 18:51 |
| ogra_ | by installing a metapackage | 18:51 |
| slangasek | ogra_: we *can* lock a device to a version of the rootfs, but it's shooting ourselves in the foot to ever do that for production devices | 18:51 |
| ogra_ | yeah | 18:52 |
| didrocks | achiang: they do install either unity8-desktop-session-mir or unity8-desktop-session-x11, then there is a new session in lightdm | 18:52 |
| slangasek | we do it for maguro because that's for internal dogfooding purposes | 18:52 |
| slangasek | but we shouldn't do this for real devices | 18:52 |
| ogra_ | tell that to i.e. samsung :) | 18:52 |
| achiang | seems like we should keep that same mechanism for 14.04 release | 18:52 |
| slangasek | do I need to be telling that to samsung? | 18:52 |
| slangasek | I think it's achiang's job to tell them that :) | 18:52 |
| ogra_ | well, they probably provide two updates in the lifecycle of a phone | 18:52 |
| ogra_ | ah, heh, yeah, indeed | 18:53 |
| tedg | Staticly compile it all! | 18:53 |
| rsalveti | I wonder if the vendor would also need to certify a newer stack/release | 18:53 |
| tedg | :-) | 18:53 |
| rsalveti | major one at least | 18:53 |
| xnox | tedg: juju doesn't upload into the archive =) | 18:53 |
| sergiusens | tedg, that's why we are rewriting everything in go ;-) | 18:53 |
| ogra_ | go go go | 18:54 |
| tedg | I guess I just don't understand who wants their phone to change more frequently than every 6 months. | 18:54 |
| tedg | :-) | 18:54 |
| ogra_ | you dont get much in contact with teenagers, eh ? | 18:55 |
| rsalveti | you'd be surprised | 18:55 |
| ogra_ | :) | 18:55 |
| === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html | ||
| sergiusens | tedg, it doesn't even need to be an improvement | 18:55 |
| sergiusens | just change icon colors or something | 18:55 |
| sergiusens | :-P | 18:55 |
| tedg | Can we just rotate the backgrounds? | 18:55 |
| tedg | Daily? | 18:56 |
| sergiusens | exactly | 18:56 |
| slangasek | tedg: I don't want to wait 6 months between security updates! | 18:57 |
| achiang | slangasek: you can be on the devel channel then ;) | 18:57 |
| asac | good one | 18:57 |
| tedg | slangasek, I have nothing to hide, I'm not a terrorist. | 18:58 |
| asac | the devil channel :) | 18:58 |
| asac | lol | 18:58 |
| slangasek | achiang, tedg: could you please coordinate your trolling | 18:58 |
| slangasek | I'm having trouble following all of this | 18:58 |
| ogra_ | just change the version number :P | 18:59 |
| ogra_ | hmm, my HO locked up | 18:59 |
| tedg | slangasek, Just wait for the promoted troll | 18:59 |
| ScottK | slangasek: +1 on phone security updates. solve getting those to end users quickly and consistently and that'd be a real advantage. | 19:06 |
| slangasek | ScottK: right... for the moment, the proposed model for doing that is frequent rolling updates, but this probably needs to be revisited once we have more real phones in the field | 19:07 |
| ScottK | So I lose use of the phone for $MINUTES where the value might be more than a single digit for each security update? | 19:07 |
| ScottK | (base on how long Andriod system updates take, I don't know if that's a fair comparison) | 19:08 |
| slangasek | ScottK: eh, I don't know how long the downtime will be for the updates... hopefully we'll do better than that. But the basic update model will still require a reboot to recovery | 19:27 |
| slangasek | (there are reasons we're doing image-based updates, for devices that we have no text console or recovery media for) | 19:27 |
| * ogra_ hopes we'll do image based updates on other devices too in the future :) | 19:30 | |
| === salem_ is now known as _salem | ||
| === jibel_ is now known as jibel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!