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