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