[05:06] vila: I didn't get your 'why not a regular MP', when I was suggesting to disable the radeon from the config. you should do the merge proposal against the config but you need to deploy the change regardless of the bzr change. [05:08] josepht: I don't think you need me to check whether something is running on radeon.. for jobs I guess it's ok if it's still deployed, just look it's idle at http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/? and if you need it for investigations, remove it from the lp:cupstream2distro-config first. [06:31] Mirv: because I found it weird that you didn't file the MP. There are enough things that are not (yet!) under version control and are therefore hard to track, to add confusion by not using version control for stuff that is already using it ;) [06:31] Mirv: now, what about: [06:31] Mirv: 'long annoying detail of the next job breaking after abort' as in this problem has been know ? Since when ? [06:34] vila: I didn't file a MP because I left it for you to decide whether the problems can be solved or if the radeon machine needs to be taken off from rthe grid [06:34] I just thought that if you need the diff, I'll offer it [06:35] vila: that problem of error-after-abort has been seen before, but just not fixed. not really sure when it was first noticed. [06:37] Mirv: ack, then I've good news, expect it to soon be a thing of the past: http://q-jenkins.ubuntu-ci:8080/job/otto-test-radeon/label=qa-radeon-7750/61/console [06:37] Mirv: I'm not fully awake yet and have an urgent dentist appointment to attend 1h30 from now [06:38] vila: nice! [06:38] Mirv: I'll check where this fix need to be deployed then [06:38] vila: ok, have "fun" there [06:43] Mirv: and then I think we need to discuss how to interact around this kind of issues, otto node provisioning is too complex to handle given the occurrence of these incidents. Who is responsible for them is unclear, I think you'll be better served if you could manage them yourself but at the same time there are cases where the ci team need to take control. I don't think this case was one of them. [06:44] ok [06:44] Mirv: so for the next hours, don't abort jobs ;) But lower the timeout ? [06:46] Mirv: or as a really dirty trick, if you get stuck, run the job I pointed above, it will stop the container [06:49] ok, testing running something then using the test job if needed [07:21] Mirv, vila OOC, why do you need to abort jobs? [07:32] jibel: Mirv needs to when they are stuck and the timeout is too long for him, hence the advice to reduce it (dunno who set it to 330 mins...) [07:46] vila, but why are they stuck? It usually means something went wrong isn't it? [07:52] jibel: AFAIK in this case, the Xserver inside the container crashed, and I think aborting is the wrong idea as it means the Xorg.0.log file is not collected which means Mirv can't provide it upstream [07:52] * vila dentist & [07:53] vila, ah, okay, maybe this condition could be checked in the runner and exit when X dies as there is no point in running tests without it [07:58] vila, and I agree 330min is a very long timeout, it used to be 2hours because unity testsuite takes 90min [08:05] IIRC, it was extended for the Mir guys to debug without needing us to prevent the timeout, I guess it can go back to 2h + the fix jibel mentionned about detecting X [08:22] didrocks, vila on the testbed you could run in background something like "while sleep 60; do pidof X || do_something_to_terminate_cleanly; done" [08:22] yeah [08:22] or a more elaborate version of that of couse :) [08:23] well I'm confirming the radeon still breaks, so I'll now remove its usage from config [08:24] jibel, didrocks: right, tests should check for X and fail otherwise. That's a more specific fix that the one I'm investigating right now which is: something went wrong, clean the place. And I want that later one in place in any case as it will catch other, yet unknown, failures. [08:24] (http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/576/console - X.org probably crashed if one would look at the logs) [08:27] Mirv, didrocks: now I'd like to understand what your policy is regarding otto nodes availability. -nvidia absence was a blocker, now qa-radeon presence is a blocker [08:28] going with the logic that -nvidia was a blocker as specific failures won't be caught, it seems to me that -radeon should be kept especially when it's not failing for all suites [08:28] https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/remove_qa-radeon-7750/+merge/196494 [08:29] vila: we would need all three to be functional in order to get really trustworthy results, also in case one of them breaks we don't want it to be the last one. but having a broken machine enabled blocks more than having 2/3 working. [08:30] vila: if there'd be a list of stacks it works at every time, then it could be enabled selectively of course. but the crashes might be random too. [08:30] vila: I mean I want at least 2 [08:30] vila: one isn't enough [08:30] I proposed now https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/remove_qa-radeon-7750/+merge/196494 which would remove radeon from all of the stacks for now [08:31] Mirv: good, that's what I thought for -nvidia so happy to see some convergence there [08:33] Mirv: 'random crashes' indeed is what this catch-all fix is about, needs a bit of refinement as it assumes there is a single container running (and I want a clear error message otherwise) [08:34] Mirv, didrocks: only autopilot-*-daily_release jobs ever run otto tests right ? [08:34] vila: I guess there is another one that jibel put in place for community apps ^ [08:34] didrocks: on q-jenkins ? [08:35] IIRC, yeah [08:35] didrocks: ack, thanks, I'll followup with fginther about that then [08:35] vila, that was a project to run autopilot tests of desktop application written by the community, but since the move to a queternourly release, there are no slot available anymore to run them [08:35] thanks [08:35] I'll move that to VMs and hand it over to CI [08:41] hioh, since you mention VMs, sorry, never found the time to get back to you about 'vga ??? not supported' remark you made when I talked about pass through [08:42] jibel: I'm not sure we're on the same page there, to me, pass through refers to the feature where the host *ignores* the graphics card and let the kvm fully handles it (crashes included). Is that what you were referring to or something different ? [08:44] Mirv: timeout set to 120 for now but if you feel you're still wasting too much time, lower it again. [08:46] vila: ok, thanks. where it's set, I haven't known that? [08:47] Mirv: oh very very sorry, http://q-jenkins:8080/job/autopilot-trusty-daily_release/configure [08:48] Mirv: build environment / Absolute / Timeout minutes [08:49] ogra_: please, kick an image as soon as you can [08:51] Mirv: apologies, I shouldn't have assume you knew where that timeout was defined :-( Better repeat assumed knowledge rather giving incomplete hints :-( Painful for all involved in the end... [08:54] didrocks: about 'it was extended for the Mir guys to debug without needing us to prevent the timeout', as in: so they can access the otto node while the job was running/suspended but the container still accessible ? [08:55] vila: they had random races which prevented the session to start [08:55] vila: so yeah, they wanted to dive in when this happened [08:55] and most of the time, we noticed after 2 hours [08:55] so too late, nearly the end of the timeout [08:56] didrocks: ack, so in the longer term, we want to give them a way to reproduce that on a different otto node (ideally on *their* machine) so we don't have to interfer with production right ? [08:56] vila: exactly [08:57] vila: but as it's racy and hw dependant, we need a way to stress it to reproduce [08:57] with the same hw [08:58] didrocks: yeah, tricky balance to find... [09:01] didrocks: but let's start with a solution that preserve production and only fallback to de-provisioning as a last resort (not to mention the landing and ci teams need a lighter process than filing a MP, land it, deploy it) [09:01] vila: waiting eagerly on your patches :) [09:02] didrocks: priorities are 1) fixing 1ss move, 2) ci airline early target(s), 3) the rest AFAIU [09:03] didrocks: so stopping the container after the timeout sounds like the best trade-off in the short term [09:04] vila: I guess it's already what happens (stopping after the timeout) [09:04] just change the timeout to 2 hours [09:04] didrocks: and tuning the timeout to it slowest possible value should also give you faster feedback [09:04] didrocks: yes, that's why I say: don't abort ! [09:05] vila: it doesn't abort, it's stopping the container [09:05] didrocks: the issue is a container still running when the job is aborted and that happened several times in the last days no ? [09:06] vila: yeah, but that's not linked to the timeout [09:06] at least, not to: "vila | didrocks: so stopping the container after the timeout sounds like the best trade-off in the short term" [09:06] as I said, what you told just above is already done ^ [09:06] another issue is what you work from Friday if I understood correctly [09:06] didrocks: yes, but that assumes that nobody abort jobs [09:06] which is: [09:07] "if someone abort the jobs, shutdown the container" [09:07] (nothing to do with timeout) [09:07] didrocks: meh, the link between the timeout and somebody aborting the job is that if the timeout is short enough nobody *can* abort the job [09:08] vila: yeah, so just move the timeout to 2h [09:08] as we need 90 minutes for the unity7 tests [09:08] didrocks: already done [09:08] so, you're back to what we had initially [09:08] same functionality, same bugs :) [09:08] didrocks: can you guarantee that nobody will abort jobs ? If not I'd rather have a catch-all in place [09:09] vila: ok, so there is no link if you want to add the safety net [09:09] between the timeout and this "fix abort" case [09:10] didrocks: don't know how to explain it.... [09:11] didrocks: people have been aborting jobs [09:11] well, it's easy: [09:11] - the timeout was too long [09:11] vila, this "jenkins cannot kill tasks it doesn't own" has been there forever, and is not specific to release testing [09:11] -> just REVERT to 2h, no need for a week to discuss that, it was for a Mir race case, we didn't restore it, just do it… [09:11] (and discussion closed on that one) [09:11] - if someone aborts the job, we're screwed [09:12] -> yeah, valid one, known from the starts, we either decide to fix it or leave it alone [09:12] vila, so if you can fix it for every thing running in jenkins go ahead but it's orthogonal to the daily release IMO [09:12] jibel: thanks, didn't know if that was linked to 1ss move or not [09:12] no need to have discussions on those for days :) [09:13] didrocks: but I told you the timeout has been fixed, since you keep discussing I thought you had something else on your mind [09:13] vila: no, just "the other issue isn't really link if you want a real fix for it" === ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues [09:13] even if I understand we'll get it less, as we did at first [09:15] didrocks: right, so several potential fixes have been tried, discussed and agreement found, I came up with a new one yesterday evening and told Mirv this morning. I think that's where we stopped being on the same page ;) [09:15] I don't have the start of the discussion, what was the new potential fix proposal? [09:16] didrocks: I realize there are other fixes, better targeted, but they'll require more time. If you're fine with ensuring the jobs are not aborted anymore, I'm fine leaving that ticking bomb at peace for now. [09:17] Mirv: ack, then I've good news, expect it to soon be a thing of the past: http://q-jenkins.ubuntu-ci:8080/job/otto-test-radeon/label=qa-radeon-7750/61/console [09:18] vila: how can we ensure? [09:19] didrocks: ensure what ? that people won't abort jobs or that we'll stop the container if they do ? [09:19] vila: I don't know, just repeating your "If you're fine with ensuring the jobs are not aborted anymore" -> how do you do that? [09:20] didrocks: that's the question you didn't answer ;) [09:20] didrocks: can you guarantee that nobody will abort jobs ? If not I'd rather have a catch-all in place [09:21] vila: well, it's a rethorical question I guess… the answer is obvisouly no [09:21] vila: so, you are going to work on a fix? [09:22] didrocks: look at that url above and you'll find a crude fix in the post build part of the job which I need to refine slightly [09:23] vila: not sure what that means, apart that you detect a container running [09:27] didrocks: that's the two encountered cases where a job can't run because the previous one was aborted. [09:28] didrocks: or rather, one is when the previous one was aborted, the other is when the current job has started a container and *may* have left it running [09:28] vila: ok [09:30] Joining in a moment [09:33] Damn, hangouts is taking ages today... some plugin problems [09:35] Ok, getting really irritated here [09:37] === Image r29 building === [09:38] Now I have no video from anyone [09:51] so, radeon was still running after deploying config changes. let's see if it helps now that I removed it also from the daily_release job [09:55] jibel: I just closed our task tracking drude and rabisu. Can you confirm that they're working as expected? [09:55] (closed because I can confirm they're up) [09:55] ok everyone FYI, now it should be finally possible to run stacks sanely again and even get autopilot results [10:13] ev, they're working. I reopened the RT because FW rules are incorrect. [10:14] ev, I fixed the problem with the publisher, it is due to an incompatibility in matrix jobs configurations between 1.424 (version before the move) and 1.480, I added info on asana so Larry can notify other people using matrix jobs on d-jenkins [10:15] 1.424, 1.480 = versions of jenkins [10:15] ev, and there is still a ticket open fo the scheduler not working on d-jenkins [10:16] ev, but I think it's a bug in jenkins when a request for shutdown is cancelled and can only be fixed with a restart [10:17] jibel: awesome, thank you for all of that! [10:49] ev, hey, seems the otto runner is b0rked somehow https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/957/console [10:50] ev, twice today it complained about being unable to start the lxc container [10:51] === image r29 DONE === [10:54] otp for another 30-45min [11:09] wow, when did we add the sound of a 1920's typewriter to the keyboard? [11:22] didrocks: RSS Reader is working mostly fine, found a bug and filed it, File manager seems to be an AP issue, most issues relating to pop overs. [11:23] popey: ok, keep me posting on all other discoveries :) [11:23] thanks ;) [11:23] will do [11:23] http://popey.com/~alan/phablet/device-2013-11-25-112323.png is fun [11:23] phone got stuck between two scopes [11:26] ^ vila is the problem Saviq is experiencing further fallout from what we just discussed on the phone? [11:27] popey, unity8 crashed? [11:27] no [11:27] it just got wedged a bit when I searched in the home then while results returned I swiped across [11:28] after I took that pick I swiped and it locked on to the scope fine [11:28] popey, if you can reproduce, please bug [11:28] s/pick/pic/ [11:28] yeah, trying [11:48] ev: not exactly and this one seems to be s-jenkins, not q-jenkins [11:48] oh right [11:48] * ev digs === MacSlow is now known as MacSlow|lunch [12:07] Saviq: managed to do it again, not quite sure how, will file a bug [12:10] Saviq: bug 1254693 [12:10] bug 1254693 in Unity 8 "Unity sometimes gets stuck between two scopes" [Undecided,New] https://launchpad.net/bugs/1254693 [12:10] Saviq: lemme know if you need any logs off the phone [12:13] popey, logs likely won't help, steps to reproduce would be good if you find them [13:05] xnox, did you happen to test the libc6 changes on touch ? (my client disconnected, havent seen the outcome of the conversation on the weekend) [13:07] ogra_: no i did not. plus i don't have mako/maguro. [13:07] xnox, grouper is a target this cycle ;) [13:07] ok, then i'll do that testing later today [13:14] so what was again the status with the unity8 problem? [13:14] (crasher) [13:15] I'm wondering whether I could push the mir builds to the PPA or if unity8 needs to be built still which would pull unwanted dependencies in case I'd push for mir [13:16] either way I can probably work on mir tomorrow morning before the meeting === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues === alan_g is now known as alan_g|lunch [13:23] Mirv: oh, you didn't release Mir yet? [13:27] didrocks: nope, not enough time for today unfortunately to run all the tests anyhow. I'm just thinking whether there was any problem in preparing the PPA now so that I can run tests tomorrow morning. [13:28] didrocks: and I almost forgot the publish button! Can you ACK a packaging change? http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot_1.4+14.04.20131125-0ubuntu1.diff [13:29] didrocks, Mirv: catch-all to stop containers on aborted jobs is now in place for http://q-jenkins:8080/job/autopilot-trusty-daily_release/ [13:29] Mirv: good for me to prepare the ppa [13:30] vila: great! [13:30] didrocks: thanks. one more thing, is this current manual stack run intentional and is it planned to change now that I disabled radeon again? [13:30] (ie build_all disabled) [13:30] sil2100: +1 [13:30] Mirv: you can enable it again I guess [13:31] ok, enabling === MacSlow|lunch is now known as MacSlow [13:32] updated the stack status page as well [13:44] thanks Mirv! [13:57] morning [13:59] hey fginther [13:59] didrocks, morning [14:03] didrocks, lool: do i need to do a landing ask to add a pkg-config file to a -dev package as well, for a source that has some binaries on the touch image? (the -dev package itself isn't on the image of course, and the other binary packages will not be changed) [14:06] dobey: if nothing else change and you test a rebuild didn't bring anything/change anything, please go ahead [14:06] ok, great. thanks [14:23] vila: ddeb -> package containing debug symbols, currently hosted on ddebs.ubuntu.com [14:23] we strip those off executables automatically during build [14:23] apport-retrace makes use of them when people upload crash reports containing core dumps [14:24] or people can run apport-retrace manually to diagnose issues, or even install the ddebs directly [14:24] cjwatson: oh ! debug debs, why are they involved for ci ? [14:24] because we're copying packages into the primary archive, and therefore ideally need to make sure ddebs are available for those copied binaries [14:25] unfortunately ddebs are implemented with a giant hack on the backend right now so that's tricky [14:25] the work to fix that has been planned for a while and about 90% implemented [14:25] I think it's currently blocked on moving the librarian to swift [14:25] cjwatson: oooh, so you want to make sure debs are not blindly copied without their ddeb ? [14:26] right, and also: ddebs need to be created in the first place [14:26] which can only be done while building the debs [14:26] cjwatson: right, ok [14:26] wgrant has done a good deal of work on the copy logic etc. [14:27] ev, any word on the failing containers? [14:27] ^ josepht should be able to update you [14:27] ev, thanks [14:28] Saviq: I'm still looking at it. It seems jenkins has a gnome-session open but I haven't tracked down exactly why yet. [14:29] didrocks: calendar app failing in #29, run tests locally and it fails here too, but the app itself works. so probably ap issue. [14:29] josepht, thanks [14:30] paging balloons.. http://ci.ubuntu.com/smokeng/trusty/touch/mako/29:20131125:20131125/5091/calendar-app-autopilot/ - these failures. can someone take a look at them? Do you need a bug filed? === alan_g|lunch is now known as alan_g [14:40] popey: tell him "no thanksgiving for you if not fixed by TOMORROW" ;) [14:41] hah [14:41] popey: I heard there is one every year, they can get into next year one :) [14:42] they have way too many holidays [14:42] as do you lot! [14:42] * popey lumps "europeans" together [14:42] * popey is of course just jealous ㋛ [14:47] popey, [14:47] popey, https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-new-event-test/+merge/195421 [14:47] it was fixed last week [14:47] needs to get pushed to the images [14:48] probably end up with a whole sleuth of stuff to push in again [14:48] good stuff [14:48] will poke sergio when he is around [14:48] * popey hugs balloons [14:49] * balloons peeks and sees what else isn't landed [14:55] Saviq: it looks like it was a gpu lockup [14:56] josepht, ok, will try to kick a job [14:56] balloons: lets get the full list of things that need updating and I'll test them for sergio so we can get them in the next image [14:57] Saviq: wait, I think I'll need to have someone kick the machine first :) [14:57] rfowler: ping [14:57] josepht, ok [15:11] balloons: can you check with sergio maybe about those? [15:11] didrocks, yes, popey and I will work with sergio and land stuff :-) [15:12] balloons: can you tell me once it's done? (even by email) [15:12] popey rejected the fixes last time :-) [15:12] so that I know what we can expect in the next images [15:12] didrocks, sure, I'll email [15:12] bad bad popey! [15:12] ;) [15:12] thanks [15:13] ogra_: so, I discussed with asac, and he agrees on the "promote now" [15:13] ok [15:14] ogra_: is everything good from your perspective on image 28? [15:14] just wanted to make sure we dont bypass him [15:14] ogra_: yeah, talk to various people and they agree I can tell the decision in the future, but let's see as well if asac agrees once back [15:14] ogra_: let's way for final popey's feedback then and publish if ok [15:14] wait* [15:18] didrocks, hmm, the indicators dont actually match the icons ... if i switch to bluetooth in the indicator header, the messaging icon is highlighted [15:19] ogra_: can you file that as a bug? [15:19] seems the caption odering doesnt match the icon odering here [15:19] I saw that in the old days already [15:19] functionally it seems to be ok though [15:19] but couldn't reproduce it reliably [15:19] so maybe just a race [15:20] * ogra_ reboots the phone to see if it is still there afterwards [15:20] ogra_: yeah, if now it happens 100% of the time, I would see that as an improvement (relatively speaking :p) [15:21] but at least, we'll have a way to fix it more easily ;) [15:21] definitely reliable [15:21] it's weird, but I would "\o/" [15:21] see #ubuntu-touch [15:21] seems there is even already a bug [15:22] ok, nice! at least, we'll be able to kill it definitively :) [15:25] didrocks: 28 is okay from my perspective [15:26] popey: great! [15:26] same here [15:26] ogra_: please promote, I have an email ready (just need popey to ack it, it's a little bit special and I want to have it right ;)) [15:26] rfowler: unping [15:27] Saviq: okay, you are clear to kick a job [15:27] josepht, thanks [15:28] ogra_, didrocks, do you monitor regression bugs whenever checking if a image is good to go or not? The bugs I filed were tagged regression [15:28] Ursinha: I monitor with tabs [15:28] including the indicator bug [15:29] === Image r28 PROMOTED === [15:30] \o/ [15:31] * didrocks sends email [15:31] Ursinha: I don't track the tags, but bugs directly TBH [15:31] is 28 better than the previous one, even with a few regressions? [15:32] in theory we don't want to promote something that we know that has regression [15:32] rsalveti, it a lot worse [15:32] *it's [15:32] then why did we promote it? [15:32] http://ci.ubuntu.com/smokeng/trusty/touch/ [15:32] image 10 was the last one ... [15:32] 28 was just promoted [15:33] right, but are you using it as your daily phone? [15:33] rsalveti, because people are starting to nag i guess [15:33] don't push images that are known to be broken [15:33] rsalveti: it's not worse, the test failures are false positives [15:33] it's a pita [15:33] Ursinha is using as her daily phone [15:33] didrocks, it is full of crashes [15:33] (or negatives) [15:33] ogra_: the crashes are on exit [15:33] didrocks, I found a couple regressions I filed, plus some I still need to file... [15:33] as discussde this morning [15:33] discussed [15:34] and I stopped counting the amount of times Ursinha complained that something stopped working [15:34] and 10 was indeed better [15:34] please, don't promote broken stuff [15:34] Ursinha: the indicator one was a race that happened before (in image 10), I'm not aware/no one mentionned other regressions before we promoted [15:34] did we? [15:34] rsalveti, thats why i asked for asac approval for it [15:34] and asac +1 on those premise [15:34] i didnt feel like promoting it [15:34] well, we all need to agree when to promote something [15:34] and not wait for asac to decide [15:35] rsalveti, clear statement was equal or better than 10 [15:35] right, and it's not equal, it's worse it seems [15:35] we didnt have any such image in the last two weeks [15:35] ogra_, if it has a regression can I consider it worse? [15:35] Ursinha, yes [15:35] ogra_, so........ [15:35] still, we don't want to break people dogfooding it [15:36] remember, we have people using dogfooding it [15:36] so, do you have a real list of regressions and why weren't they brought up there? [15:36] Ursinha, dont look at me ... i wouldnt hve promoted it ... we explicitly asked asac for approval [15:36] didrocks: are you using it as your daily phone? [15:36] rsalveti: I do use it [15:36] didrocks, that was my question :) I've been filing bugs and being careful enough to add the regression tag to it so they can be found [15:36] didrocks: with trusty? [15:36] if they're not, we need to do something about it, because depending on nagging people to have it looked at doesn't scale [15:36] Ursinha: do you have a link across launchpad, I told I'm tracking bugs that was up here [15:36] rsalveti: yep [15:37] and would you like to use/have new regressions? [15:37] rsalveti: but I'm using -proposed [15:37] or would you like to have a working phone? [15:37] right [15:37] didrocks, you can have a list of bugs tagged regression for a list of projects, if you need I can craft an script for you that does that [15:37] yeah, we need a list of regressions asap [15:37] rsalveti: again, a list please, all what I need [15:37] we shouldn't accept regressions [15:37] that's the only way to move forward [15:37] we can't consider all bugs tagged regression because that would bring lots of unrelated bugs, but we need to be sure that all the projects important to us are being checked for regression bugs [15:37] I can do that [15:38] from my experience, I just heard here about "the indicator one" that I can reproduce here [15:38] didrocks, exactly [15:38] which I saw before [15:38] Ursinha: dogfooding-regression? [15:38] but only once [15:38] so it seems a race becoming reliably failing [15:38] I was able to reproduce it with 28 [15:38] * ogra_ too [15:38] and we have a bug already, ogra_ as well [15:38] so why did we promote 28 hahah [15:38] didrocks, I'm trying to create a way of tagging all important bugs in a way no reported and confirmed bugs slip [15:39] rsalveti, it was there on 27 already [15:39] Ursinha: that would be excellent, so that we have a direct access on that list [15:39] * ogra_ admits he didnt test r27 ... the tst results looked so bad it didnt look worth it ... [15:39] (thugh r28 doesnt actually look much better) [15:39] * Ursinha kicks the hell out of ogra_ [15:40] but worse than 10 [15:40] *again*, popey confirmed the test results are false positives [15:40] yes [15:40] hmm? [15:40] he tried them manually, all after another [15:40] popey, its all your fault :P [15:40] #blamepopey [15:40] :) [15:40] didrocks, I can do that, only need to know the projects that are important to us that should be tracked [15:40] all projects and avengers wiki page and what else? [15:41] Ursinha: well, I guess everything in the phone, so it's a big list :) [15:41] from lihybris to Unity8 [15:41] or we need a metaproject [15:41] like affect phone [15:41] hmm [15:41] everything thats seeded [15:42] ogra_, touch or all images? [15:42] touch for us [15:42] we need 1) list of packages, 2) list of upstream projects [15:42] no idea if anyone actuvely looks at desktop regressions that way [15:42] there are bugs reported against the projects but not the packages in ubuntu [15:42] * ogra_ assumes desktop people know their packages OOTB [15:42] ogra_: it's always popey 's fault [15:42] Ursinha, that breaks our bug filing policy [15:43] the packages in desktop (and other teams) can be tracked by subscribing a team to them, you have the list of affected packages in that way [15:43] but as I said, not only packages need to be tracked, but also projects [15:43] ogra_, what's the bug filing policy? [15:43] Ursinha, bugs *need* to be filed against the ubunu packages ... preferably using ubuntu-bug ... filing them additionally against upstream projects is optionsl [15:43] *optional [15:43] well, we only need to track (from the touch perspective) the packaged affecting the touch seeds [15:44] ogra_, okay, so what's broken isn't the policy, but people that are filing bugs need to do that when filing bugs [15:44] we only care for the bugs in the ubuntu archive .. which means they nneed to be filed against the packages not the project [15:44] right [15:44] I'm only tracking what exists today, there are people that file bugs only against the upstream projects... [15:44] we need to work on disabling the bug tracking system for the upstream projects [15:44] and only use the package one [15:44] rsalveti: +1 [15:44] or [15:44] it all just brought confusion [15:44] rsalveti, well, not really ... [15:44] didrocks: just dput ubuntuone-credentials with the aforementioned .pc file addition; thanks [15:44] we need to tell people to file bugs against packages as well [15:45] dobey: yw, thanks to you! [15:45] Ursinha: that doesn't work reliably [15:45] rsalveti, upstream projects should still be able to use a bugtracker for i.e. wishlist bugs etc [15:45] people we then depend on people :-) [15:45] rsalveti, so you're suggesting people to file two bugs, one against upstream and another against the package? [15:45] ogra_: right, if they want, sure [15:45] Ursinha, s/as well// [15:45] that's what I'm saying, launchpad happily supports that already [15:45] ogra_: but I believe we can disable most of them (for the ones we are the upstream) [15:46] as we want trunk to always be reflected in the distro [15:46] * ogra_ is sure asac wrote a mail about bug filing policies [15:46]