[14:58] <ricmm> hi
[14:59] <kgunn> link ?
[15:00] <tsimpson-uds> see /topic
[15:06] <tvoss_> didrocks, o/
[15:06] <mzanetti> we broke it!
[15:07] <didrocks> mzanetti: ricmm is broken, that's what I thought :p
[15:07] <didrocks> hey tvoss_
[15:10] <tvoss_> ricmm, I think lifecycle shoul dbe handled per stage
[15:18] <tvoss_> ricmm, I would propose to look into content hub
[15:18] <tvoss_> too
[15:18] <tvoss_> didrocks, Saviq, kgunn ^
[15:18] <Saviq> tvoss_, maybe join the hangout/
[15:18] <Saviq> ?
[15:18] <didrocks> tvoss_: what do you mean but looking into content hub?
[15:19] <didrocks> for clipboard?
[15:19] <Saviq> tvoss_, but yes, I did think that the hub could be integrated
[15:20] <tsdgeos_uds> ricmm: what's the plan for the "new sidestage features" for surfaceflinger, will still support them for the other ports that don't use Mir?
[15:20] <tsdgeos_uds> or should just all other ports just use Mir?
[15:21] <tvoss_> didrocks, yup, it's the same scenario, content source, destination and actual content
[15:23] <Saviq> tsdgeos_uds, yeah, that's a very good question, not sure we will be able to answer it here
[15:30] <tsdgeos_uds> ack, makes sense :-)
[15:34] <mzanetti> Saviq: will we do this properly soonish then? https://code.launchpad.net/~unity-team/unity8/split-surfaces
[15:36] <Saviq> mzanetti, possibly, the while scenegraph topic binds into this a lot
[15:36] <Saviq> mzanetti, more so than the side stage, I'd say
[15:36] <mzanetti> mhm
[15:38] <mzanetti> didn't we have a destkop file hint which specifies supported stages?
[15:39] <Saviq> delivery...
[15:39] <Saviq> mzanetti, default, not supported
[15:39] <mzanetti> iirc there was a month or so where we had another one too
[15:39] <mzanetti> but that one stopped working at some point and was removed from all the apps
[15:40] <tvoss_> didrocks, Saviq my broadband dropped, resurrecting it now
[15:40] <mzanetti> games?
[15:43] <mzanetti> ricmm said there won't be landscape only
[15:43] <mzanetti> but games might really do that
[15:44] <mzanetti> so it would run on tablet main stage and phone, but not tablet sidestage
[15:49] <mzanetti> yes
[15:50] <mzanetti> yeah... got it
[15:55] <didrocks> now, the challenge is going to be able to stop ricmm :)
[15:55] <mzanetti> :D
[15:59] <sil2100> ;)
[16:00] <Saviq> ricmm, to make sure you have that: http://pad.ubuntu.com/uds-1311-client-1311-enable-sidestage
[16:04] <cjwatson> hangout url?
[16:06] <Ursinha> didrocks, ^
[16:06] <zyga> hi
[16:07] <ev> I'll be taking any questions you have on Didier's presentation or the CI Airline on the whole.
[16:07] <tedg> ev, Will you be serving drinks and roasted nuts as well?
[16:07] <tsdgeos_uds> did the stream just die for everyone or just me?
[16:07] <robruds> tsdgeos_uds: works for me
[16:08] <dobey-uds> tedg: i'm going to need all the rum you have.
[16:08] <ev> dobey-uds: if you want a speaking slot, there's still space
[16:08] <ev> tedg: :)
[16:09] <ev> or anyone else for that matter - we've got plenty of space in the on air hangout
[16:11] <dobey-uds> ev: i don't want to complain too much in the session :)
[16:11] <ev> dobey-uds: it's the point of the session
[16:11] <ev> getting feedback from upstreams
[16:11] <tedg> It's hard to think of positive feedback :-)
[16:13] <ev> tedg: feedback on the new idea
[16:13] <ev> not the current approach
[16:14] <ev> do feel free to ask questions now. I'll happily queue them up for Didier.
[16:21] <tedg> QUESTION: You've been talking about updating for changing images, how about changing trunks?
[16:21] <ev> tedg: can you elaborate on what you mean by changing trunks?
[16:21] <tedg> ev, Foo app gets new bug fixes on trunk
[16:23] <cjwatson> This optimises strongly for feature work that requires extensive testing; it's making trade-offs in favour of that.  I really want to make sure that changes where that trade-off isn't justified don't need to go through this, as it would have a very scary effect on velocity if they did.
[16:23] <dobey-uds> QUESTION: Why the emphasis on anti-isolation?
[16:23] <cjwatson> While at the same time ensuring that the bells-and-whistles CI facilities are available for the cases where they're needed.
[16:23] <infinity> +1 to Colin's comments there.
[16:24] <tedg> I don't know how you can really have a "lock", I mean, there are likely to always be more features landing than we'll have HW to lock everything.
[16:24] <cjwatson> The "small bug fixes" bit at the beginning of the presentation alludes to that discussion, I think, but that's a substantial policy grey area that I think is worth thinking about.
[16:24] <ev> cjwatson, infinity: are we talking about the time it takes to run the tests? Because this isn't blocking on human beings, so I'm trying to understand what you're worried will decrease development velocity.
[16:24] <cjwatson> No, I'm talking about the whole thing.
[16:25] <cjwatson> There are days when I make 20-30 changes to the archive for build fixes, transitions, and the like.
[16:25] <dobey-uds> tedg: the pervasive requirement of specific hardware/device testing is definitely a problem
[16:25] <infinity> ev: The whole end-to-end "register intent to change" all the way to "landing".  It's far too heavy for a simple/small fix/change.
[16:25] <tedg> Will there be a choice of who gets sign-off on take off?  I'm guessing we don't need design sign off for Upstart features.
[16:25] <ev> cjwatson: sure, but if you had a simple way of throwing a dsc at this and forgetting about it, would that not work
[16:25] <cjwatson> No.
[16:25] <cjwatson> It's far too heavyweight.
[16:25] <cjwatson> And unnecessary.
[16:26] <cjwatson> Given that all I actually need for most of that is "does it build and does it pass autopkgtests", which I already have.
[16:26] <tedg> And most transitions are handled by the proposed handling.
[16:26] <cjwatson> (Looks like Didier is getting to what I care about now)
[16:27] <zyga> how does this session relate to people working on ubuntu components patch by patch, can I somehow not maintain my own CI infrastructure?
[16:27] <ev> cjwatson: okay, I cannot condense that down into a sentence, so after we handle tedg and dobey-uds' questions, may I ask that you raise your concerns?
[16:27] <cjwatson> Sure
[16:27] <ev> much appreciated
[16:29] <ev> zyga: you're free to use whatever you want to verify your code before uploading.
[16:29] <zyga> ev: uploading? when I'm uploading it has to work already, what I want is something that helps me on the way there, by the time I upload packages it is already too costly or too late to fix something that was broken early on
[16:30] <ev> zyga: So this is one such approach that allows that continuous feedback
[16:30] <tedg> ev, Do we have data on how many cross-package mega-features we do per cycle?  I'm guessing 2, perhaps 3.  Worried we're building something for a minority of use-cases.
[16:30] <ev> tedg: noted
[16:31] <zyga> ev: so is the intent to use this system to create a package for each patch that lands into ubuntu so that it goes through all of that before landing?
[16:31] <dobey-uds> tedg: indeed. it feels very TSA to continue the metaphor
[16:31]  * tedg feels safer now
[16:32] <ev> zyga: you can feed this system a branch or a dsc file
[16:33] <zyga> ev: so I propose a merge request on launchpad, I go to this boarding system, point it at my branch, what happens next? does it land my branch after I'm done, does it comment on the merge request? can I do that for all the proposals I'm doing?
[16:34] <zyga> ev: does it go to ubuntu? to my project trunk?
[16:34] <dobey-uds> this seems all about testing everything all at once together, versus simply pushing developers to write isolated code
[16:34] <cjwatson> Damnit
[16:34] <tedg> ev, Feed it a branch?  Isn't that basically what a MR is?  Will MRs be considered "small fixes" by default?
[16:34] <zyga> cjwatson: how is this different from autopackage tests?
[16:34] <cjwatson> I was having audio problems yesterday, but I'd hoped they were just with mumble
[16:34] <cjwatson> Let me try restarting my desktop env
[16:35] <cjwatson> I'd like to do this by audio, so I'll get back to you
[16:35] <infinity> ev: Your audio is very choppy.
[16:35] <ev> boo :(
[16:36] <ev> infinity: can you carry this one?
[16:36] <zyga> audio too choppy to understand
[16:36] <ev> or raise your concerns
[16:36] <zyga> does the system exist or is this a proposal for something new?
[16:36] <zyga> ev: ^^
[16:36] <dobey-uds> too much background noise for ev
[16:36] <zyga> and how does it tie into UDD (ubuntu distributed development), if any
[16:38] <Ursinha> didrocks, I wonder if your workflow diagrams cover all these questions?
[16:38] <ev> Ursinha: do feel free to share them here
[16:38] <ev> zyga: it's something being built
[16:39] <Ursinha> ev, it was an honest question, I don't know if they cover these cases (if they don't we might need to extend them)
[16:39] <ev> oh :)
[16:39] <zyga> ev: is this something you see being required for all updates to stable ubuntu releases?
[16:40] <ev> zyga: to be clear, we are not requiring this for core-dev uploads.
[16:40] <ev> but yes, this system can handle SRUs
[16:40] <ev> I'll raise that question with didier so he can explain further
[16:42] <cjohnston> The lock only lasts from the time that a ticket is marked as ready to be merged until it's merged, should be hours at best
[16:42] <cjohnston> (best meaning most)
[16:46] <Ursinha> I love the analogies
[16:46] <zyga> cjwatson: good comparison
[16:46] <plars> heh
[16:49] <tedg> In France the change the speed on the highway during holidays?
[16:49] <cjwatson> As a cyclist, I also don't think that car travel is a good analogy for an efficient system :-)
[16:49] <tedg> Wow.  That'd never fly in Texas.
[16:50] <dobey-uds> tedg: many highways in the US do as well, when there are high traffic situations. not just holidays, but during rush hour and such even
[16:50] <plars> tedg: wait, we have speed limits in Texas? since when?
[16:50] <tedg> plars, They're listed on the white signs with bullet holes
[16:50] <cjwatson> Last time I drove in Texas the speed limit was 55mph for a three-hour empty highway ...
[16:50] <kgunn> plars: 80mph on that tollway near your city it awesome
[16:52] <arges-uds> (I'm late so this may have already been covered) Does this fundamentally change the SRU process?
[16:52] <dobey-uds> arges-uds: no
[16:53] <arges-uds> : )
[16:53] <didrocks> cjwatson: well, I'm a cyclist as well, but I guess the global speed one is a still giving some help (/me would love that the speed in his city on the road with cyclist line is slower to be safer)
[16:54] <cjwatson> Right.  But part of the problem is precisely that car travel doesn't scale up; you make roads more efficient for drivers by removing cars (there are studies on this, there's a tipping point where there's a fairly sharp corner in the graph).
[16:54] <tsdgeos_uds> i'm with tedg here, i don't want nor need this big thing for this MR https://code.launchpad.net/~aacid/unity-mir/nomegaheader/+merge/195823
[16:55] <vila> the ci system also give access to more hardware than all devs can have on their desktop
[16:55] <cjwatson> This analogy is getting rather laboured :-)
[16:55] <dobey-uds> tedg: it's full autowaited
[16:56] <plars> There seems to have  been some value in the past of tracking what's about to land in the image. Isn't that the motivation for even having patches going through the lightweight process get a "ticket"?
[16:56] <cjwatson> I dispute that value
[16:56] <cjwatson> (In the case of lightweight changes)
[16:56] <ev> cjwatson: please raise that then :)
[16:56] <cjwatson> I think it has made some people feel more in control, but I think that control is artificial
[16:57] <cjwatson> Again, and I'm sounding like a broken record: for more substantial feature work, by all means
[16:58] <dobey-uds> cjwatson: and even then, that work should be incremental, not huge swathing changes, i think
[17:00] <dobey-uds> who is doing the work to write all the toosl, or fix issues in launchpad?
[17:00] <infinity> cjwatson: Indeed, "people having control" shouldn't be a goal in itself, unless the control is useful.  In a distributed development environment, often "people having control over landing" is of benefit to exactly no one except that person's ego.
[17:01] <Ursinha> dobey-uds, that's still being discussed, that would be the ci team, I believe
[17:02] <dobey-uds> Ursinha: i wonder if any of the work is going to be fixing issues in launchpad to make it more useful for such processes, or just writing weird custom hacks on top of what already exists there (or just using external stuff like google docs to track things)
[17:02] <Ursinha> infinity, also having a bottleneck is against the principle of continuous integration
[17:02] <dobey-uds> because custom hacks are not fun
[17:03] <Ursinha> dobey-uds, I'm suggesting that we use launchpad as the "ticketing system" as we already use a lot of it to other parts of the process, wgrant said he would be happy to discuss other parts that could be fixed in launchpad (like the jenkins part, for instance)
[17:04] <Ursinha> dobey-uds, that said I agree with you :)
[17:04] <dobey-uds> and in particular, i don't want someone to go write another custom branch merge/commit solution and reimplementing features poorly, when we have tarmac
[17:05] <M3kH> is started the Unity8 shell discussion?
[17:05] <Ursinha> dobey-uds, I believe most people agree on that
[17:05] <dobey-uds> Ursinha: anyway. i would like to be included in those discussions
[17:05] <kgunn> M3kH: another hour
[17:06] <Ursinha> dobey-uds, sure, please join the discussion :) I can point you the documents and we can start to discuss more in the open so other people can join as well
[17:06] <M3kH> ooh :) cool I have the time for come back home
[17:06] <dobey-uds> am still a bit in shock from being told last night "oh, we're going to make huge changes to our process again"
[17:07] <dobey-uds> Ursinha: great. yeah, please e-mail me the links to those docs and ping me to be in discussions when possible :)
[17:07] <Ursinha> dobey-uds, sure, will do
[17:07] <dobey-uds> Ursinha: thanks!
[17:07] <Ursinha> np :)
[17:07] <dobey-uds> ok. time to get lunch over here
[17:07] <dobey-uds> later :)
[18:03] <kgunn> just rounding folks up from lunch....bear with us
[18:06] <kgunn> hangout https://plus.google.com/hangouts/_/72cpjf8uetpdtf0ed3u4t3lm64?authuser=0
[18:10] <kgunn> the pad saviq is referencing http://pad.ubuntu.com/uds-1311-unity8-shell-discussion
[18:18] <Saviq> https://wiki.ubuntu.com/Apport
[18:21] <pstolowski_> I think it's worth mentioning that when you run unity8 on the desktop, it's going to connect to the backend services of the desktop (e.g scopes), so you cannot replicate the exact phone experience. any hints about making it similar to the phone as much as possible while running on the desktop?
[18:25] <Saviq> https://wiki.ubuntu.com/DebuggingProgramCrash
[18:26] <Saviq> https://lists.launchpad.net/ubuntu-phone/msg04549.html
[18:28] <pstolowski_> is cross-compilation possible?
[18:28] <Saviq> https://wiki.ubuntu.com/SimpleSbuild
[18:30] <Saviq> https://wiki.ubuntu.com/CrossBuilding
[18:30] <pstolowski_> awesome, thanks
[18:32] <Saviq> http://pastebin.ubuntu.com/6444153/
[18:35] <veebers> Saviq: Could we cover quickly running the tests? qmltests and autopilot etc
[18:36] <veebers> hmm, does anyone else get a "Proxy Error" from the etherpad?
[18:36] <kgunn> veebers: yes...seems to be down
[18:36] <veebers> kgunn: ack, thanks for confirmation
[18:36] <kgunn> back up now tho
[18:37] <veebers> You could also, cd tests/autopilot; autopilot run . . .
[18:39] <kgunn> veebers: feel free to edit etherpad for posterity's sake
[18:39] <veebers> kgunn: cool, will do when I get access back
[18:45]  * mzanetti thinks of questions to bug Saviq
[18:46] <Saviq> mzanetti, too late ;P
[18:48] <kgunn> mzanetti: i'm pretty sure you know where he works