From Fedora Project Wiki

< QA‎ | Meetings


  • adamw (242)
  • tflink (61)
  • kparal (43)
  • Viking-Ice (36)
  • dledford (26)
  • nirik (17)
  • pjones (7)
  • robatino (6)
  • brunowolff (4)
  • zodbot (4)
  • jskladan (3)
  • lmacken (1)
  • athmane (1)
  • pschindl (1)

Action Items

  • adamw to summarize this response for the fesco trac ticket
  • nirik look into why grub2 isn't showing up as critpath in bodhi
  • tflink to ping python-yourls reviewer to get the process moving again
  • tflink find out current status of virtualization test day


adamw #startmeeting Fedora QA meeting 15:01
zodbot Meeting started Mon Sep 12 15:01:22 2011 UTC. The chair is adamw. Information about MeetBot at 15:01
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01
kparal hello 15:01
adamw #meetingname fedora-qa 15:01
zodbot The meeting name has been set to 'fedora-qa' 15:01
adamw morning (IN YOUR REGION) kparal 15:01
adamw #topic roll call 15:01
* athmane is around 15:02
adamw who's here and ready to a some q? 15:02
* kparal enjoys afternoon's morning 15:02
* nirik is lurking. 15:02
* tflink is here 15:02
* pschindl is here 15:02
adamw kparal: sounds like a Talking Heads album title 15:02
* kparal is not familiar 15:03
adamw look 'em up! 15:04
adamw alrighty 15:04
adamw #topic previous meeting follow-up 15:04
adamw so, we didn't meet last week: the last meeting was 15:04
adamw we had three action items 15:05
adamw adamw - ping rbergeron about updating the the schedule to include the new TCs 15:05
adamw I did that, but i'm not sure she's actually updated the schedule: i'll ping again 15:05
* jskladan lurks 15:05
adamw adamw - check in with tflink about alpha/beta/final validation results and ensuring bugs are correctly marked as blockers 15:05
adamw i did that, and tflink did indeed go through the alpha results and make sure failures were marked as blockers, thanks tflink. 15:06
tflink np 15:06
adamw and finally... 15:06
adamw adamw - check in with tflink about alpha/beta/final validation results and ensuring bugs are correctly marked as blockers 15:06
adamw sigh. fial. 15:06
adamw mkrizek - review tflink's Python bindings for yourls 15:06
adamw tflink: did that get done? 15:06
tflink adamw: we did get started but reviewboard was down for a bit. I'm doing the next round now 15:07
adamw cool. 15:07
kparal mkrizek responded for that last week via email 15:07
tflink wait, I got confiused 15:07
adamw oh right. 15:07
tflink confused 15:07
tflink the review for the RPM is still waiting final review 15:07
tflink I submitted fixes but the reviewer hasn't responded yet 15:07
tflink I'll ping him today 15:08
adamw okay. 15:09
adamw need an action item or is that just normal stuff? 15:09
adamw #chair tflink 15:09
zodbot Current chairs: adamw tflink 15:09
adamw ^^^ for raptor-proofing 15:09
tflink adamw: just normal stuff but I can #action 15:10
tflink #action tflink to ping python-yourls reviewer to get the process moving again 15:10
adamw okie dokie 15:11
adamw #topic beta preparation 15:12
adamw so, let's take a quick look at where we are with the beta... 15:12
adamw it looks like we still have quite a few bugs that need re-verification, and some new ones in tc2, unfortunately 15:13
adamw looks like fixes to raid and grub stuff have caused some regressions 15:13
adamw it's probably worth doing a quick mini-blocker-review, that good for everyone? 15:14
* kparal fires up the blocker list 15:14
kparal 15:15
adamw tflink: is that up to date right now? 15:15
tflink adamw: should be, the script is firing every hour AFAIK 15:15
adamw okay 15:16
adamw so i think we can skip the accepted blockers and just look at the new proposed 15:16
adamw there's only three 15:16
adamw #topic 15:16
tflink if this really needs an OSX partition, doesn 15:17
kparal will it also fail when having windows instead of mac os? 15:17
adamw kparal: well, we're not entirely sure 15:17
tflink t that hit the "everything but macs" part? 15:17
* tflink realizes that OSX partition and EFI working on "everything but macs" are not the same thing 15:18
adamw tflink: but fairly similar, yeah. 15:18
adamw i'd like to have a look at the script in question but my f16 machine is still firing up 15:18
adamw anyone have a copy to hand? 15:18
tflink I'm wondering if we need more information on this. it seems a little vague 15:19
adamw well, the *cause* seems very clear 15:19
adamw but we're definitely missing details on the *symptoms* 15:19
adamw i think looking at the script should rather clear it up, though 15:19
adamw if someone could pastebin the thing *hint hint* 15:19
kparal the release criteria speak only of windows, and it's final criteria, not beta, I believe 15:20
* tflink is updating a F16 VM right now 15:20
adamw okay, so in the interests of time, shall we agree to ask for info on this one for now? 15:20
tflink sounds good to me 15:20
adamw propose #agreed need more info on what circumstances you need to be in to hit 737203 15:21
kparal +1 15:21
adamw okay, counting two acks 15:21
tflink ack 15:22
adamw #agreed need more info on what circumstances you need to be in to hit 737203 15:22
adamw #topic 15:22
adamw this seems dubious 15:23
adamw "Throwing this on the Beta blocker bug list since users arent able to boot into a newly installed kernel." 15:23
adamw but why would your newly installed kernel have no initramfs? 15:23
tflink that's what I was wondering 15:23
tflink but the wording makes me wonder if that is just a method of reproducing 15:23
adamw well, i read it as that's the case he definitely identified 15:24
adamw and the rest is speculation 15:25
tflink needinfo again? 15:25
* kparal gives no vote, doesn't understand this one 15:26
adamw yeah, i think needinfo. 15:27
adamw bit more justification required. 15:27
tflink adamw: are you playing secretary, too or do you want me to do that? 15:27
adamw propose #agreed 737370 need more information on exactly why viking feels this impacts the ability to boot a newly installed kernel in normal conditions, as a newly installed kernel should have an initramfs 15:27
adamw tflink: that'd be a help 15:27
tflink k, will do 15:28
tflink ack 15:28
adamw #agreed 737370 need more information on exactly why viking feels this impacts the ability to boot a newly installed kernel in normal conditions, as a newly installed kernel should have an initramfs 15:28
adamw #topic 15:28
adamw this one's obviously config-specific to some degree, but it sure looks bad. 15:29
adamw dledford: around? 15:29
dledford yes 15:30
adamw dledford: does this look like a dupe of 736521 to you, as proposed by the reporter? they don't look quite the same to me, though obviously in the same general area. 15:30
adamw i know dlehman was worried about installs with pre-existing mdraid arrays, and 736521 is part of that. 15:31
dledford give me a few minutes, I've not seen this particular bug before 15:31
dledford might want to skip to next bug and come back to this one after I've had a chance to fully check it out 15:32
tflink I think this is the last of the proposed blockers, no? 15:33
adamw this is the last one 15:33
adamw so, i guess for now we should keep them separate until we're sure they're dupes 15:33
adamw on the face of it i'm +1 blocker for this 15:34
dledford ok, this is a dup of 736521 15:34
adamw the installer ought to handle pre-existing raid arrays 15:34
adamw cool. so, i propose we take 736521 as a beta blocker 15:34
dledford the installer *should*, but older arrays need to be phased out and users need to be warned that they need to upgrade to a new metadata format. 15:35
adamw on the basis that the criterion implies the installer should handle existing raid arrays sanely. 15:35
dledford I agree on 736521 as a beta blocker 15:35
adamw cool, thanks. 15:35
tflink works for me 15:35
adamw #agreed 737278 is a dupe of 736521 15:35
adamw #topic 15:36
dledford issue isn't about existing arrays to be honest, it's the shutdown of *any* array is oopsing, that we start and then shutdown pre-existing arrays merely shoves it in our faces at install time, without that we would still likely hit this bug on reboot with a newly created array 15:36
adamw ah, okay 15:36
dledford and that being the case, it's even more of a blocker 15:36
adamw propose #agreed we propose and accept 736521 as a beta blocker on the basis that it is known to break installation when an mdraid array exists on the target system, and it is believed that it would likely affect proper functioning of a system with a newly-created array 15:37
adamw dledford: yeah, makes it easy. 15:37
tflink ack 15:38
adamw okie dokie 15:38
adamw #agreed we propose and accept 736521 as a beta blocker on the basis that it is known to break installation when an mdraid array exists on the target system, and it is believed that it would likely affect proper functioning of a system with a newly-created array 15:38
adamw let's see, there's a couple of proposed nth we could knock off quick 15:38
adamw #topic 15:39
adamw doh, should really have got this into tc2 :( 15:39
adamw this is the 'lldpad eats my cpu' bug 15:39
adamw it's a pretty easy +1 nth for me as it's going to affect every boot of the live image 15:39
adamw oh, god, i've bored everyone to death 15:41
adamw i knew this day would come 15:41
tflink I thought that we covered this one on friday, no? 15:41
adamw if we did, i did a piss poor job of secretizing it 15:41
adamw which is entirely possible 15:41
tflink I thought that we pseudo-skipped it because it's an F15 bug 15:41
* kparal never heard of lldpad 15:41
tflink under the understanding that we would take the F16 version as a blocker or NTH (don't remember which) 15:42
adamw tflink: we accepted it 15:42
adamw kparal: it doesn't do anything most of us need, but it's getting pulled into live images through anaconda deps 15:42
adamw and if you have it installed without this fix, it'll eat about 10% of your cycles. om nom nom. 15:43
kparal even after installation? 15:43
adamw anyway, we accepted it at firday's meeting, so...moving on 15:43
tflink yeah, this is the one where the RHEL6 version got proposed as a F16 NTH 15:43
kparal or just during LiveCD run? 15:43
adamw kparal: yeah, except after install you can at least remove it. 15:43
adamw and fix it with an update. 15:44
kparal then I'd say we should consider even a real blocker 15:44
adamw we don't really have criteria for minor performance overhead like this 15:44
adamw regardless, it'll get fixed, so let's not spend too much time... 15:44
adamw #agreed 701943 was already covered in 09-09 review, but bug report not updated 15:45
adamw #topic 15:45
adamw okay, last one 15:45
adamw this looks like a 'blocker' for a non-blocking desktop (sugar) so automatic nth 15:45
adamw so, i'm +1 15:45
kparal +1 15:46
tflink +1 nth 15:46
adamw propose #agreed 737150 is a blocker for a non-blocking desktop, sugar, so it's accepted as NTH 15:46
tflink ack 15:47
adamw #agreed 737150 is a blocker for a non-blocking desktop, sugar, so it's accepted as NTH 15:47
adamw okay, that was relatively painless! thanks for secretaryizing tflink 15:47
tflink shouldn't we be cloning 701943? 15:47
tflink instead of accepting a F15 bug as NTH for F16? 15:47
adamw tflink: meh. i don't really see it as being a huge problem. we quite often use bugs for multiple releases. it's just not something bugzilla's very good at. 15:48
tflink ok 15:48
adamw admittedly, it'd get auto-closed if the f15 update was pushed, so it might be safer... 15:48
adamw if you want to do it, go ahead, and take the nth status with the clone 15:48
adamw so...any other business for beta? 15:49
adamw it looks like we have quite a bit of work to clear the blocker list for wednesday 15:49
adamw we definitely need to get all those modified blocker fixes confirmed 15:49
robatino there are 2 responses on so may want to revisit that 15:50
* adamw looks 15:51
adamw "Are you going to argue here that booting without initramfs is not a valid user configuration?" 15:51
adamw erm...yes? 15:51
Viking-Ice go ahead 15:51
adamw well, i mean, valid? sure, in the sense that nothing stops you doing that. release critical? I'm having a hard time. 15:51
Viking-Ice enlighten me why it is not 15:51
Viking-Ice I'm waiting 15:51
Viking-Ice it's not default yes but not valid ??? 15:52
adamw what do you mean by 'valid'? 15:52
kparal the question is whether we want to block the released because of it 15:52
Viking-Ice valid accepted setup 15:52
adamw the release criteria don't cover 'everything you can possibly configure the system to do'. is it a valid bug? sure. is it a release blocker? i'm not sure 15:52
kparal *release 15:52
adamw #topic 15:52
Viking-Ice I would think broken grub2 is yes a valid blocker 15:52
adamw so, to put it formally, this is a violation of a criterion (any old one about booting the system), but only in a specific, non-default configuration: you boot without an initramfs. 15:53
Viking-Ice but file it as nth otherwize but this needs to be fixed before final atleast 15:53
Viking-Ice I would think 15:53
adamw i don't know if we have any data on how many people boot without initramfs. if i had to make a wild-ass guess it'd be 'not a lot'. 15:53
Viking-Ice so what the rule of thumb is that if it's not default it cant be blocker 15:54
adamw Viking-Ice: what's the use case for it? 15:54
Viking-Ice since it's not "valid" configuration 15:54
Viking-Ice adamw, dropping initramfs decrease boot time 15:54
adamw Viking-Ice: whenever a bug violates a criterion but only in some specific configuration, we discuss how common that configuration is, and hence how likely the bug is to be encountered 15:54
adamw presumably you'd have to build a custom kernel with all the necessary modules for your system built into it? 15:54
Viking-Ice it will occur to all that do not boot with initramfs 15:55
Viking-Ice so it affects atleast me haraldh that i'm aware of 15:55
Viking-Ice where are you going to draw the line here 10 users 100 users 1000 users ??? 15:55
adamw we've done this before 15:55
Viking-Ice adamw, nope 15:55
kparal better use percentage 15:55
Viking-Ice you dont 15:55
adamw you've been here... 15:55
adamw well, any time i've tried to boot without an initramfs (which happens sometimes when grubby has a bug or whatever), boot has failed 15:56
adamw not because of this bug, but because some driver needed for my hardware that's in the initramfs wasn't loaded... 15:56
adamw oh, worth noting there is of course a workaround for this: enable the initramfs. 15:57
adamw so, it's kinda hard to make a determination here as we really have no idea how many people disable the initramfs. this is the first time i've come across it. 15:57
Viking-Ice or backport that patch I mention or rather updated grub to more recent version 15:57
adamw anyone else have any data or anything? 15:57
Viking-Ice adamw, bunch in debian arch and gentoo have hit this 15:57
adamw ah, the ricer distros. =) 15:57
Viking-Ice let's asume that there are more then me and harald that are booting without initramfs 15:58
adamw that seems likely, but it's still vague 15:58
adamw how many more? we don't really have a clue 15:58
tflink a fair assumption, but I'm not convinced that its enough to be a blocker 15:58
Viking-Ice adamw, we cant have a clute 15:58
tflink NTH at most is what I'm thinking ATM 15:58
Viking-Ice clue as to many other things 15:58
kparal if kernel compilation is required to go without initramfs, I don't believe this will hit too many people. like >1% 15:58
adamw i guess my vote would be -1 beta blocker, +1 nth, maybe +1 final blocker, but we're really guessing in the dark 15:59
adamw kparal: well, viking says it isn't 15:59
Viking-Ice kparal, kernel compilation is not needed 15:59
Viking-Ice atleast not in my case 15:59
tflink how about -1 beta blocker, +1 nth and will re-consider for final blocker if more information on number of people hitting it comes up 15:59
Viking-Ice really 15:59
kparal tflink: +1 16:00
Viking-Ice this breaks kernel installation on updates 16:00
kparal meaning ack for tflink's proposal 16:00
Viking-Ice and you dont think this it's valid 16:00
adamw 'valid' isn't really a useful word in this context. 16:00
Viking-Ice <sigh> 16:00
adamw they don't think it's a beta blocker. 16:00
tflink Viking-Ice: not invalid, just not very common 16:00
Viking-Ice yet... 16:01
tflink it's certainly a bug but as you asked before, what is the cutoff? 16:01
adamw we can send out a mail to test and devel to try and get some idea of how many people boot without initramfs. 16:01
tflink we knnow that 2 people are using this config right now and have no idea how many more 16:01
Viking-Ice or people are going to hit this when they upgrade and already are booting without initramfs 16:01
tflink +1 to adamw's suggestion 16:01
Viking-Ice want to count the screams then? 16:01
adamw sure. i'm good at screams. 16:01
dledford Viking-Ice: it will be on one hand 16:01
dledford Viking-Ice: sorry, but your config is rare...that you have it working for you is awesome, I doubt more than 5 other people do. 16:02
adamw anyway, we seem to have a consensus 16:02
Viking-Ice nth revisit at final... 16:03
adamw propose #agreed 737370 rejected as a blocker as it requires a non-standard configuration we think is likely to be very uncommon, accepted as nth due to severity of impact. we will try and check with devel and test lists to see if many others are using the affected configuration 16:03
kparal ack 16:03
Viking-Ice ack 16:03
dledford ack 16:03
tflink ack 16:03
adamw #agreed 737370 rejected as a blocker as it requires a non-standard configuration we think is likely to be very uncommon, accepted as nth due to severity of impact. we will try and check with devel and test lists to see if many others are using the affected configuration 16:03
adamw okay! 16:03
adamw so...any other beta business? 16:04
Viking-Ice dont we need to form some criteria around grub 16:04
adamw Viking-Ice: like i wrote in the bug, i think we have sufficient *criteria*, but what would be useful would be test cases 16:04
adamw it would be great if you could draft up some test cases we could associate with grub2 16:04
dledford Viking-Ice: Out of curiosity, what root filesystem can you even use without an initramfs and using the precompiled kernel package? There are almost *no* built in disk or network drivers... 16:04
Viking-Ice for instance if valid grub options would break configuration creation 16:05
Viking-Ice not default but people do it... 16:05
Viking-Ice dledford, ext4 16:05
dledford Viking-Ice: that's a filesystem driver, not a disk driver, what's the disk attached to? 16:05
adamw alright, i'm gonna move on as we're already past 1 hr and we could be spending time on beta bugs... 16:05
adamw #topic Update policy changes? 16:06
adamw so i wanted to flag up for anyone who hadn't seen it 16:06
adamw there's a proposal before fesco to loosen up the updates policy, specifically the critpath requirements 16:07
adamw i tend to be the only person from qa who speaks up when this kind of question comes up on -devel, which might give the impression i'm representing the whole of QA, but really i'm not, we don't have any kind of agreed 'party line' on the policy... 16:07
adamw so i figured it'd be good to bring it up so people can chip in on their own behalf if they like, and if anyone feels really strongly about it we could come up with a group position 16:08
tflink I think that we're between a rock and a hard place here 16:08
adamw yeah, it's a hard problem. 16:08
tflink I dislike the idea of releasing CRITPATH updates without testing 16:08
tflink but waiting that long for updates isn't ideal, either 16:08
adamw but obviously when a security update for a stable release is sitting around for 21 days without karma, that's not good. 16:08
tflink and annoying for maintainers 16:08
adamw worth putting in the standard call for more people to keep stable releases around - in vms, if nothing else - and do karma for them...please do that! 16:09
* adamw should practice what he preaches 16:09
* tflink is also guilty of that 16:09
dledford Some of us keep stable releases around all the time ;-) 16:09
adamw dledford: boring! ;) 16:09
* dledford hasn't touched f16 yet 16:10
adamw dledford: it's mostly N-1 that's the problem 16:10
adamw i have f16 on my desktop and f15 on this laptop, but f14 only in a vm 16:10
adamw i think that's the case for quite a few people 16:10
kparal can we link here the current critpath policy for comparison? 16:10
adamw i guess i could put out a call for proventesters on the forums, i think there are generally a few more people running older stable releases there 16:10
* nirik liked the idea of perhaps a proventester meeting per week... 16:10
adamw kparal: sure - the policy in question is 16:10
kparal adamw: thanks 16:10
dledford Yeah, but I put out two calls for testers on my updates and they still lingered for 43 days. Calls for testers simply doesn't guarantee any results at all. 16:11
adamw nirik: i'd just be afraid it'd go the way of bugzappers, but if someone was really committed to doing it, that'd be great 16:11
nirik dledford: FWIW, I fear that mdadm runs into "hey, I don't want my raid arrays on a new alpha release" so less testers. ;( 16:11
adamw dledford: i think it got through now, right? i put out a call on -test last week with specific 'this is the scenario in which you can +1 the update' notes which i think helped 16:11
dledford nirik: I get a reasonable number of f15 bugs, and a reasonable number of f16 alpha/beta bugs, no f14 bugs, so I would say it's kinda split. 16:11
brunowolff I run raid 1 on almost all of my systems, which currently include f15, f16 and rawhide. 16:12
tflink I also don't have many RAID arrays, which makes it harder to test 16:12
brunowolff That's how I found the 3.1 kernel bug related to raid. 16:12
dledford nirik: I get people staying at a stable release, but I also now get people who run into mdadm simply because they have Intel Matrix raid on their test box 16:12
nirik dledford: BTW, sorry this is causing you issues... hopefully we can come up with a way to make it better. 16:12
kparal the condition 1) in the proposal is OK I think 16:12
kparal condition 2) is the current policy 16:12
* nirik has a raid/storage box, but it's f15, and I don't reboot it much. 16:12
dledford nirik: my home server is f15 as well with my primary storage being raid5, and also doesn't reboot much...unless I'm working on an update ;-) 16:13
brunowolff I think that some timeout is reasonable. If critpath testing isn't getting done, then releasing an update may be better than not releasing. 16:13
adamw well, condition 1) has somewhat of a problem, which is that not everyone can change bug state 16:13
kparal adamw: then they can comment in Bodhi 16:14
adamw so if a third party confirms the fix, but the original bug reporter goes AWOL, the third party might not be able to set VERIFIED, though the maintainer could do it on their behalf 16:14
adamw true 16:14
dledford adamw: and in hindsight, I would rewrite condition 1 to exclude FTBFS and New Upstream automated bugs and limit gating on actual human filed bugs 16:14
kparal or comment in the bug, and the maintainer takes care of that 16:14
adamw 2) is actually *stricter* than current policy 16:14
kparal I see, 1 extra karma 16:15
adamw current policy is just +1 proventester, +1 anyone else, and -1s aren't taken into account (though i'd argue that's a bug in bodhi/the policy/both) 16:15
adamw it's also worth throwing my standard pony in here, which is that simple numerical bodhi karma sucks ass and is just about impossible to write a really good policy with: we've been waiting for bodhi 2, which will have a more flexible karma system, for a while 16:15
adamw the policy would need rewriting for bodhi 2 anyway 16:15
adamw 3) is the most controversial, i guess, but i don't hate it 16:16
kparal I think some timeout could be accepted, because we cannot ensure every critpath update gets tested 16:16
* nirik also notes that making things more complex means more chance for bodhi bugs and also more chance for confusion 16:16
kparal the questions is whether it should look like 3) or somehow else 16:16
adamw so i guess we can say none of us really has any objection to dledford's proposal? 16:16
adamw in particular the timeout, which seems the most 'controversial' bit? 16:17
tflink like I said, I'd rather not have untested critpath updates, but I don't have any better ideas 16:17
kparal I think it could work, and if some problems arises we can discuss further modifications 16:17
adamw tflink: right, that's about where i am with it 16:17
adamw oh, i'd modify 3) very slightly to specifically say you can't timeout push an update with negative karma 16:18
adamw i'm sure that was dledford's intent, but it should be explicit :) 16:18
tflink until we have a better and more effective system for getting stuff tested within a reasonable amount of time, anyways 16:18
dledford adamw: fair enough, I'm good with that modification 16:18
tflink yeah, definitely +1 to no neg karma 16:18
dledford adamw: in general I'm good with no neg karma 16:19
adamw i'm not sure if there's anything wrong with *the system*, really, it's just that we plain don't have the manpower to cover all critpath updates for all releases 16:19
adamw dledford: okay. 16:19
adamw it does seem like the system is pretty strong at negative karma'ing bad updates 16:19
adamw which gives me more confidence in a timeout system even for critpath 16:19
dledford adamw: just need to make sure that an edit/new build of an update properly resets existing karma for the new build in the update 16:19
adamw we tend to get a lot more -1s on bad updates than we get +1s on good ones 16:19
nirik dledford: I am pretty sure it does now. 16:20
adamw dledford: yeah. 16:20
nirik but I could be wrong. 16:20
dledford okie dokie, I'm good then 16:20
adamw okay 16:20
adamw so... 16:20
tflink resets karma and timeout on new update, I think would be better 16:20
adamw propose that we agree QA as a body is okay with dledford's proposal, and specifically with the idea of allowing even critpath updates through on a timeout basis with no negative karma 16:20
tflink but I suppose that after a certain point, you have to trust people 16:20
adamw and i'll post a comment to the bug to reflect that 16:21
adamw sound okay? 16:21
tflink works for me 16:21
adamw anyone else? 16:21
kparal ack 16:22
brunowolff ack 16:22
kparal "no negative karma" means the total, or any karma feedback 16:22
kparal ? 16:22
tflink any 16:22
kparal ok 16:23
adamw the simplest interpretation is 'any' 16:23
dledford I'd ack, but that's sort of self serving ;-) 16:23
adamw though there is the question of +20, -1, but that doesn't apply to the timeout scenario 16:23
adamw dledford: hehe 16:23
adamw okay 16:24
adamw #agreed qa does not object to dledford's proposals, specifically the timeout for critpath option 16:24
adamw #action adamw to summarize this response for the fesco trac ticket 16:24
* nirik notes the fesco meeting is in 30 or so. 16:25
adamw yeah, i'll blow through this quick 16:25
adamw #topic upcoming events 16:25
adamw so, we have a virtualization test day scheduled for this thursday, but no page up yet 16:25
* dledford thanks everyone and steps outside 16:25
tflink they said that they were working on it on friday 16:25
adamw thanks dledford 16:25
adamw tflink: okay 16:26
adamw tflink: do you want to take an action item to bag yourself a jforbes and find out the current status? 16:26
adamw it would really be good to have the page in place by tomorrow for pr purposes 16:26
tflink #action tflink find out current status of virtualization test day 16:26
adamw yay, thanks tim. 16:27
adamw aside from that, feature freeze is tomorrow and rc is supposed to be wednesday... 16:27
adamw and of course there's a blocker review meeting on friday 16:28
adamw i don't see a whole lot else coming up in the near future, anyone else? 16:28
tflink sounds like a calm week ahead :-D 16:28
adamw heh =) 16:29
adamw yeah, everyone hit the beach 16:29
adamw #topic autoqa update 16:30
adamw any big autoqa news, tflink or kparal? 16:30
adamw or small autoqa news, for that matter 16:30
kparal most of the team was off half of the last week 16:30
kparal so I know only two small updates 16:31
kparal pschindl added opt-in email support into anaconda test cases 16:31
kparal and mkrizek posted patch for using the yourls url shortener inside autoqa 16:31
kparal I reviewed it, I think it will require a little bit more work. but we should be near 16:32
adamw cool, sounds like that project's moving along. 16:32
kparal I hope tflink can add anything I have missed 16:32
* tflink is going to get that done today 16:32
kparal oh, and jskladan received his red fedora, an important step in autoqa development 16:32
adamw stop the presses! 16:33
* jskladan yey 16:33
adamw i expect you spent all week testing it out 16:34
jskladan not yet, but i will :-D 16:34
adamw =) 16:34
adamw okay 16:34
adamw #info pschindl added opt-in email support into anaconda test cases 16:34
adamw #info mkrizek posted patch for using the yourls url shortener inside autoqa 16:35
adamw #topic open discussion 16:35
adamw ...and finally we made it 16:35
robatino currently grub is critpath but grub2 is not 16:35
adamw anything we didnt' cover yet? 16:35
adamw robatino: ah, nice. i think we should bring that up with releng 16:35
adamw robatino: could you file a releng trac ticket? 16:35
robatino i'm not familiar with that - didn't even know they were involved 16:36
adamw i believe releng maintains the critpath generation stuff 16:37
adamw just go to , sign in with fedora account, and file a new ticket 16:37
adamw nirik: this is releng stuff, right? 16:38
nirik yeah. 16:38
adamw cool. 16:38
nirik it was recently fixed I thought... 16:38
adamw nirik: generating critpath? or grub2 being in it? 16:38
nirik generating it. 16:38
adamw okay, well, this is b) =) 16:38
robatino i only see two existing tickets with the word "critpath" in them and neither seem related 16:39
robatino so i'd rather someone more familiar do it 16:39
nirik it is. 16:39
nirik grub2 is in, but might be something wrong with bodhi accepting it. 16:40
nirik 16:40
adamw of course, if critpath generation was only fixed recently, we don't know how long grub2's been in... 16:41
adamw was submitted 09-05 and is not identified as critpath 16:41
* pjones perks up 16:42
pjones so what's the issue? 16:42
pjones oh, so critpath may not have listed grub2 for a while? 16:43
nirik I think bodhi just needs to load in the current one, but I could be wrong. 16:43
adamw pjones: we're not sure if it's that grub2 only recently got into critpath, or if it's that bodhi isn't picking up the critpath status. 16:43
pjones yeah 16:43
adamw robatino: nirik: can i give you two an action item to look into it further? 16:44
nirik adamw: sure, I can ping lmacken on it or file a ticket. 16:44
robatino i'm not really competent, i just noticed it on bodhi 16:44
adamw okay, i'll throw it at nirik then =) thanks for flagging it up 16:44
adamw #action nirik look into why grub2 isn't showing up as critpath in bodhi 16:44
pjones so as the guy currently banging on that package, is there any practical implication I should know about? 16:44
lmacken adamw: I'll update the critpath list by hand (ideally bodhi needs to query the pkgdb for it) 16:45
adamw pjones: well, per policy you should restrain yourself from pushing updates to it without the appropriate karma for critpath. that's about all. 16:45
adamw lmacken: yay! efficiency. 16:45
pjones adamw: sure - but we've already been doing the karma thing there AFAIK (which is why -5 currently isn't in) 16:45
pjones unless I've misunderstood something major. 16:45
adamw pjones: in that case, nothing to worry about. 16:46
adamw alright...anything else? 16:46
adamw setting fuse for 2 minutes 16:47
adamw alright, thanks for coming everyone 16:49
adamw go forth and test! 16:49
adamw #endmeeting 16:50

Generated by 2.8 by Marius Gedminas - find it at!