17:00:58 <jreznik> #startmeeting F20 Beta Go/No-Go meeting
17:00:58 <zodbot> Meeting started Thu Nov  7 17:00:58 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:00 <jreznik> #meetingname F20 Beta Go/No-Go meeting
17:01:00 <zodbot> The meeting name has been set to 'f20_beta_go/no-go_meeting'
17:01:11 <jreznik> #topic Roll Call
17:01:39 <nirik> morning everyone
17:01:41 * satellit listening
17:02:11 <jreznik> morning nirik
17:02:29 * nirik hopes for good news, but I guess we will see.
17:02:52 * mkrizek is here
17:03:00 * kparal here
17:04:25 <jreznik> adamw, tflink: are you here too? bunch of blockers, we need more people
17:05:03 * jreznik will wait a few more minutes for more people to show in
17:05:26 <nangthang> .fas nangthang
17:05:26 <zodbot> nangthang: nangthang 'Thang Nguyen Nang' <thangnguyennang1988@gmail.com>
17:05:32 <nangthang> hi everyone
17:07:15 <jreznik> #topic Purpose of this meeting
17:07:19 * tflink is around
17:07:42 <jreznik> #info Purpose of this meeting is to see whether or not F20 Beta is ready for shipment, according to the release criteria.
17:07:44 <jreznik> #info This is determined in a few ways:
17:07:46 <jreznik> #info No remaining blocker bugs
17:07:48 <jreznik> #info Test matrices for Beta are fully completed
17:07:49 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist
17:07:51 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_RC5_Install
17:07:52 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_RC5_Base
17:07:54 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_RC5_Desktop
17:08:03 <jreznik> #topic Current status
17:09:04 <jreznik> there seems to be one bug FailedQA - #1008633
17:09:19 <jreznik> and bunch of proposed blocker bugs from this morning
17:09:59 * roshi is here
17:10:30 <jreznik> so it does not look well today again
17:11:13 <jreznik> but first, let's try to go through the proposals... tflink, kparal if I can ask you to lead the blocker review session...
17:11:19 <jreznik> #chair tflink, kparal
17:11:19 <zodbot> Current chairs: jreznik kparal tflink
17:11:40 <kparal> sorry everyone, most of the bugs were discovered today. either those are recent regression or we really failed in the last weeks to discover them
17:11:44 <tflink> kparal: are you running it or should I?
17:12:15 <kparal> tflink: please do if you can
17:12:26 <tflink> sure, need a sec to prepare
17:13:45 <tflink> #info up for review today, we have:
17:14:02 <tflink> er, this isn't a review meeting
17:14:05 <tflink> #undo
17:14:05 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x24652650>
17:14:17 <tflink> #info the current blocker status is:
17:14:23 <tflink> #info 6 Proposed Blockers
17:14:24 <tflink> #info 4 Accepted Blockers
17:14:34 <tflink> starting with the proposed blockers
17:14:42 <tflink> #topic (1008732) LUKSError: luks device not configured
17:14:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732
17:14:42 <tflink> #info Proposed Blocker, anaconda, NEW
17:15:54 <nirik> hum.
17:16:52 <jreznik> nirik: yeah, that's the sound I did when I saw proposed blockers showing in the morning...
17:16:56 <nirik> I suppose this is a blocker by technical definition, but I wonder how many people would really hit it... it seems a pretty corner case.
17:17:11 <kparal> I tried to reproduce it but did not hit it
17:17:57 <jreznik> also criterions does not say anything about luks as I read it
17:18:17 * roshi does secretary work
17:18:18 <nirik> 1027682 looks very similar?
17:18:36 <kparal> all of today's bug will look very similar, actually
17:18:39 <nirik> and 1027947 is the non encrypted version
17:19:02 <kparal> I assumed they are caused by the same underlying problem, but dlehman says "partitioning is fscking complicated" :)
17:19:10 <nirik> yeah, no kidding. ;(
17:19:47 <kparal> I assume this (1008732) happens only if you play with existing encrypted LVM and try to reuse some of its partitions in a specific way
17:20:12 <nirik> well, I'll propose that this is enough of a corner case that we can release note it/not block. But others may disagree. ;)
17:20:13 <kparal> i.e. not that common use case, but not completely corner case
17:20:35 <nirik> and work around would be: wipe the disk and try again?
17:20:38 <jreznik> what would help us a lot if dlehman could go through the list and mark them as important/less important/screw it... not sure we can decide on that without input form devs
17:21:12 <nirik> s/disk/partition table or partitions/
17:21:15 <dlehman> the luks one could be a final blocker but not beta IMO
17:21:42 <kparal> I'm OK with putting this one to CommonBugs
17:22:03 <dlehman> is the beta criteria for custom "everything attempted must work" ?
17:22:28 <kparal> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning
17:22:40 <kparal> there is " Assign mount points to existing storage volumes "
17:22:49 <kparal> but there is also resize in place, which is Final
17:22:59 * croberts is here running late
17:23:08 <kparal> and it was not really trivial to hit this, so we have no further info of the minimal root cause
17:23:22 <tflink> dlehman: that's final: "
17:23:24 <kparal> my feeling is that if you don't try to resize, it will not blow up
17:23:24 <tflink> The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:23:33 <tflink> whoops, that got broken up
17:24:09 <jreznik> I think we are reaching the agreement this is more for final
17:24:17 <kparal> yeah, that one above is a catch-all, to be used with consideration
17:25:04 <jreznik> so final?
17:25:08 <tflink> it's hard to say for certain without knowing the minimal reproducer, but with our current knowledge, I'm OK with final
17:25:13 * nirik is ok with that.
17:25:21 <kparal> yeah, let's propose
17:25:22 <tflink> anyone -1 on final?
17:25:44 <kparal> rather anyone +1 on Beta?
17:25:47 <nirik> we can always reeval
17:25:58 <nirik> really all we need to know now is beta blocker or not. ;)
17:26:00 <tflink> proposed #agreed 1008732 - RejectedBlocker (beta) AcceptedBlocker (final) - Violates the following F20 final release criterion: "
17:26:07 <tflink> bah
17:26:17 <jreznik> nice criterion
17:26:26 <tflink> proposed #agreed 1008732 - RejectedBlocker (beta) AcceptedBlocker (final) - Violates the following F20 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."
17:26:51 <tflink> ack/nak/patch?
17:27:12 <nirik> ack
17:27:13 <jreznik> ack
17:27:21 <roshi> acn
17:27:25 <roshi> ack
17:27:39 * roshi just threw in the acn for good measure
17:27:41 <kparal> ack
17:27:42 <tflink> #agreed 1008732 - RejectedBlocker (beta) AcceptedBlocker (final) - Violates the following F20 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."
17:27:52 <tflink> #topic (978298) AttributeError: 'DeviceFormat' object has no attribute 'peStart'
17:27:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=978298
17:27:57 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:28:50 * nirik re-reads
17:29:34 <jreznik> seems like we already touched this one in f19
17:30:05 <nirik> yeah, it's an old f19 one.
17:30:13 <tflink> if 2 or 3 people have hit this since F19 ... not sure it needs to be a beta blocker
17:30:33 * nirik agrees.
17:30:34 <kparal> we actually rejected this as a blocker for F19 Final
17:30:51 <nirik> right. -1 blocker.
17:30:54 <tflink> due to the risk of the complex fix that late in teh cycle, no?
17:31:13 <nirik> and how hard it is to hit
17:31:15 <kparal> ah, we rejected it as F19 Final FE
17:31:22 <kparal> it seems it was not proposed as a hard blocker?
17:31:50 <kparal> no it wasn't
17:31:58 <kparal> I don't think this needs to block F20 Beta
17:32:01 <tflink> -1
17:32:19 <kparal> since more people hit this, it might be good to consider for F20 Final. but -1 for Beta
17:32:19 <jreznik> as always - we should somehow track unfixed issues from older releases we say "not a blocker"... as some of these bugs are hunting us
17:32:29 <jreznik> but -1 Beta now
17:33:15 <tflink> proposed #agreed 978298 - RejectedBlocker - This use case was deemed too much of a corner case to justify blocking the release of Fedora 20 beta.
17:33:16 <kparal> roshi: are you doing a secretary?
17:33:27 <roshi> yup
17:33:31 <kparal> great thanks
17:33:32 <tflink> ha, should have asked him that in here instead of via PM :)
17:33:43 <tflink> ack/nak/patch?
17:33:57 <nirik> ack
17:34:20 <jreznik> ack
17:34:24 <kparal> ack
17:34:27 <tflink> jreznik: I can come up with a list of rejected F19 blockers that are still open
17:34:32 <tflink> #agreed 978298 - RejectedBlocker - This use case was deemed too much of a corner case to justify blocking the release of Fedora 20 beta.
17:34:43 <tflink> if that would be helpful, should be a quick bz query
17:35:10 <tflink> #topic (1027682) DeviceError: ('Cannot destroy non-leaf device', 'fedora_dhcp-29-193-root')
17:35:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027682
17:35:14 <nirik> if you could, and someone(s) could go and confirm they hit f20, it could be useful.
17:35:16 <tflink> #info Proposed Blocker, anaconda, NEW
17:35:16 <jreznik> tflink: would be worth trying it
17:35:35 <nirik> -1 blocker here for the same reasons as the first one.
17:36:10 <kparal> comment 16 has a simpler reproducer. encryption is not necessary to hit this
17:36:42 <kparal> the core problem is in the resize attempt. if I don't do it, it doesn't crash
17:36:45 <tflink> sounds like a resize issue?
17:37:36 <kparal> might be. actually in this case I also marked the new partition to be encrypted (not sure whether it is essential for causing this)
17:37:50 <kparal> but the original system can be unencrypted
17:38:15 <dlehman> pretty sure something's got to be encrypted for an LV named "root" to be a non-leaf device
17:38:34 <tflink> didn't we decide that resize was generally a final issue?
17:38:39 <kparal> if we -1 this, we probably need to document that any resize operation on LV might cause crashes (most probably together with some encryption)
17:39:10 <kparal> tflink: yes, but always talked more or less about ntfs only. other resize operations usually work
17:39:19 <kparal> AFAIK
17:39:28 <tflink> does resize work for non-encrypted partitions?
17:40:15 <kparal> often it doesn't, but I proposed that as Final: https://bugzilla.redhat.com/show_bug.cgi?id=1027714
17:41:03 <kparal> I guess several of these bugs are just different symptoms of some underlying problem
17:41:25 <nirik> yeah
17:41:41 <adamw> good lord, what the hell sliding timezone is this meeting on? it's 9:40 here!
17:41:49 <adamw> mumble mumble
17:41:56 <kparal> adamw: morning
17:42:13 <adamw> morning
17:42:28 <tflink> adamw: the sliding timezone known as UTC
17:42:46 <jreznik> hey adamw, timezones... but I'm open to move utc times too if it would help you, I just thought 9 am is still reasonable time :D
17:43:14 <adamw> depends whether we did all night validation or not :P
17:43:19 <adamw> anyhoo, sorry, back to the bug
17:44:44 <tflink> so I see two questions: is resize of ext4 partitions worthy of blocking beta? and is resizing encrypting partitions worthy of blocking beta?
17:44:45 * jreznik understands
17:45:03 <adamw> historically we've always said 'no'.
17:45:10 * nirik says no no. ;)
17:45:22 <tflink> is anyone +1 on this?
17:45:27 <adamw> is dlehman here, or are we anaconda-representation-less?
17:45:33 <tflink> adamw: he's here
17:45:42 <jreznik> adamw: he's trying to help us (so thanks goes to dlehman)
17:46:12 <adamw> cool, just checking if we have a devel perspective on the bugs
17:46:20 <kparal> I can quickly try to repeat that without any encryption
17:46:38 <kparal> 2 minutes tops
17:46:50 <adamw> sounds good
17:46:56 <jreznik> if the answer for that question is no, what would it would change? but yeah, try it
17:47:10 <kparal> if the answer is no, then nothing :0
17:47:11 <kparal> :)
17:48:04 <tflink> proposed #agreed 1027682 - RejectedBlocker - Resize issues are generally considered for blocking final release, not beta. As such, this bug is rejected as a release blocking issue for F20 beta but please re-propose as a Final Blocker and mark for inclusion in CommonBugs.
17:48:30 <jreznik> ack
17:49:18 <kparal> crashes
17:49:20 <kparal> reported as 1028110
17:49:53 <nirik> ack
17:49:55 <kparal> I found out that I already tried that today :)
17:50:00 <kparal> I'm ack for this
17:50:07 <adamw> ack, but commonbugs of course
17:50:09 <kparal> we can discuss 1028110 separately if you want
17:50:33 <tflink> #agreed 1027682 - RejectedBlocker - Resize issues are generally considered for blocking final release, not beta. As such, this bug is rejected as a release blocking issue for F20 beta but please re-propose as a Final Blocker and mark for inclusion in CommonBugs.
17:50:54 <tflink> #topic (1027846) PartitionException: Partition is not part of the disk it is being removed from
17:50:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027846
17:50:59 <tflink> #info Proposed Blocker, anaconda, NEW
17:52:38 <nirik> nice... this is a f18 bug?
17:52:48 <kparal> why?
17:52:53 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=865653 seems to be very similar/the same?
17:53:30 <adamw> probably one of those ones with a genericish error message
17:54:21 <kparal> reproduced, exactly as in comment 12
17:54:50 <adamw> i'm probably -1 for bugs which require you to pass through the partitioning phase twice, as i'm sure there's all sorts of crap lurking there
17:55:06 <adamw> but...yeah, crasher.
17:55:50 * jreznik thinks the same as adamw, it's still beta...
17:55:52 <nirik> yeah, -1 blocker here...
17:56:00 <tflink> -1 blocker, +1 commonbugs
17:56:09 <kparal> please add a note to propose for final
17:56:12 <kparal> -1 beta
17:56:31 <kparal> (or do it as a part of secretary work, thanks)
17:56:44 <jreznik> -1 but check for final
17:56:58 <jreznik> or even better, do it final now
17:57:00 <adamw> i kinda think we should just re-set the storage options whenever the user re-enters the spoke, but eh.
17:57:04 * roshi adds note
17:57:12 <tflink> proposed #agreed 1027846 - RejectedBlocker - Going through the partitioning spoke multiple times was deemed not worthy of blocking beta and thus, this bug is rejected as a blocker for Fedora 20 beta. Please re-propose as a blocker for F20 final and mark for inclusion in CommonBugs.
17:57:23 <roshi> -1 blocker and ack
17:57:28 <nirik> ack
17:57:50 <kparal> ack
17:57:52 <jreznik> ack
17:57:59 <tflink> #agreed 1027846 - RejectedBlocker - Going through the partitioning spoke multiple times was deemed not worthy of blocking beta and thus, this bug is rejected as a blocker for Fedora 20 beta. Please re-propose as a blocker for F20 final and mark for inclusion in CommonBugs.
17:58:07 <tflink> #topic (1027947) ValueError: new size same as old size
17:58:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027947
17:58:07 <tflink> #info Proposed Blocker, anaconda, NEW
17:58:54 <tflink> this seems like a variation on resize issues
17:59:01 <nirik> yeah.
17:59:13 <tflink> not quite the same, but not sure this is beta blocker material
17:59:13 <jreznik> and similar to that failed qa bug?
17:59:20 <tflink> failed qa bug?
17:59:46 <jreznik> 1008633
17:59:52 <kparal> it's all connected with resize operation
17:59:57 <nirik> this seems more possible for people to hit easily...
18:00:04 <nirik> but still I think I'm -1 for beta.
18:00:23 <jreznik> but seems like the agreement was more resize is not beta material...
18:00:29 <adamw> yeah, though it is unfortunate that this is quite so...crashable.
18:02:43 <jreznik> any other thoughts?
18:02:43 <roshi> -1 for beta as it's a resize issue, but I agree with adamw
18:02:54 <kparal> if we are firm with resize being not beta material, then -1 even here, sure
18:03:03 <adamw> dlehman: has this gotten worse in f20 or are we just testing resize harder?
18:03:14 <kparal> but I'm actually not so sure about this approach, maybe we should consider some resize operation to work in Beta in the future
18:03:49 <kparal> hm, actually, this is not resize criterion but "" Reject or disallow invalid disk and volume configurations without crashing. ""
18:04:02 <kparal> which is Beta
18:04:09 <dlehman> adamw: not sure
18:04:18 <kparal> 130 GB partition on a 20 GB HDD is an invalid operation
18:04:22 <adamw> kparal: there's kind of a tension there
18:04:59 <kparal> let's relax and have a beer, then
18:05:07 <adamw> there's clearly some issues with the criteria as written...as there always are with the storage criteria :/
18:05:08 <tflink> yeah, I can see a typo causing a user to hit this but you'd still have to be resizing to hit it, I think
18:05:17 <jreznik> kparal: in five minutes? where? :)
18:05:19 <roshi> kparal +1
18:05:30 <adamw> i mean, a tension between different elements of the criteria
18:05:54 <adamw> on the one hand we had a clear intent not to cover resizing till final, on the other hand, that criterion as written certainly looks like it ought to apply to this kind of scenario
18:05:55 <kparal> I'd really love to release today, so.... I don't object
18:06:00 <dlehman> the bug that allowed you to try resizing to impossibly large size has been fixed
18:06:24 * adamw can't think of an easy and clear way to improve the wording off the top of his head :/
18:06:29 <kparal> dlehman: jsedlak seems to still hit it in that bug report
18:06:40 <jreznik> dlehman: https://bugzilla.redhat.com/show_bug.cgi?id=1008633#c17
18:06:51 <tflink> kparal: I suspect that he means it has been fixed in a newer version than what's in RC5
18:06:57 <kparal> ah
18:08:00 <tflink> or not, but we're getting off in the weeds a bit
18:08:21 <tflink> it sounds like we're mostly -1 blocker on this?
18:08:22 <adamw> i guess broadly we can release with a big note saying 'for pete's sake don't try resizing anything', or slip again :/
18:08:25 <dlehman> oh, there are two bugs that fit that description
18:08:35 <adamw> i guess i am, but it's a bit of a 'let's just ship the thing' vote
18:09:00 * nirik is -1 blocker on it.
18:09:06 * kparal agrees with adamw
18:09:17 <dlehman> from my perspective it seems like there are about five times as many fedora qa people working on anaconda in f20 compared to any previous release
18:09:51 <jreznik> dlehman: testing for free!
18:10:03 <kparal> dlehman: especially today, right? :)
18:10:19 <adamw> we have more people than before this cycle indeed, i only wish it was 5x as many though :)
18:10:28 <dlehman> well, what you have is 20 qa guys reporting bugs and 1 (count it: one) developer trying to untangle the reports and fix the bugs
18:10:37 <kparal> that's what happens if I instruct 5 people to "verify this thing"... a 5 new bugs are discovered
18:10:46 <adamw> kparal: hehe
18:11:05 <jreznik> dlehman: get these 5 to write tests, it would be a great deal for both sides (and me too)
18:11:11 <adamw> it's an interesting question, though - does having more test resources reveal us to be too strict on the criteria? or what?
18:11:12 <dlehman> it's great, but I am not going to start working 20 hrs each day to keep up
18:11:26 <adamw> dlehman: is clumens on something else atm?
18:11:40 <dlehman> nobody else has ever worked seriously on storage
18:11:41 <jreznik> adamw: a lot of bugs are now in blivet, so dlehman...
18:11:58 <adamw> i always had this image of dlehman and clumens being the Storage Guys, but apparently not
18:11:59 <tflink> proposed #agreed 1027947 - RejectedBlocker - While unfortunate, this is a resize issue at heart and that is not covered by the F20 beta release criteria and thus, is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:12:08 <roshi> ack
18:12:16 <jreznik> ack
18:12:19 * tflink wonders if this is an even stronger case for having a better system of triagers
18:12:43 <tflink> other ack/nak/patch?
18:13:08 <jwb> if you want an example of a worst case testers:developers ratio, look at the kernel
18:13:23 <jwb> i'm honestly surprised we don't hit way more blockers
18:13:24 <kparal> ack
18:13:41 <jreznik> jwb: it's not as visible during install phase I'd say
18:13:52 <nirik> ack
18:14:00 <tflink> #agreed 1027947 - RejectedBlocker - While unfortunate, this is a resize issue at heart and that is not covered by the F20 beta release criteria and thus, is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:14:11 <tflink> #topic (1027965) CreateException: Can't have a partition outside the disk!
18:14:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027965
18:14:16 <tflink> #info Proposed Blocker, anaconda, NEW
18:14:43 <adamw> jreznik: also, kernel bugs are almost universally 'hardware-specific' in some way
18:14:58 <adamw> if we were stricter about blocking releases for hardware not working we can come up with as many blockers as you like =)
18:15:00 <jreznik> another instance of previous one?
18:15:14 <kparal> resize again, yes
18:15:17 <jreznik> adamw: right
18:15:20 <kparal> might be the same or not
18:15:22 <tflink> jreznik: not quite, but similar
18:15:43 <tflink> i read this as a bug about being able to create the huge lv on a tiny disk
18:15:54 <dlehman> no
18:15:55 <tflink> the other one was about the crash when attempting to fix the mistake
18:16:10 <dlehman> it's a programming error where something has an outdated reference to something else
18:16:21 <kparal> tflink: this is not LVM, it's standard partition
18:16:34 <kparal> and it seems only be connected with resize operation
18:16:43 <kparal> i.e. you need to take an existing one and try to enlarge it
18:16:50 <kparal> over the available size
18:17:05 <nirik> -1 blocker for the same resizey reasons as previous. ;)
18:17:20 <tflink> if we've rejected the rest of the resize bugs, I can't really see accepting this one
18:17:23 <dlehman> guys, this is fun but as you know I have a bit of work to do, so I'm going to leave now
18:17:26 <tflink> is anyone +1 on this for beta?
18:17:34 <adamw> do we have anything c oming up which isnt' a resize issue...too late.
18:17:39 <adamw> -1 with the others
18:17:46 <kparal> -1
18:17:47 <tflink> nope, this is the last proposed blocker on my list
18:18:03 <jreznik> -1
18:18:32 <kparal> if I create a new partition, max size is correctly enforced
18:18:33 <tflink> proposed #agreed 1027947 - RejectedBlocker - While unfortunate, this is a resize issue which is not covered by the F20 beta release criteria. Thus, it is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:18:41 <kparal> ack
18:18:41 <jreznik> ack
18:19:06 <adamw> ack
18:19:27 <tflink> whoops, wrong bzid
18:19:39 <adamw> shows how closely we check
18:19:47 <tflink> proposed #agreed 1027965 - RejectedBlocker - While unfortunate, this is a resize issue which is not covered by the F20 beta release criteria. Thus, it is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:19:58 <roshi> ack
18:20:03 <tflink> #agreed 1027965 - RejectedBlocker - While unfortunate, this is a resize issue which is not covered by the F20 beta release criteria. Thus, it is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:20:14 <tflink> that's all of the proposed blockers on my list
18:20:27 <kparal> now we need to discussed reopened accepted blocker - 1008633
18:20:44 <tflink> #topic (1008633) ValueError: invalid target size request
18:20:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008633
18:20:44 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
18:21:40 <kparal> abrt directed mkrizek to this bug
18:21:48 <kparal> but it might be a different issue with the same traceback
18:22:09 <adamw> do we have the logs?
18:22:11 <jreznik> but resize again from description
18:22:15 <kparal> adamw: yes, last comment
18:23:07 <nirik> 100TB is a nice large amount. ;)
18:23:30 <kparal> the funny thing is that we already accepted similar "resize" bug as a blocker not that long time ago :)
18:23:48 <adamw> yay for consistency :(
18:23:56 <adamw> i think i wasn't there to 'massage' things :P
18:24:30 <kparal> let's massage this one
18:24:39 <kparal> another chance for you
18:24:47 <tflink> same justification as the last several resize bugs?
18:24:53 <kparal> I guess so
18:25:02 <jreznik> different time without such push on the release and I know you guys likes to be exact :)
18:25:09 <kparal> but we should have a big red warning in the beta release notes
18:25:13 <tflink> adamw: does our "massage expert" have any other ideas?
18:25:30 <tflink> kparal: yeah, "for the love of pete, don't even try to resize stuff in the installer" :)
18:25:42 <adamw> yeah, i think that's where we're headed
18:25:50 * nirik nods.
18:25:54 <adamw> either we take all of these as blockers and implement a month of project colada, or go with the banner ad
18:25:58 <nirik> unless there's some cases where resizing actually works. ;)
18:26:08 <nirik> -1 blocker. ;)
18:26:10 <adamw> this one sounds rather a lot like one from earlier, doesn't it?
18:26:17 <adamw> nirik: probably hidden somewhere :)
18:26:33 <adamw> in general all of these should be re-proposed for final even where we're not noting it, i think
18:26:39 <kparal> nirik: actually I think you won't find that one in current Beta
18:26:43 <nirik> in a nice world all these would get fixed in the same backend/code parts... but sadly...
18:26:59 <tflink> proposed #agreed 1008633 - RejectedBlocker - While unfortunate, resize issues are not covered in the F20 beta release criteria. Thus, this bug is rejected as a release blocking issue for F20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:27:03 <jreznik> kparal: I'll talk to docs guys, make sure it will be there
18:27:05 <nirik> ack
18:27:08 <kparal> ack
18:27:12 <roshi> ack
18:27:21 <jreznik> ack
18:27:37 <tflink> at the rate we're going, this could end up being a problem for final - methinks we have some upcoming discussion on what kinds of resize are supported and what isn't
18:27:46 <tflink> #agreed 1008633 - RejectedBlocker - While unfortunate, resize issues are not covered in the F20 beta release criteria. Thus, this bug is rejected as a release blocking issue for F20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs
18:28:09 <tflink> ok, that's all of the accepted blockers which are not "VERIFIED"
18:28:47 <jreznik> tflink: sure, these resize issues looks like something we should focus on with anaconda guys
18:28:54 <jreznik> (better dlehman)
18:30:12 <jreznik> so if I count it correctly, we're blocker free
18:30:53 <kparal> yes
18:31:02 <kparal> surprisingly
18:31:04 <jreznik> #topic Current status
18:31:16 <adamw> zoiks
18:31:24 <nirik> hurray!
18:31:47 <jreznik> #info After the blocker review, there are no known accepted and not fixed blocker bugs
18:31:53 <roshi> all bugs updated
18:31:57 <jreznik> thanks roshi
18:32:19 <roshi> :)
18:32:37 <jreznik> #topic Test matrices coverage
18:33:52 <jreznik> I see coverage looks pretty good, is there anything that still needs to take a look?
18:34:25 <kparal> I think we are covered
18:34:31 <adamw> not seeing anything missing
18:34:35 <adamw> cloud and arm folks happy?
18:34:44 * nirik tested in openstack. worked fine.
18:35:30 <jreznik> and pwhalen tested arm quite a lot
18:35:49 <tflink> ec2 worked for me with some simple tests
18:35:57 <pwhalen> RC5 testing mostly complete now
18:36:21 <jreznik> pwhalen: are you ok with current arm coverage?
18:36:51 <pwhalen> yes, everything looks good for arm, installs, images
18:37:46 <jreznik> so qa seems happy with current coverage, right? before infoing it
18:38:36 <adamw> yup
18:38:51 <adamw> desktop login is missing for kde...hm
18:40:53 <jreznik> do you want to try it or we believe it works? looking on ARM...
18:41:26 <kparal> it works in general, just nobody wants to go through that super-complex test
18:41:51 <adamw> heh
18:41:54 <adamw> it's not that bad
18:42:25 <jreznik> #info QA is ok with RC5 test matrices coverage
18:42:28 <adamw> in my tests keymap for encryption passphrase was broken agaiun, but i decided to keep quiet about that...
18:42:38 <jreznik> adamw: pss!
18:42:43 <roshi> I've been using KDE for the past few RC's and login seems to work fine
18:42:50 <adamw> ok
18:43:26 <adamw> roshi: it's a keyrmap test and DM function test too, but it's seemed OK in what i've seen
18:43:32 * adamw fires up a VM quickly, i'll yell if it's busted
18:43:33 <jreznik> so anything else or I can move to the topic everyone is looking for?
18:46:17 <kparal> jreznik: go
18:47:04 <jreznik> #topic Go/No-Go decision
18:48:13 <jreznik> ok, so here we are
18:48:24 <nirik> go!
18:48:27 <adamw> assuming my KDE test is ok, a muted go
18:49:20 <adamw> clearly we need to work on the criteria some more
18:51:14 <jreznik> proposed #agreed Fedora QA and Fedora Development are Go
18:52:23 <adamw> ack
18:52:33 <jreznik> nirik: ^^^
18:52:34 <pwhalen> ack
18:53:28 <roshi> ack
18:53:45 <kparal> ack
18:54:42 <jreznik> I expect nirik would be ok with that as he said go above :) not to prolong it more than we need
18:55:01 <jreznik> #agreed Fedora QA and Fedora Development are Go
18:55:09 <nirik> sorry, stepped away for a min.
18:55:14 <nirik> ack
18:55:22 <jreznik> #action jreznik to announce the Go decision
18:55:40 <jreznik> thanks guys!
18:55:45 <jreznik> #topic Open floor
18:56:23 <jreznik> probably two topics, we should follow up with dlehman about that resize bugs + clear criteria for final
18:57:36 <jreznik> and also fesco approved that request from the previous week to shorten the period between beta and final by one week - with a bunch of resize issues, do we want to try it?
18:58:03 <jreznik> and I was a bit pesimist in the ticket https://fedorahosted.org/fesco/ticket/1191
18:58:32 <nirik> It's not really easy to say until we know how hard it will be to fix those issues at this point.
18:59:02 <jreznik> yep, that's why I ask for more thoughts
18:59:20 <jreznik> without that week, we don't have any buffer for final slips...
18:59:42 <jreznik> if we shorten it and slip because of it, we would be in the same situation, so...
19:01:03 <adamw> i'm not sure anyone except the anaconda team  can answer that question with specific detail
19:01:08 <adamw> i can answer it with general scepticism if you like ;)
19:01:40 * nirik personally things we should keep the shortened schedule... moving it out makes little sense.
19:02:12 <jreznik> nirik: not sure I understand you correctly now
19:02:40 <jreznik> adamw: that's a good point
19:03:07 <nirik> well, we shortened the period between beta and final freeze right?
19:03:18 <adamw> nirik: if we were sure we'd slip anyway then pushing the schedule out saves QA a week of pointless effort, but eh
19:03:57 <jreznik> nirik: fesco approved that proposal, now the question is - do we want to proceed with it?
19:04:21 <nirik> adamw: I really don't think we can know that without a time machine. ;)
19:04:22 <jreznik> as currently ga is Dec 17, if we use it, it will be Dec 10, that will give us one week buffer
19:04:29 <nirik> jreznik: yes. I think we do.
19:05:39 * jreznik would like to announce it asap in that case
19:06:00 <jreznik> but in worst scenario it would not work, we would be back to Dec 17
19:08:24 <jreznik> ok, I take it as we will use shortened beta to final cycle
19:08:48 <adamw> we'll yell if it looks untenable
19:09:11 <jreznik> thanks guys for coming, I'm still a bit surprised we were able to release it today :D
19:09:20 <jreznik> adamw: ok, please do so
19:09:28 <croberts> i will post the meeting notes to the magazin site
19:09:44 * jreznik is going to end the meeting in 3...
19:09:49 <jreznik> croberts: thanks
19:10:08 <jreznik> (not sure it's interesting story to read before sleep but :)
19:10:20 * croberts laughs
19:12:15 <jreznik> 2...
19:13:07 <jreznik> 1...
19:13:50 <jreznik> thanks again
19:13:52 <jreznik> #endmeeting