16:00:10 #startmeeting F-14-Beta blocker review 16:00:10 Meeting started Fri Aug 27 16:00:10 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:15 #topic Gathering ... 16:00:17 yo 16:00:24 #meetingname f-14-beta-blocker-review 16:00:24 The meeting name has been set to 'f-14-beta-blocker-review' 16:00:31 hey adamw 16:01:07 I'll just wait another minute for others 16:02:16 alright, I guess it's adamw, me and zodbot 16:02:23 thank god for zodbot 16:02:28 indeed 16:02:31 otherwise i might fear for my maidenhead 16:02:41 * jlaska is speachless 16:02:44 :P 16:02:45 speechless too 16:02:58 okay ... I think we all know the rules here 16:03:07 But for anyone new to the meeting ... 16:03:14 * nirik is lurking around, but somewhat busy... ping me if I can help 16:03:17 I'll be walking through the bugs listed at ... 16:03:19 nirik: will do 16:03:22 #link https://bugzilla.redhat.com/showdependencytree.cgi?id=611991&hide_resolved=1 16:03:52 let's get started 16:03:54 #topic https://bugzilla.redhat.com/show_bug.cgi?id=618504 16:03:55 Bug 618504: medium, low, ---, enrico.scholz, NEW, Cannot submit abrt bugs 16:04:25 * jlaska reviewing criteria pages 16:04:48 yeah, that's on beta, i think 16:04:54 I thought so too ... searching 16:05:12 it's a no brainer, if we can't get bug feedback for the beta ... that's not good 16:05:30 ...or i may be on crack 16:05:44 we have alpha anaconda criteria that it must be able to submit bug reports 16:05:51 oh, i see 16:06:07 i proposed criteria for this when it came up at the alpha meetings 16:06:10 but didn't implement them yet 16:06:21 thread - 'Release criteria proposal: automated bug checking tools functionality' 16:06:43 aah okay ... right I thought this topic came up already 16:06:44 the proposal there is that by beta they must be able to report the bugs properly 16:06:59 it got only one reply at the time, a question - no yays or nays 16:07:09 * jlaska hangs head 16:07:17 I'll queue that up for comments adamw 16:07:32 #action jlaska to add feedback to 'Release criteria proposal: automated bug checking tools functionality' 16:07:46 in the meantime, I'm comfortable tentatively approving this for beta. 16:08:00 yeah, me too, let's leave it on the list till we decide on the criterion 16:08:04 Should discussion come back and say this isn't valid criteria for beta, we can re-evaluat next week 16:08:07 adamw: okay 16:08:23 adamw: you're much faster at the bz updates, are you comfortable running that today? 16:09:03 sure. this seems like a somewhat slippery issue, though, it may not actually be affecting everyone. i can't recall if i've filed bugs with abrt in f14 lately... 16:09:38 #agreed 618504 - agreed to leave on the F14Beta list, and review next week pending outcome of improved beta release criteria 16:10:04 adamw: we have abrt test cases on the wiki, howabout a general call for test feedback to determine the extent of this bug 16:10:20 #link https://fedoraproject.org/wiki/Category:ABRT_Test_Cases 16:10:27 might not need a general call, just a quick test 16:10:34 roger 16:11:08 #action 618504 - run through several ABRT test cases to confirm the impact of bug 16:11:32 adamw: you okay moving on? 16:11:44 sure 16:12:31 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027 16:12:33 Bug 621027: medium, low, ---, tcallawa, NEW, Graphical screen in anaconda shows F-13 16:12:54 I have an open action item on this issue from this weeks qa-meeting 16:13:08 I'll take care of this before our monday meeting 16:13:30 right, we still need to set the expectations here together with the graphics team. 16:13:34 probably leave it on the list until then. 16:13:42 To summarize, I believe approval of this issue for F14Beta depends on the discussion with the design-team 16:13:49 adamw: +1 16:14:27 #action 621027 - jlaska will reach out to design-team for guidance on artwork related release criteria 16:14:48 #agreed 621027 - will remain on the list pending review of artwork release criteria 16:14:59 I don't think there is much more to say on this one 16:15:04 that darn cranes at it again 16:15:26 next up ... 16:15:28 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621685 16:15:29 Bug 621685: medium, medium, ---, bcl, MODIFIED, TypeError: sequence item 0: expected string, NoneType found 16:15:58 I'm not quite sure we have specific release criteria to cover this issue 16:16:09 i think you know the most about this one 16:16:19 my understanding of the failure is that any attempts to install to a system with an incomplete previous install (e.g. no /etc/fedora-release), will fail 16:16:25 iirc, it's already fixed in git 16:16:52 fixed in anaconda-14.16-1 16:17:08 to be honest, I think we may have this covered 16:17:19 but this might be a stretch 16:17:24 #info The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations 16:17:33 that's specifically about rescue mode. 16:17:42 if rescue mode fails due to the same bug, sure., 16:17:43 right ... which I haven't confirmed is impacted by this bug 16:17:52 definitely a stretch 16:18:23 this is an edge condition, but it's more common than I thought 16:18:33 it may be under final criterion '# The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above ' but again a bit stretch-y. we might benefit from a specific criterion for handling existing disk contents. 16:19:13 we do havea catch-all for issues that impact many users, right? 16:19:33 howabout this ... let's move to F14Final based on the criteria you listed 16:19:46 if I can confirm whether this also impacts rescue-mode ... I can escalate for F14Beta 16:20:00 in the end ... it's already fixed and will be in the next anaconda build 16:20:14 but it's good to make sure we're capturing this (and similar future) issues properly 16:20:33 yeah, it could be caught under the catchall 16:20:45 yeah, we don't need to worry much about this specific issue 16:21:05 okay, so F14Final? 16:21:18 or leave as is since it's already resolved 16:21:23 (MODIFIED) 16:21:42 * jlaska +1 on F14Final based on criteria you listed above 16:22:47 #agreed 621685 - move to F14Final based on Final criteria that the installer must be able to create any workable partition layout 16:22:55 ok 16:23:02 * jlaska assumes silence is consent ;) 16:23:08 * jlaska prepared with #undo as needed 16:23:23 #topic https://bugzilla.redhat.com/show_bug.cgi?id=622927 16:23:24 Bug 622927: medium, low, ---, rvykydal, MODIFIED, F14 Alpha RC2 - /etc/resolv.conf gets corrupted, cannot download packages 16:24:19 #info This should be fixed in anaconda-14.17-1 (F14 Beta). 16:25:42 hmm, possibly an Alpha criteria - "# The installed system must be able to download and install updates with yum and PackageKit " 16:26:02 but again, a stretch 16:27:01 i'm not entirely clear on the impact here 16:27:05 it doesn't seem particularly obvious 16:27:28 something about Orion's network ... and anaconda is just doing things that NM is supposed to? 16:27:44 does he mean that *the installer* can't download packages (and hence can't complete installation)? 16:27:49 what exactly triggers this problem? 16:27:53 i think we're short of info here 16:28:06 but since it's getting fixed i'm not sure how hard we want to push 16:28:12 ah, you're right, the installer cannot download packages 16:28:50 recommendation? 16:29:53 just leave it for now and wait for it to get fixed 16:29:55 seems simplest 16:29:59 alrighty 16:30:28 #agreed 622927 - unclear what conditions lead up to this failure. However the issue is resolved in next anaconda build 16:30:35 #undo 16:30:35 Removing item from minutes: 16:30:46 #info unclear what conditions lead up to this failure. However the issue is resolved in next anaconda build 16:31:00 #agreed 622927 - leave on F14Beta list 16:31:14 #topic https://bugzilla.redhat.com/show_bug.cgi?id=623126 16:31:17 Bug 623126: medium, low, ---, jforbes, NEW, F14 Alpha CD mediacheck and install fail in KVM guest 16:33:59 If this is a common usage scenario, this may fall under "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology) " 16:34:19 robatino: also confirmed that the problem exists with F14 guest on F14 host 16:34:48 sorry, got a bit busy 16:34:53 jlaska: i also did this by using KVM's nested virtualization, but it was painfully slow 16:34:54 back 16:35:13 I think jforbes can provide some guidance on what release the virt team would target for virt cd-swapping installs 16:35:30 haven't checked with a rawhide "host" yet, would take a few hours 16:35:49 robatino: no worries, I don't think we'd need that 16:36:04 lemme ask jforbes ... I have a feeling this was Final release material when we hit this in F13 16:36:23 if this only happens in virt, i don't think it's a blocker. 16:36:37 realistically, what's the case for installing from split media on a VM? 16:36:48 adamw: testing 16:36:50 the only reason to use split media is if your system has no DVD drive, and you can't have a kvm without a DVD drive. 16:36:56 adamw: fair point ... it's certainly something that QA uses to expedite testing 16:37:27 rather than having to burn media 16:37:28 jlaska: i don't think that's enough to make it a blocker, myself. after all, if it can fail in a KVM but work on real hardware, clearly testing it in a KVM isn't a great test. 16:37:30 kvm + split media does not seem like a real case 16:37:38 outside of testing whether or not split media works 16:37:50 and that includes some fun "issues" with changing isos or physical media during install 16:37:53 within a guest 16:38:01 given that we provide the split media for a very specific case (real hardware with only a CD drive), the best method of testing seems to be to use the actual media 16:38:05 on an actual machine 16:38:07 so it's a question as to whether this should block comes down to '# Bug hinders execution of required Final testplans or dramatically reduces test coverage ' 16:38:10 ? 16:38:23 I don't think this dramatically reduces test coverage 16:38:23 "hinders" seems pretty vague 16:38:25 sounds right. my vote is that it doesn't. 16:38:27 hey jforbes 16:38:48 heya 16:39:00 we've got 2 votes for removing # topic bug from F14Beta ... do you have any opinions on support for CD swapping for virt guest installs? 16:39:10 we could probably clarify that 'hinders' 16:39:17 to me it should be more like 'unavoidably hinders' 16:39:27 i can't do split media testing with this bug since i only test within a VM 16:39:38 a bug should have to really make testing close to impossible before we turn it into a blocker for the release, and this one really doesn't 16:39:49 It should be removed as a blocker, we have someone looking at it, but it is just a release note in RHEL, wont be fied soon 16:39:53 robatino: sure, but we do have the capability to test outside of a KVM *as a team* 16:40:10 alright, 3 +1's for removing from F14Beta 16:40:49 I'm with robatino in that it it puts some roadblocks in front of tests for validating media 16:40:50 Of note, this was actually there in 13 as well, and we came to the same conclusion 16:41:11 jforbes: I remember we had a similiar issue, but forgot the conslusion 16:41:12 there aren't that many people who test split media now 16:41:27 We do have someone looking at it, but it is not of the highest priority 16:41:39 adamw: F14Target 16:41:41 ? 16:42:19 sure, why not. 16:42:34 actually, no, i don't think it even qualifies for that, tbh 16:42:41 #info jforbes notes someone is looking into the issue, but it is not a high priority issue 16:42:49 but hey, add it if it floats your boat =) 16:43:30 #agreed 623126 - does not meet any release criteria, remove from F14Beta 16:44:04 adamw: I don't have strong feelings about it .. just that I'd take it if it turned out to be a simple fix 16:44:09 jforbes: thanks for your input! 16:44:20 #topic https://bugzilla.redhat.com/show_bug.cgi?id=623524 16:44:21 Bug 623524: medium, low, ---, anaconda-maint-list, NEW, Err during filesystem check after upgrading bootloader 16:44:30 jlaska: i'd take it now, i'm not so sure i'd want to take it through a freeze... 16:44:38 NP 16:45:12 adamw: okay 16:45:20 on the face of it this is clearly a blocker, be interesting to know if it happens in all cases though 16:45:33 this bug was filed by Mingtao 16:45:42 if this impacts all upgrades ... "# The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually" 16:46:13 based on the test results wiki, this happens when upgrading and installing a new bootloader 16:46:19 but not when upgrading or skipping the bootloader creation 16:46:30 ok 16:46:39 well, i'd say we take it as a blocker and monitor. 16:46:42 +1 16:47:04 #info # The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually 16:47:33 #agreed 623524 - accepted as a F14Beta blocker .. will continue to monitor impact scope of this issue 16:47:42 #topic https://bugzilla.redhat.com/show_bug.cgi?id=624208 16:47:43 Bug 624208: medium, low, ---, ajax, NEW, [F14 REGRESSION] KDE desktop effects with OpenGL: no display updates 16:48:15 adamw: definitely your territory 16:48:49 I guess the question is how many graphics adapters are affected by this? 16:49:13 well, i'd also like to know exactly how you hit it 16:49:30 if it requires manual intervention at any point to enable the affected desktop effects configuration, it's not a blocker 16:49:59 rdieter any thoughts? 16:51:02 jlaska: whether it's blocker-worthy? (probably not, imo, we've not considered opengl support as blockers before have we?) 16:51:17 rdieter: for me it depends if it's the default config 16:51:20 it is not 16:51:27 ok, then i'd say no blocker 16:51:31 but i'll wait for stefan's reply 16:52:05 I'll be doing more extensive f14-related testing myself (using intel hardware) soon, so will be able to provide more feedback then too. 16:52:11 #info 624208 - wait for feedback from Stefan in the bz 16:52:19 so leave on the list now,pending feedback? 16:52:27 yeah, for now, but we're leaning towards not-a-blocker. 16:52:40 #agree 624208 - on the surface, doesn't appear as a blocker. Waiting on reporter feedback. 16:52:49 last one ... 16:52:55 rdieter: thanks! 16:52:59 #topic https://bugzilla.redhat.com/show_bug.cgi?id=624971 16:53:00 Bug 624971: medium, low, ---, rhughes, NEW, Fail to upgrade with preupgrade-1.1.4-1.fc13 16:54:14 looks like a fairly obvious blocker 16:54:14 rhe identified the specific criteria impacted in comment#1 16:54:23 agreed, well done rhe 16:54:28 oh looky who's here =) 16:54:58 #info The installer must be able to successfully complete an upgrade installation 16:55:01 from a clean, fully updated default installation of the previous stable Fedora 16:55:02 OH SNAP THEY SAW ME 16:55:04 #info release, either via preupgrade or by booting to the installer manually 16:55:07 wwoods: run away! 16:55:08 * wwoods flee 16:55:27 #agreed 624971 - approved as a F14Beta blocker 16:55:32 #topic Open discussion 16:55:51 alright, anything else to discuss here today? 16:56:12 fine art, politics, long walks on the beach? 16:56:41 * jlaska will close out the meeting in 1 minute 16:57:14 30 seconds ... 16:57:18 see! he's after my maidenhead! 16:57:20 zodbot, protect me 16:57:27 goodness 16:57:45 Okay ladies and gentlemen, thanks all for your attendance 16:57:52 I'll send the minutes to test@ and devel@ for review 16:58:05 now back to regularly scheduled systemd discussions 16:58:10 #endmeeting