| ppisati | morgen * | 07:39 |
|---|---|---|
| * apw peers blearily out on the world | 07:44 | |
| jk- | hey apw | 07:45 |
| jk- | and hello ppisati | 07:45 |
| apw | jk0 heya | 07:45 |
| ppisati | hey | 07:50 |
| apw | cnd, hey! | 08:49 |
| cnd | howdy! | 08:50 |
| cking | cnd, welcome to sunny UK | 09:28 |
| cnd | cking, thanks :) | 09:36 |
| cnd | weather seems nice here | 09:36 |
| cking | it's unbelievable warm for the time of year at the moment | 09:37 |
| cking | unbelievably even | 09:37 |
| cnd | heh | 09:37 |
| diwic | Sweden's so cold Facebook's planning it's next facility in northmost Sweden. :-) | 10:26 |
| diwic | cking, but currently I share your analysis, it's quite warm here as well. | 10:27 |
| diwic | s/it's/its | 10:27 |
| cking | heh | 10:36 |
| cking | apw, I fakeroot doesn't seem to exist on tangerine's oneiric chroots - am I going mad, or has somebody removed it recently? | 10:39 |
| apw | cking, checking | 10:42 |
| cking | methinks apw is installing it now for me | 10:45 |
| apw | heh whyso ? | 10:45 |
| cking | it's now working for me | 10:45 |
| apw | really now that is odd | 10:46 |
| cking | you messing with my mind? ;-) | 10:46 |
| apw | not for me | 10:46 |
| cking | I could never get the hang of mondays | 10:47 |
| apw | Picking 'linux-meta' as source package instead of 'linux' | 10:52 |
| apw | wtf ... why would you do that | 10:52 |
| apw | something is very wrong with pretty much everything to do with the chroot creation, i am applying some hammers | 10:54 |
| apw | bah, the damn arm cross tools again, are uninstallable | 10:58 |
| cking | a stick of TNT may be more appropriate | 10:58 |
| cking | doesn't anyone check this kind of stutff? | 10:58 |
| * ppisati -> reboot in Oneiric | 11:02 | |
| diwic | apw, any idea of how we are from 3.2 merge window opened? I think I read something about Linus taking a vacation, but not for how long...? | 11:43 |
| apw | diwic, no more specific information than you suggested, we would expect a release 'now' really | 11:50 |
| apw | then i'd expect the merge window the next week | 11:50 |
| diwic | apw, ok | 11:50 |
| apw | if he vacs then yes he often shoves it in the gap, and we wait a little longer, but not much more | 11:51 |
| diwic | how long does he go for vacation usually? | 11:51 |
| cking | depends if he goes diving and runs out of oxygen | 11:52 |
| apw | a week normally | 11:52 |
| diwic | apw, so I good guess would be release this week, next week vacation, week after that would be merge window? | 11:53 |
| apw | yeah, he may have a longer merge window with his vac in it too, thats happened before | 11:56 |
| apw | but, anything not already in a maintainers tree by now, isn't likely to make it unless its a bugfix | 11:56 |
| diwic | but merging new features would then be accepted by the end of the merge window as well, no strict "regressions only" stuff. | 11:57 |
| diwic | hrm ok | 11:58 |
| diwic | so this practically leaves me ~1 day to finish off all new kernel features for 12.04. | 12:01 |
| apw | if we have 3.2 yes probabally, it is hard to know which will actually be in the release this early | 12:10 |
| apw | it depends more on external factors than anything else | 12:10 |
| brendand | sconklin - is the maverick kernel getting respun? | 14:01 |
| * ogasawara back in 20 | 14:06 | |
| sconklin | brendand, probably not, I think that failure turned out not to be a kernel problem. | 14:11 |
| brendand | sconklin - aha. should we go ahead with cert testing then? | 14:15 |
| brendand | sconklin - i'll get hggdh to update the bug | 14:16 |
| sconklin | Not until The QA status is definitively decided. I think hggdh said it was ok, but the task status and tag should be set to PASS if it is | 14:16 |
| hggdh | sconklin, brendand: if you are talking about bug 854092 then it is a pass from QA -- problem is at AWS | 14:21 |
| ubot2 | Launchpad bug 854092 in kernel-sru-workflow/certification-testing "linux: 2.6.35-30.60 -proposed tracker" [Undecided,Confirmed] https://launchpad.net/bugs/854092 | 14:21 |
| sconklin | hggdh, then in order to proceed, the tag has to be changed from a fail to a pass | 14:22 |
| hggdh | just did it | 14:23 |
| apw | (preferably with an expplanation in the bug as to why its ok to switch it) | 14:23 |
| hggdh | but I think this pass override should come from whoever worked on the bug, not me. In this case smb and I worked on it, so I was fully aware. But generically, an override should come from elsewhere | 14:24 |
| herton | hggdh: hardy was also tagged as failed, problem in the same test as maverick, is it also the same issue? | 14:36 |
| apw | smb is off today so he won't be commenting .... | 14:40 |
| hggdh | herton: indeed | 14:42 |
| hggdh | herton: tagged -passed | 14:45 |
| herton | ok thanks | 14:45 |
| hggdh | sconklin: we need to work out this retagging | 14:46 |
| hggdh | (in general) | 14:46 |
| sconklin | hggdh, I agree, it should be set to pass by whoever 'makes the decision', in this case smb | 14:56 |
| hggdh | sconklin: thank you. In this case, I explicitly asked smb about it, so we are cool | 14:57 |
| bjf | sconklin, not sure i entirely agree with that, QA "ownes" that stage so it should be they that makes any changes regarding it | 14:58 |
| bjf | sconklin, my thinking in this case is that smb, makes the case to hggdh that it should pass and hggdh should set the state and reset the tag | 14:58 |
| hggdh | bjf: QA owns the test, and takes a decision based on the test results. Once a bug is opened, the subject matter experts can decide | 14:58 |
| hggdh | bjf: this would be an override. Overrides are signed by whoever decides | 14:59 |
| sconklin | bjf, that was indeed my original thinking on this, that no one outside of the assigned team should be changing status or tags. | 14:59 |
| bjf | sconklin, that is my beliefe | 15:00 |
| sconklin | Because responsibility should now be delegated outside the assignee.. I think this needs further discussion so that we're all in agreement with whatever we decide to do. | 15:00 |
| sconklin | another problem is that almost any case where an override is required is going to be vaguely defined and impossible to anticipate in our process documentation | 15:01 |
| bjf | sconklin, i don't think that delegation of responsibility should be part of the process | 15:02 |
| hggdh | we really need to figure this out. This is not delegation, but override; an entirely different beast | 15:02 |
| sconklin | but we can not determine a priori who should have the ability to make an override. | 15:03 |
| sconklin | I do see bjf's point | 15:03 |
| hggdh | there is that. We can simplify by requiring the subject matter expert to formally add an entry in the bug; what I do not like is QA taking the decision without visible reason | 15:04 |
| hggdh | so the final decision will be from whoever owns the task | 15:05 |
| hggdh | but this should be made clear. | 15:06 |
| hggdh | In other words: explanation of why the decision can be overriden comes from the subject matter experts; final decision from the step/task owner | 15:06 |
| hggdh | (this actually applies to any SRU, not only kernel) | 15:07 |
| * apw thinks that sounds about right, we have to convince you, if we cannot do that you do not change | 15:09 | |
| sconklin | I think that sounds right. So ultimately it is the responsibility of the asignee to complete that task, by involving subject experts as required | 15:12 |
| apw | to look at it the other way round, it is qa's sign off, if they are signing off they had better be happy, if we want them to be happy we'll have to work at it :) | 15:13 |
| hggdh | this actually should be applied to all tasks, and for success or failure | 15:15 |
| hggdh | sconklin: er. Should we, then, *not* complete a task if there is doubt? Or should we fail, and then override if needed? | 15:16 |
| sconklin | https://github.com/sickill/git-dude looks handy, although I wonder if it won't lead to excessive fetches on upstream repos | 15:16 |
| sconklin | If the test fails, mark it a fail and open a bug. If the outcome turns out to be wrong (i.e. a success), then go back and change it. | 15:17 |
| hggdh | agreed | 15:18 |
| gema | hggdh: I don't think anyone but QA should be changing a test case from fail to pass | 16:06 |
| gema | as apw says, they should convince us :) | 16:07 |
| gema | sorry, I have come too late to the conversation, probably | 16:07 |
| hggdh | gema: I am not sure, but I accept the reasoning. And yes, I think you got in too late ;-) | 16:09 |
| gema | hggdh: normally when you have to change a test case from fail to pass there is more to it than that | 16:09 |
| gema | it is likely we'll have to do some follow up and add another test case or so | 16:09 |
| gema | I was just trying to understand the process based on the conversation | 16:10 |
| gema | not sure what changing from fail to pass means in this context, so don't mind me too much x) | 16:10 |
| apw | i think its important that a QA sign off is something QA stands behind, as that is where the QA 'veto' comes from, a no means no there | 16:10 |
| gema | apw: I agree, if I think it's a fail and you don't have a good reason why it is not a fail, I won't change it | 16:11 |
| gema | and you don't change just the result, I presume you change the condition that makes the test fail and re-run? | 16:12 |
| komputes | Does anyone see anything on this screen that might indicate why 64-bit won't boot on a Thinkpad X220? https://launchpadlibrarian.net/81019072/IMG_0749.JPG | 16:22 |
| komputes | Full bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/853085 | 16:22 |
| ubot2 | Launchpad bug 853085 in linux "general protection fault: 0000 [#1] SMP " [Undecided,Confirmed] | 16:22 |
| hggdh | gema: in this case, we were discussing a bug found while checking; the bug is outside the checking scope (but driven by it). | 16:23 |
| gema | hggdh: yep, I was looking at it now, thanks :) | 16:24 |
| hggdh | gema: further analysis on this (new) bug shows an issue outside the kernel -- so there is nothing to change in the test process (except now look for a new error condition) | 16:24 |
| gema | hggdh: I thought it was interesting to jump in because you were talking about agreeing on a process | 16:24 |
| gema | hggdh: so I wanted to understand the problem further | 16:24 |
| hggdh | k | 16:24 |
| gema | hggdh: understood, so the test case needs changing | 16:25 |
| gema | hggdh: I find pretty difficult to decide whether a test passes or fails with our current process | 16:25 |
| hggdh | actually, both the test conditions and the process | 16:25 |
| hggdh | gema: better we get back to #qa to discuss it | 16:26 |
| gema | hggdh: sure | 16:26 |
| tgardner | apw, gomeis/tangerine gcc-arm-linux-gnueabi in oneiric schroot | 17:39 |
| tgardner | installed in* | 17:39 |
| * tgardner -? lunch | 17:52 | |
| * jjohansen -> lunch | 19:28 | |
| === NCommander is now known as Guest45434 | ||
| jonpry | anyone notice that the ubuntu.kernel.org ppa is out of disk space? | 22:42 |
| === Guest45434 is now known as NCommander | ||
| === NCommander is now known as Guest61019 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
