=== kalikiana__ is now known as kalikiana_ === wgrant_ is now known as wgrant === psivaa_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - === psivaa_ is now known as psivaa === lan3y is now known as Laney === Laney is now known as Guest1882 [09:04] psivaa: hi and happy new year! there seem to be some lock files or such preventing both autobuilds and at least hud stack build - http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/377/console [09:05] Mirv: happy new year to you too, let me take a look === Guest1882 is now known as Laney [09:08] thanks, no hurry [09:18] hmm, no tests for #115 and #116 [09:18] ogra_: will take a look at that too [09:19] thx [09:19] seems to have fallen over yesterday already [09:27] ogra_: is there another image due now or shall i run the tests for 116? ( i'll need to see if we could run 115 at all) [09:27] 116 is the latest from 3am UTC tonight [09:28] the next auto-build would be at 15:00 UTC ... if we dont decide to disable that one and switch to manual [09:28] so i'd say skip 115 [09:29] Mirv: this stale stack issue requires some lock files deleted. i think it's safe now to remove them because there is no job running at the moment. [09:29] looking over the last days i wouldnt expect any dramatic change anyway [09:29] ogra_: ack, thx. i've started to run with 116 [09:29] awesome :) [09:32] Mirv: hey, joining? [09:32] psivaa: ^ [09:32] sigh, my talkpluginb asks weird questions [09:33] ogra_: give weird answers then! [09:33] didrocks: joining [09:33] :) [09:33] Like "What's the weight of an unladen swallow?" [09:33] plars: psivaa: hi ... could we resume sending around the retried jobs (e.g. flaki ones?) ... or is mako really magically green nowadays? [09:33] i think a mail to landing teams at end of day would be nice [09:33] didrocks, it doesnt tell me where i can give these answers unless i read a multipage help thingie [09:33] asac: ack, will do [09:34] sigh [09:36] so even setting the permissions according to the help file it still asks me to set them [09:36] psivaa: yep nothing is running so lock files could be removed [09:37] Mirv: ack, doing that === vrruiz_ is now known as rvr [09:40] Mirv: i've kicked off the job in concern.. http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/378/console [09:40] appears progressing [09:41] psivaa: thanks! looks good now again, we'll get a bit fresher look and I fixed hud stack for example so it should try to build properly [09:41] Mirv: ack [09:41] argh ... and the firefox upgrade i just did makes it unstartable now ... yay for keeping an LTS installed for stability [09:41] * ogra_ shakes his fist [09:44] WOAH ! [09:44] i had to remove the locale package ! [09:55] Mirv: remember we have the weekly meeting tonight :) [09:58] cronjob for 15:00 UTC disabled [09:59] thanks ogra_ :) [09:59] didrocks: sure! :) === greyback_ is now known as greyback [11:05] didrocks: aiming to promote 116? [11:05] (assuming tests etc) [11:06] popey: yeah, if you can get anough testing with davmor2 :) [11:06] kk [11:07] didrocks, popey: Hey anything specific that we are looking at? Was swap dropped or is that to come? [11:08] davmor2: no, just usual health check :) [11:08] didrocks: will do [11:08] thanks! [11:11] popey: is mtp working for you? [11:12] didrocks: ^ [11:12] yes [11:13] popey: thanks === cjwatson_ is now known as cjwatson [11:19] davmor2, swap is still in ... we'll announce if we drop it [11:20] ogra_: that's fine, Might be good to run some tests with it disabled again before we drop it. [11:20] yes [11:20] thats the plan [11:20] ogra_: but not today === alan_g is now known as alan_g|tea [11:34] davmor2: do you have a bluetooth headset? [11:34] popey: I do it connects now but doesn't work [11:34] ok [11:34] pulse most likely [11:35] missing profiles etc [11:35] it breaks phone calls too [11:35] for me, if I attach bluetooth headset, i can no longer make or receive calls [11:35] ogra_: no I have a bug for the initial issue [11:35] yeah, that points even more in pulse direction [11:35] ok, will file a bug [11:35] unless you know of one already? [11:35] popey: see the spreadsheet [11:36] that is one bug [11:36] doesnt describe it [11:36] for you it looks like another again though [11:36] yeah [11:36] k [11:36] filing [11:37] possibly just needs a profile like the wired headset [11:38] right === alan_g|tea is now known as alan_g [11:52] bug 1266738 [11:52] bug 1266738 in pulseaudio (Ubuntu) "Bluetooth headphone pairing works, but no audio output - Mako #116" [Undecided,New] https://launchpad.net/bugs/1266738 [12:15] didrocks: if I have an issue with a the layout of indicators what do I file the bug against? ie if you disable BT and then re-enable it from the setting and then drag down the BT indicator it is showing the Location settings [12:15] I'm assuming unity8 [12:16] davmor2: for those, I would say unity8 as well [12:16] Saviq: hey, agreed? ^ [12:16] davmor2: i filed one for that [12:16] bug 1264678‎ [12:16] bug 1264678 in Unity 8 "Incorrect indicator appears under correct indicator heading" [High,Triaged] https://launchpad.net/bugs/1264678 [12:20] popey: thanks [12:28] didrocks: mtp is still not working here for me [12:29] davmor2: ok, so, this is a regression compared to latest published image? [12:29] promoted* [12:29] fginther, hey, can you repo init from scratch? I see the jenkins build pulling in the prebuild kernels which I don't get when doing this from scratch [12:29] didrocks: yeap happened I noticed it around build 100 [12:30] davmor2: ok, do you know anyone else with a maguro who can confirm it's a maguro regression? [12:30] didrocks: ignore that it's just kicked into life [12:31] * ogra_ has a dejavu [12:31] didnt we have that before ? [12:31] ogra_: it seems really temperamental at the minute [12:32] i cant confirm on my maguro [12:32] works as it should [12:35] ogra_: for me the icon shows as soon as I plug it in but nautilus never seems to open and I get the error message, works fine on my n7 running touch though [12:36] davmor2, oh, i was commenting on the indicator stuff [12:36] bingo seems to be working nicely no [12:37] ogra_: ah yeah that was they were all jumbled before this is just if you remove one and then add it back again [12:38] right, i just did that here [12:38] and it works fine [12:47] ogra_: to be honest I think it depends on the usage of the indicators etc, I'd just used the location indicator to turn on gps [12:47] i switched bluetooth off and on several times [12:49] ogra_: could just be a race condition maybe [12:49] yep [12:52] didrocks: right so mtp looks to be working here now just not as snappy as it was, this maybe down to the fact that I running a fresh saucy on this box rather than raring that was on it, or it maybe the changes that have been made to the upstart script, and the fact that it is maguro [12:55] sergiusens: mtp and adb are still not getting on mtp is still kicking an adb session off [12:56] davmor2, are you sure it's mtp and not the start of android? [12:56] davmor2: ogra_: popey: so let's wait for the test results, and if you +1, we can publish it [12:57] yep [12:57] +1 [12:57] sergiusens: hmm could be I guess, but the action you see is adb shell is connected when mtp shows in nautilus it kicks the adb session [12:57] (thats me +1ing you saying that, and also +1ing the image) :D [12:57] didrocks: +1 looks good here only old issues nothing new [12:57] davmor2, well they are trigger almost at the same time [12:59] sergiusens: it's the action of mtp displaying in nautilus when you see the adb get kicked though. Not the initial connection which I assume is instant (Ie when the icon appears on the launcher) [13:00] davmor2, do this, disable the mtp job and verify that you still get kicked out ;-) [13:01] sergiusens: give me a minute === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [13:15] popey: in settings if you select backgrounds, then select different backgrounds for each, and set the home one to an image, and leave the welcome screen on the default what happens when you hit the power button a couple of times to show the welcome screen [13:16] ugh, hate changing the background because it's a bitch to unset it === alan_g is now known as alan_g|lunch === cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [13:59] morning [14:07] sergiusens: if that was the case then it would be a very out of date image [14:07] I haven't touched mtp since ... last year, and it's not my top priority right right now ;) [14:07] cyphermox, context? [14:07] sergiusens: mtp kicking off adb [14:08] cyphermox, oh, I'm saying that as well [14:08] doubtful that it's the case for a QA job. [14:09] cyphermox, i asked davmor2 to disable mtp for him to verify that this wasn't mtp kicking him off [14:09] yeah === alan_g|lunch is now known as alan_g [14:10] sergiusens: sorry just back from lunch give me 5. How do I disable the job from auto starting then, upstart is not a strong point for me :) [14:12] sergiusens, trying [14:12] davmor2, echo manual /usr/share/upstart/sessions/mtp-server.override [14:12] davmor2, add the missing > ;-) [14:13] sergiusens: add the missing evil face ;) [14:13] lol [14:15] sergiusens: meh forgot to enable write mode first D'oh [14:15] tries again [14:16] davmor2, before ubuntu touch was trendy and everyone started using it, we even then had this problem; it started with the container switch [14:17] sergiusens: ah okay we'll soon find out, and then just blame ogra_ if it is ;) (Bound to be his fault somewhere along the line ) [14:18] oh, back then ... the good old times === ricmm|sick is now known as ricmm === bregma_ is now known as bregma [14:21] sergiusens: hmmm I set the override with echo manual > /usr/share/upstart/sessions/mtp-server.override and it still tried to connect mtp [14:22] sergiusens: and that was after a reboot [14:22] well, the server won't be started but the device will still be registered as an MTP device, so you'll still get dialogs on your desktop [14:23] cyphermox: ah okay [14:23] davmor2, the dialogs are a different story [14:24] sergiusens: indeed :) [14:24] sounds very much like a case of android starting -- you probably still get kicked off of an adb session [14:24] it is [14:25] before: android booted first, android started adb; period [14:25] right starting again unplugged the phone, reattached it, started adb shell [14:25] still connected [14:25] after: ubuntu's init started adb; upstart started adb; android starts adb [14:25] sergiusens: now, ubuntu starts adb, android starts, android starts adb again, no? [14:26] Yeap just got kicked [14:26] so android starting is the issue then, is there a bug for that? [14:26] cyphermox, pretty much [14:26] cyphermox, sergiusens ^ [14:26] davmor2, no; a workitem in a blueprint [14:27] sergiusens: great okay thanks [14:54] fginther, btw, can we get merger for lp:usensord now? Sorry if I missed an ETA about this [15:00] sergiusens, I'm still working on it, the x86 box is not upgrading to saucy well [15:00] should be working by tomorrow [15:01] ah, great; thanks [15:08] didrocks: https://wiki.ubuntu.com/DailyRelease/InlinePackaging is guidelines, not strict rules, right? [15:23] dobey: not strict rules but if you follow them it works better and makes it easier for us to help you out with daily release if necessary [15:24] most are there as safeguards so that regressions are readily apparent, etc. [15:24] right [15:25] for instance, export DPKG_GENSYMBOLS_CHECK_LEVEL = 4 [15:25] yes, which i do [15:25] cyphermox, dobey is also pretty opposed to split mode [15:26] but native vs. bzr-builddeb split mode packaging is not part of that [15:26] *shrugs* [15:26] neither one is going to make any regression any more apparent, or make changes easier to review. it's something you do at the beginning and generally adhere to [15:27] and the wrap-and-sort, or annoying vcx-bzr comment don't make avoiding regressions any easier [15:27] or more apparent [15:27] no, they make maintenance easier [15:27] easier in some cases, yes [15:29] but having dependencies already sorted, and on separate lines, isn't made more readable or easier to manage, by having them spaced out an arbitrary number of spaces based on the name of the field they're in [15:29] I fail to parse that line, and busy with too much state to try harder [15:30] dobey: in general, we'd just rather you follow those guidelines to make it easier for us to work with your branch and help you with daily-release [15:30] and the comment about vcs-bzr is just silly because the whole point of daily-release is that people don't just upload changes directly into the archive. [15:30] dobey: in some cases it's necessary to [15:30] we don't want to make it so people absolutely can't land time-critical changes [15:31] are those cases documented anywhere? because the InlinePackaging wiki page sure makes no reference as to why that comment should be there, or what those cases are [15:31] dobey, remember there are core devs and motus that sponsor patches, etc [15:31] so sometimes upload directly [15:31] when that happens, we have to backport those to upstream [15:32] dobey: the comment is just a comment. omit it if you prefer [15:33] kenvandine: would it not be better to communicate that such uploads shouldn't happen (unless an absolute emergency requires it), and that changes should be donea s merge proposals to the upstream branch? [15:34] they are rare [15:34] and that comment could help show people where their changes belong [15:35] not all ubuntu developers are bzr users [15:35] old school :) [15:35] didrocks: 116 looks good for tests.. [15:36] believe it or not... there are still people that seem to like using quilt [15:36] kenvandine: the comment may also be lying. i don't want people to assume that just because they uploaded something to the archive, that it will definitely be an accepted change upstream. because it makes no sense [15:36] * kenvandine hugs packaging with bzr [15:36] well, using quilt is great for packaging things you don't actually own, when you need to make changes to them [15:36] dobey, ah... but we'll catch that quickly [15:37] the daily release machinery would flag the package for having an uploaded change that isn't in trunk [15:37] which we would then propose a branch for [15:37] which could get rejected [15:40] right. but i think there are too many potential points of human error in that process. [15:42] i don't think we can reduce that any more than we have already [15:43] well, it's going to happen regardless of whether that comment is there or not [15:43] and the Vcs-Bzr is there, so anyone with upload privileges should know to use it [15:43] we've had at least two major projects that were sufficiently short-duration that we didn't have time for uploads to go through daily release, just recently; you should certainly assume such things will continue to happen [15:44] indeed [15:44] when you're trying to get thousands of packages to build you don't have time to cope with a small fraction of them being special snowflakes :) [15:44] and we have process in place to keep from uploading over those [15:45] kenvandine: it's just a shame we can't use git-dpm (yet ...) [15:46] not using git is a win in my book [15:46] I'm not git's biggest fan, but git-dpm is light-years ahead of anything bzr can offer [15:46] i've never tried it, but i do love bzr bd :) [15:48] And with bzr basically being a dead project, the git ecosystem is only going to get further ahead :-/ [15:49] dobey: kenvandine: until trunk matches distro, always, it hurts everyone to be able re-arrange / prioritise which sets of changes get in. At the moment one can only land trunk, and if it has 10 features 1 bugfix 1 packaging-fix, one cannot land any part without other two. [15:49] (Similarly, dgit was fundamentally more reliable one week into development than UDD can ever be) [15:49] dobey: kenvandine: i had to resort at times getting packaging fixes merged into trunk, cherrypicking & uploading into distro, and then merging back the "cherrypick" debian/changelog entry to keep everything in "sync" [15:50] xnox, yeah, there are quite a few cases where this is necessary [15:51] dobey: kenvandine: in this sense dgit rules, as it's a hard requirement for dgit/trusty branch match the archive. And then one is free to stage any amount of branches and one gets the hand over the trigger which sets of changes to simultaniously push to central repository as dgit/trusty branch with a matching dput into the archive. === gatox is now known as gatox_lunch [15:53] and still not relevant to whether something should be a native package, or use split mode in bzr-bd [16:04] sergiusens, here's a build from scratch (on raring): http://s-jenkins.ubuntu-ci:8080/job/ubuntu-touch-image-builder/15/console [16:04] sergiusens, still failed with the vmlinuz problem [16:05] fginther, don't know how your sync is fetching the ubuntu/prebuilts/* [16:06] did a sync from scratch this morning and didn't get that pulled in === cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [16:07] fginther, oh, it's just cloned, but not added; was chsing the wrong thing [16:32] dobey: split mode is mandatory for the whole system to work [16:32] dobey: as we already talked about before holidays [16:32] dobey: vcs-bzr is to be nice for other packagers, but I don't really care [16:32] dobey: I hate wrap-and-sort, but that's a personal taste, it's not a blocker [16:34] dobey: but following the same guidelines everywhere help when other touches other packages [16:34] are the mergers not merging? [16:34] didrocks: i thought native would be fine? if native doesn't work that seems like a bug in the system (the stuff that deals with the the versioning) [16:36] dobey: can counted as a bug, but nobody is going to change that AFAIK [16:37] dobey: as some people want to have upstream tarballs for other distros [16:37] didrocks: i certainly agree on that last one, but i don't think doing things consistently wrong is good, even if it is consistent and easy. and i think split mode is wrong. [16:37] dobey: so right now, following the same for everyone is better [16:37] didrocks: i wouldn't say it's better. i'd say it's consistent [16:37] dobey, consistent == better :) [16:37] dobey: it's not wrong, some people may argue that they don't want to publish native natives [16:38] well s/may argue/were arguing/ [16:40] didrocks: arguing that one wants to have tarballs for release on other distros doesn't make split mode correct. "correct" would be to have debin/ not be in tree in those case, or to at the very least fix the system to create proper upstream tarballs and not use split mode as a way to get that. yeah, it works, but it's still not "correct" :) [16:41] dobey: it's consistent at least and part of our requirements === gatox_lunch is now known as gatox [16:47] need to get lunch, bbiab [16:50] Laney: the upstream merger is disabled for system-settings as I requested it. You are part of "THE" prototype :) [16:50] O_O [16:59] * ogra_ hands Laney some salad and other guineapig food [17:00] * Laney hides under ogra_'s sofa [17:00] * ogra_ sends the cat [17:01] /nick pinocchio [17:01] heh [17:01] didrocks: what does this mean for us? :-) [17:03] Laney: see ubuntu-phone mailing list =))))) you get to land your own stuff. [17:03] Laney: you're screwed! :) [17:03] :-D [17:03] Laney: more seriously, in a call, will tell you afterwards :) [17:03] Laney: invoking ogra was a good move ;-) [17:04] while(true) ogra(); [17:04] hah [17:13] Laney: Ooh, showing off C99 skillz ;-) [17:23] didrocks, i thought you guys use the UI for image builds now [17:28] ogra_: oh, we do [17:28] but holidays… ;) [17:28] ogra_: want me to do it? [17:29] ogra_: not having feedback isn't really great though [17:29] (in the UI) [17:29] didrocks, yeah, agreed, someone should improve it [17:29] ogra_: did you poke it or should I? [17:30] go ahead [17:30] ok doing :) [17:30] ogra_: for promotion, you are still in line though ;) [17:31] yeah, np [17:31] build 117 requested [17:32] Laney: so, yeah, you will be in the pilot program :) [17:32] Laney: did you read asac's email on the phone ML? [17:34] yes I've seen it and the slides [17:34] but it talks about setting up checklists and stuff which I don't think we did [17:34] Laney: yeah, we are trying the landing part for now [17:34] Laney, in summary they want to stop automerging to trunk for approved mps, but have a "coordinator" picking branches to land and making a mp with those, throwing that to a ppa (using a tool provided by CI), testing the result and acking through the tool === davmor2_ is now known as davmor2 === balloons_ is now known as balloons [17:35] I see [17:35] then that "set" would land in distro and be merged back in trunk [17:35] we need to open the publication to core-dev btw [17:35] so that for core-dev, there is no more landing team involved at all [17:35] nice [17:35] the meeting thing would probably put me off :P [17:36] anyway, hope it all works === bfiller is now known as bfiller_afk [17:45] Laney: it works on my machine, is that enough? :p [17:46] sounds like the gold standard to me [17:46] ship that bad boy [17:46] \o/ [17:50] Laney: those checklists are TODOs for engineering teams [17:51] Laney: so you should self-impose what you want to do... as long as there is something reasonable you qualify for doing landings on your own === kalikiana__ is now known as kalikiana_ [17:51] the checklist and testplan will then be improved as we go === balloons is now known as Guest99854 [18:07] === image 116 promoted === === alan_g is now known as alan_g|EOD === balloons_ is now known as balloons [18:20] ping doanac :-) Can you by chance re-run a merge job for me? It looks rather suspicious [18:20] https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906 [18:21] balloons: looking now [18:25] cihelp: can someone please do a rebuild of http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/564/rebuild ? the job results links in the MP comment are giving 404s :( [18:26] dobey: looking [18:26] dobey, that job has been purged, do you have the MP or something that triggered it? [18:27] fginther: https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/+merge/195729 [18:28] dobey, that'll work. [18:28] thanks. just want to see why the builds failed, but 404s don't tell me much :) [18:31] balloons: http://s-jenkins:8080/job/ubuntu-ui-toolkit-autolanding/543/console [18:31] bah, I lost my vpn setup.. grr [18:31] doanac, what's it say? [18:32] balloons: its just running now. i'll let you know [18:32] kk === _bjf is now known as bjf [18:46] dobey: your job was retriggered about 10 minutes ago. I'll let you know how it goes: http://s-jenkins:8080/job/ubuntu-system-settings-ci/571/console [18:46] dobey: oops - already failed: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-trusty-amd64-ci/87/console [18:47] thanks [18:58] kenvandine: can you try to trigger an ubuntu-purchase-service build into the daily ppa again now? [19:08] dobey, did you guys work out the packaging? [19:08] we need it split mode to let it get published [19:12] no. i'd like to see if it's going to give the same error though. it was in "split mode" yesterday. now it isn't. [19:17] balloons, can you approve https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906? The tests pass, but it can't merge without being approved (and I don't have permission) [19:26] http://paste.ubuntu.com/6710757/ [19:26] pile of MP for all the out of sync packages [19:26] if anyone wants to help review them :) [19:31] dobey, ok, let me kick off a build [19:31] fginther, I too don't have superpowers for that one [19:32] robru, have you proposed a branch to bring the packaging inline with our practices? [19:33] kenvandine: he has not [19:34] http://paste.ubuntu.com/6710796/ [19:34] dobey, same failure [19:34] dobey, i bet because it has a native package version :) [19:34] * kenvandine ducks [19:34] kenvandine: i bet because the cupstream2distro code is broken :) [19:35] * kenvandine whistles [19:35] anyway... i gotta run to lunch [19:35] robru, don't forget to throw that packaging back to dobey :) [19:36] * kenvandine runs [19:41] lol [19:41] wrap-and-sort -a -s -t might be ok [19:42] but just -a -t is annoying :) [19:58] how does one run the tests in cupstream2distro? [20:06] because trial tests/ is a whole bunch of fail === bfiller_afk is now known as bfiller [20:19] anyone? i've tried trial and python -m testtools.run discover, both to no avail [20:20] dobey, didrocks would be best to ask about that, i've never run them personally [20:54] dobey, "autopilot run tests" works for cupstream2distro [20:54] dobey, I do get 7 failures out of 216 tests [20:55] dobey, as does "nosetests tests" [20:56] nosetests ran 253 tests [20:57] huh [20:57] autopilot seems a bit weird to use there [21:01] dobey, indeed. nosetests had better results as well [21:07] i wonder why trial was all failures though. === doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [21:28] whee, that wasn't so hard to fix [21:30] kenvandine: https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736 just for you :D [21:31] ha... "fix" [21:31] i'll let didrocks have that one [21:31] :-D === Ursinha is now known as Guest50378 [22:01] fginther: is it possible to make upstream-merger & daily release et al use a branch other than lp:autopilot when releasing? Would this piss anyone off? [22:01] reason being: you can't set the LP development focus to something other than trunk (which actually makes sense) [22:01] but it means we're being forced to release from a branch that's unstable, which is causing us grief [22:02] thomi: hm, mir started a new series devel, and actual _new_ development happens on lp:mir/devel or some such. with lp:mir actually being stable and matching ppas / distro / etc. [22:02] xnox: yeah, but you can't set it as a development focus, so by default all new MPs point to trunk [22:02] thomi: similar strategies are used, by e.g. launchpad engenerring. Were scary new stuff goes to lp:lp/db-devel, and lp:lp is actually that get's deployed. [22:02] thomi, so you want something like lp:autopilot/release and daily release operating on that? that's do-able. No one should have an issue with that [22:02] thomi: yeah, that does suck. [22:03] fginther: if I make the series, are you able to take care of updating everyone / everything? [22:03] thomi, yes [22:04] fginther: lp:autopilot/1.4 :) [22:05] thomi: you can set the development focus to any series you want. but lp:project always points to the development focus (it doesn't have to be trunk) [22:05] dobey: right [22:06] dobey: My wording may have been vague [22:06] when I say "trunk", I mean "lp:projectname", not a series that happens to be called 'trunk' - but I admit that's probably wrong [22:06] yes, it is :) [22:07] my "beef", if you will is that by default we're releasing stuff from the lp:projectname branch (i.e.- development focus), which is also the default target for all new MPs [22:08] which, combined with submissions from a large group of people, makes it very hard to keep a stable & development branch pair [22:09] fginther: I'll CC you in an email... one second [22:21] thomi, you still want automerger on lp:autopilot, rigth? [22:22] fginther: yes please [22:22] fginther: is that what we're calling it these days? [22:22] I want to get my terminology right :) [22:22] thomi, yeah, autolanding isn't really the right term to use [22:23] I thought it was 'upstream-merger'? [22:23] that works too [22:23] thomi: understandable. i'd say if trunk is unstable, there are other problems though. but i do miss the days of having control over releases and getting packages into ubuntu, and basically following the ubuntu release processes. :) === Ursinha-afk is now known as Ursinha [22:24] dobey: well, so you can make trunk stable to a point, but I don't believe you can make it release-quality 100% of the time without affecting development velocity [22:24] at least, not when you're being held to a 'zero bugs released to distro' policy [22:24] thomi: i disagree, but no point arguing about it [22:25] zero bugs released to distro policy is just nonsense. you're going to release bugs, whether you know they exist or not. :) [22:25] well, I'd be interested to know what we could/should be doing differently :) [22:25] dobey: I *totally* agree there [22:26] dobey: but several other people don't agree with us on that point :) [22:27] well, i don't know what you're doing exactly now. i just think that if you feel trunk isn't release-worthy all the time, then there are probably other issues causing it, such as poor review practices, not having enough tests being run during merge, etc… i couldn't say exactly without knowing why you think it's not release worthy, beyond the inherent fear of releasing from trunk that is built into being a developer :) [22:29] dobey: ok, so I think we're actually saying the same thing. The problem here is that "release worthy" for our project is a mugh higher bar than for most others, so we need to take additional steps before releasing to distro [22:29] i think you're understemating the bar that others set, a bit :) [22:30] you can release trunk to distro just fine if you accept that some bugs are going to slip through [22:30] no amount of code reviews / automated testing etc. will catch everything [22:31] s/trunk// there :) [22:31] so we just need an extra step, is all, which sadly takes some time [22:31] heh [22:32] well, yes, I'm sure you can never get to 0 bugs, but you can do better than we do at the moment anyway [22:34] right. i'm saying "do better" doesn't necessarily manually cherry picking things into a stable branch and doing releases from there. i'd say it would be to identify the issues that make releasing directly from trunk untenable, and solving them. [22:37] dobey: I see. The main issue for us is that catching regressions takes time, and in the meantime we can't land any new features. I suppose we could all, as a team, stop new development and stabilise one release, then move on... maybe we'll try that next time [22:38] anyway, this is an experiment, we'll see how it goes, and maybe try something different next time [22:38] right. like i said, i dodn't know what all the issues for you are. extraneous new feature development can certainly cause problems :) [22:40] yeah [22:43] anyway, time for me to get off of here. have a good evening [22:56] thomi, https://code.launchpad.net/~fginther/cupstream2distro-config/autopilot-release/+merge/200745 [22:58] fginther: ummm, ok, I don't really have the experience to be able to review it, but thanks for your help :) [22:58]