From Fedora Project Wiki
Attendees
- 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
IRC Log
| 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 http://wiki.debian.org/MeetBot. | 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 https://fedoraproject.org/wiki/QA/Meetings/20110829 | 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 | https://fedoraproject.org/wiki/Current_Release_Blockers | 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 https://bugzilla.redhat.com/show_bug.cgi?id=737203 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=737370 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=737278 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=736521 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=701943 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=737150 | 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 https://bugzilla.redhat.com/show_bug.cgi?id=737370 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 https://bugzilla.redhat.com/show_bug.cgi?id=737370 | 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 https://fedorahosted.org/fesco/ticket/667 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 https://fedoraproject.org/wiki/Updates_Policy | 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 https://fedorahosted.org/rel-eng , 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 | http://kojipkgs.fedoraproject.org/mash/branched-20110912/logs/critpath.txt | 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 | https://admin.fedoraproject.org/updates/FEDORA-2011-12215 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 irclog2html.py 2.8 by Marius Gedminas - find it at mg.pov.lt!