ppisatimorgen *07:39
* apw peers blearily out on the world07:44
jk-hey apw07:45
jk-and hello ppisati 07:45
apwjk0 heya07:45
apwcnd, hey!08:49
ckingcnd, welcome to sunny UK09:28
cndcking, thanks :)09:36
cndweather seems nice here09:36
ckingit's unbelievable warm for the time of year at the moment09:37
ckingunbelievably even09:37
diwicSweden's so cold Facebook's planning it's next facility in northmost Sweden. :-)10:26
diwiccking, but currently I share your analysis, it's quite warm here as well.10:27
ckingapw, I fakeroot doesn't seem to exist on tangerine's oneiric chroots - am I going mad, or has somebody removed it recently?10:39
apwcking, checking10:42
ckingmethinks apw is installing it now for me10:45
apwheh whyso ?10:45
ckingit's now working for me10:45
apwreally now that is odd10:46
ckingyou messing with my mind? ;-)10:46
apwnot for me10:46
ckingI could never get the hang of mondays10:47
apwPicking 'linux-meta' as source package instead of 'linux'10:52
apwwtf ... why would you do that10:52
apwsomething is very wrong with pretty much everything to do with the chroot creation, i am applying some hammers10:54
apwbah, the damn arm cross tools again, are uninstallable10:58
ckinga stick of TNT may be more appropriate10:58
ckingdoesn't anyone check this kind of stutff?10:58
* ppisati -> reboot in Oneiric11:02
diwicapw, 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
apwdiwic, no more specific information than you suggested, we would expect a release 'now' really11:50
apwthen i'd expect the merge window the next week11:50
diwicapw, ok11:50
apwif he vacs then yes he often shoves it in the gap, and we wait a little longer, but not much more11:51
diwichow long does he go for vacation usually?11:51
ckingdepends if he goes diving and runs out of oxygen11:52
apwa week normally11:52
diwicapw, so I good guess would be release this week, next week vacation, week after that would be merge window?11:53
apwyeah, he may have a longer merge window with his vac in it too, thats happened before11:56
apwbut, anything not already in a maintainers tree by now, isn't likely to make it unless its a bugfix11:56
diwicbut merging new features would then be accepted by the end of the merge window as well, no strict "regressions only" stuff.11:57
diwichrm ok11:58
diwicso this practically leaves me ~1 day to finish off all new kernel features for 12.04.12:01
apwif we have 3.2 yes probabally, it is hard to know which will actually be in the release this early12:10
apwit depends more on external factors than anything else12:10
brendandsconklin - is the maverick kernel getting respun?14:01
* ogasawara back in 2014:06
sconklinbrendand, probably not, I think that failure turned out not to be a kernel problem.14:11
brendandsconklin - aha. should we go ahead with cert testing then?14:15
brendandsconklin - i'll get hggdh to update the bug14:16
sconklinNot 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 is14:16
hggdhsconklin, brendand: if you are talking about bug 854092 then it is a pass from QA -- problem is at AWS14:21
ubot2Launchpad bug 854092 in kernel-sru-workflow/certification-testing "linux: 2.6.35-30.60 -proposed tracker" [Undecided,Confirmed] https://launchpad.net/bugs/85409214:21
sconklinhggdh, then in order to proceed, the tag has to be changed from a fail to a pass14:22
hggdhjust did it14:23
apw(preferably with an expplanation in the bug as to why its ok to switch it)14:23
hggdhbut 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 elsewhere14:24
hertonhggdh: hardy was also tagged as failed, problem in the same test as maverick, is it also the same issue?14:36
apwsmb is off today so he won't be commenting ....14:40
hggdhherton: indeed14:42
hggdhherton: tagged -passed14:45
hertonok thanks14:45
hggdhsconklin: we need to work out this retagging14:46
hggdh(in general)14:46
sconklinhggdh, I agree, it should be set to pass by whoever 'makes the decision', in this case smb14:56
hggdhsconklin: thank you. In this case, I explicitly asked smb about it, so we are cool14:57
bjfsconklin, not sure i entirely agree with that, QA "ownes" that stage so it should be they that makes any changes regarding it14:58
bjfsconklin, 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 tag14:58
hggdhbjf: QA owns the test, and takes a decision based on the test results. Once a bug is opened, the subject matter experts can decide14:58
hggdhbjf: this would be an override. Overrides are signed by whoever decides14:59
sconklinbjf, that was indeed my original thinking on this, that no one outside of the assigned team should be changing status or tags.14:59
bjfsconklin, that is my beliefe15:00
sconklinBecause 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
sconklinanother problem is that almost any case where an override is required is going to be vaguely defined and impossible to anticipate in our process documentation15:01
bjfsconklin, i don't think that delegation of responsibility should be part of the process15:02
hggdhwe really need to figure this out. This is not delegation, but override; an entirely different beast15:02
sconklinbut we can not determine a priori who should have the ability to make an override.15:03
sconklinI do see bjf's point15:03
hggdhthere 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 reason15:04
hggdhso the final decision will be from whoever owns the task15:05
hggdhbut this should be made clear.15:06
hggdhIn other words: explanation of why the decision can be overriden comes from the subject matter experts; final decision from the step/task owner15: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 change15:09
sconklinI think that sounds right. So ultimately it is the responsibility of the asignee to complete that task, by involving subject experts as required15:12
apwto 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
hggdhthis actually should be applied to all tasks, and for success or failure15:15
hggdhsconklin: er. Should we, then, *not* complete a task if there is doubt? Or should we fail, and then override if needed?15:16
sconklinhttps://github.com/sickill/git-dude looks handy, although I wonder if it won't lead to excessive fetches on upstream repos15:16
sconklinIf 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
gemahggdh: I don't think anyone but QA should be changing a test case from fail to pass16:06
gemaas apw  says, they should convince us :)16:07
gemasorry, I have come too late to the conversation, probably16:07
hggdhgema: I am not sure, but I accept the reasoning. And yes, I think you got in too late ;-)16:09
gemahggdh: normally when you have to change a test case from fail to pass there is more to it than that16:09
gemait is likely we'll have to do some follow up and add another test case or so16:09
gemaI was just trying to understand the process based on the conversation16:10
gemanot sure what changing from fail to pass means in this context, so don't mind me too much x)16:10
apwi 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 there16:10
gemaapw: 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 it16:11
gemaand you don't change just the result, I presume you change the condition that makes the test fail and re-run?16:12
komputesDoes 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.JPG16:22
komputesFull bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/85308516:22
ubot2Launchpad bug 853085 in linux "general protection fault: 0000 [#1] SMP " [Undecided,Confirmed]16:22
hggdhgema: in this case, we were discussing a bug found while checking; the bug is outside the checking scope (but driven by it).16:23
gemahggdh: yep, I was looking at it now, thanks :)16:24
hggdhgema: 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
gemahggdh: I thought it was interesting to jump in because you were talking about agreeing on a process16:24
gemahggdh: so I wanted to understand the problem further16:24
gemahggdh: understood, so the test case needs changing16:25
gemahggdh: I find pretty difficult to decide whether a test passes or fails with our current process16:25
hggdhactually, both the test conditions and the process16:25
hggdhgema: better we get back to #qa to discuss it16:26
gemahggdh: sure16:26
tgardnerapw, gomeis/tangerine gcc-arm-linux-gnueabi in oneiric schroot17:39
tgardnerinstalled in*17:39
* tgardner -? lunch17:52
* jjohansen -> lunch19:28
=== NCommander is now known as Guest45434
jonpryanyone 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!