17:00:23 <jreznik> #startmeeting F20 Beta Go/No-Go meeting
17:00:23 <zodbot> Meeting started Thu Oct 31 17:00:23 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:29 <jreznik> nangthang: hi, yes :)
17:00:39 <jreznik> #meetingname F20 Beta Go/No-Go meeting
17:00:39 <zodbot> The meeting name has been set to 'f20_beta_go/no-go_meeting'
17:00:53 <jreznik> #topic Roll Call
17:01:04 <nangthang> hi
17:01:14 * satellit_ listening
17:01:36 <nirik> hello
17:01:42 <nangthang> I'm Thang. I am living and working in Hanoi, Vietnam. Nice to meet everyone :)
17:01:53 <jreznik> hey nangthang!
17:02:03 * pwhalen is here
17:02:14 * tflink is here
17:02:18 <nangthang> I'm a Fedora Ambassador :)
17:02:21 <nangthang> eof
17:02:57 <jreznik> ok, seems like people are showing here
17:04:41 * roshi is here
17:04:46 <jreznik> #topic Current status
17:04:52 <jreznik> #undo
17:04:52 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x3663ddd0>
17:05:00 <jreznik> #topic Purpose of this meeting
17:05:24 <jwb> i'm here because there is no reason for me not to be
17:05:37 <jreznik> #info Purpose of this meeting is to see whether or not F20 Beta is ready for shipment, according to the release criteria.
17:05:38 <jreznik> #info This is determined in a few ways:
17:05:40 <jreznik> #info No remaining blocker bugs
17:05:41 <jreznik> #info Test matrices for Beta are fully completed
17:05:43 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist
17:05:44 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_TC6_Install
17:05:46 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_TC6_Base
17:05:47 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_TC6_Desktop
17:06:08 <jreznik> #topic Current status
17:06:57 <robatino> the first item on that list should be "there exists an RC"
17:06:58 <jreznik> well, the current situation is - we're waiting for possible RC1 (or TC7) - it depends on the pungi fix
17:07:18 <jreznik> robatino: it's worth adding it to the list
17:07:55 <jreznik> #link https://fedorahosted.org/rel-eng/ticket/5787
17:07:58 <robatino> since the links need to refer to one
17:09:33 <jreznik> for pungi fix, tflink just told me, dgilmore is not sure which patch from dmach fixes that issue
17:11:35 <jreznik> so for now, we can go through blockers and after that we can try to deal with this situation - tflink, could you do the blocker bugs part?
17:12:10 <jreznik> #chair tflink
17:12:11 <zodbot> Current chairs: jreznik tflink
17:12:46 <tflink> sure, you 'd think that I'd know to have that ready for go/no-go by now :)
17:14:06 <tflink> #topic (1024144) SizeNotPositiveError: spec= param must be >=0
17:14:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1024144
17:14:07 <tflink> #info Proposed Blocker, anaconda, NEW
17:15:33 * jreznik tends to agree with what cmurf said in his latest comment
17:15:37 * cmurf is here if there are questions on this
17:15:56 <tflink> I think this gets back to the conversation that got started over what anaconda really needs to support wrt layouts it didn't create
17:16:18 <cmurf> it did create the layout
17:16:36 <cmurf> i added an LV
17:17:40 <cmurf> what if I added a regular LV or a regular partition and the installer crashed?
17:19:18 <tflink> I suspect that the better question is whether or not lvm thinp is really ready to be in the installer
17:19:27 <cmurf> certainly
17:19:56 <cmurf> i sorta regret i didn't bring this up just before freeze to consider yanking thinp from the UI
17:19:57 * shaiton got an error while deleting all LV.. But I haven't the report :(
17:20:27 <cmurf> but pulling thinp now may be more invasive
17:20:48 <jreznik> really ready or ready enough + documentation (for beta it could be ok)
17:20:59 <cmurf> i agree
17:21:02 <cmurf> leave it in for beta as is
17:21:10 <cmurf> see what more problems we get when more people are using it
17:21:23 <cmurf> decide whether to pull thinp before final
17:22:01 <jreznik> yep
17:22:22 <jreznik> any other thoughts?
17:22:39 <tflink> pulling lvm thinp at this point does seem like a bad idea
17:23:30 <jzb> apologies, here.
17:24:06 <tflink> is it possible to overcommit during install?
17:24:48 <cmurf> in a sense yes, it does allow the overcommit but then tries to make a new VG which it can't do, then make a new pool which it cant do, and a new LV which it can't do. then crashes.
17:25:02 <nirik> would it be possible/less invasive to 'hide' it in the ui?
17:25:02 <cmurf> so it's not possible to successfully overcommit during install
17:25:05 <tflink> but it works with empty disks?
17:25:15 <cmurf> tflink: yes
17:25:20 <cmurf> nirik: uncertain
17:25:52 <cmurf> tflink: and works with "free space" so while i haven't explicitly tested along side windows it should work
17:25:53 <tflink> cmurf: I'm confused, is it possible to overcommit if you start with clean disks?
17:26:01 <cmurf> tflink: no
17:26:21 <tflink> ok, but it is possible to use lvm thinp as long as you don't overcommit
17:26:27 <cmurf> tflink: it must already be overcommited to trigger an additional overcommit
17:26:31 <cmurf> tflink: correct
17:27:17 <cmurf> for beta i think it's unlikely someone will run into this
17:27:35 <cmurf> and even if they do, their existing data isn't compromised
17:28:26 <tflink> do we want to ask the anaconda devs about how bad of an idea it would be to hide thinp?
17:28:31 <cmurf> i think this is a subjective situation. my opinion is that we document and leave it in for beta, collect more test data.
17:29:15 <jreznik> tflink: as I understand it - thinp somehow works, more edge cases than thinp itself not
17:29:34 <nirik> we could ask, but yeah, if it's corner cases it might be enough for beta.
17:29:53 <cmurf> i think it's a problem to release thinp at all for final if it's not in beta
17:30:13 <cmurf> it really ought to be hammered on by other people than QA to be in final
17:30:16 <jreznik> cmurf: well, that would mean no thinp in final...
17:30:36 <tflink> I think that the current level of bugs and the few people testing it are a problem, as well
17:30:36 <cmurf> jreznik: i think we should leave it in for beta for that reason
17:31:43 <tflink> is anyone +1 blocker on this bug?
17:32:16 <cmurf> beta no, final yes
17:32:21 * jreznik is pinging dlehman
17:32:54 <tflink> if we're voting on final right now, I'm -1
17:33:14 <tflink> we need to figure out what we want to do with btrfs and lvm thinp first
17:33:15 <cmurf> meaning you'd leave this bug in for final?
17:33:29 <tflink> ie, tech preview vs. showing by default
17:33:54 <jreznik> tflink: it's a good question - for both thinp and brtfs/tech preview
17:33:55 <tflink> cmurf: as in I'd rather propose it for final and punt until the displayed fs issue is addressed
17:35:05 <cmurf> ok
17:35:13 * jreznik is ok with that too
17:35:47 <cmurf> in any case though, if we hide it for beta i think that commits us to hide it for final
17:35:53 <tflink> so it sounds like most people are +1 on the "this is a corner case since the disk layout was modified outside anaconda and therefore not a beta blocker"?
17:36:05 <cmurf> whereas if we leave as is for beta + document it for beta, we have the option to hide for final
17:36:17 <roshi> ^^ +1
17:36:27 <cmurf> +1
17:36:32 <roshi> that seems to leave us the most room
17:36:39 <jreznik> yep
17:37:04 <tflink> I'm ok with it but that seems to imply that lvm thinp as a whole is a corner case and therefore a tech preview
17:37:13 <tflink> but we can deal with that for final
17:37:38 <cmurf> yes to both
17:37:42 <tflink> someone want to take an #action to bring up the fs stuff with anaconda/fesco/etc ?
17:37:54 <cmurf> i volunteered myself and adamw to do that
17:37:56 <cmurf> :-)
17:38:16 <cmurf> i don't know the protocol
17:38:18 <jreznik> let's try to talk to anaconda guys regarding thinp/brtfs as tech preview
17:38:40 <jreznik> not sure if we need fesco involvement before
17:38:46 <cmurf> yes, definitely dlehman and probably adamw would be involved
17:39:06 <tflink> proposed #agreed 1024144 - RejectedBlocker - This bug involves a disk layout which was modified outside of the installer and thus, is too much of a corner case to block the release of F20 beta. Please re-propose for final.
17:39:13 <cmurf> sorry probably bcl
17:39:38 <roshi> ack
17:39:39 <tflink> #action cmurf and adamw to continue the conversation of whether lvm thinp and btrfs should be tech previews for F20
17:39:42 <nirik> ack
17:39:46 <jreznik> ack
17:39:50 <cmurf> ack
17:39:52 <tflink> #agreed 1024144 - RejectedBlocker - This bug involves a disk layout which was modified outside of the installer and thus, is too much of a corner case to block the release of F20 beta. Please re-propose for final.
17:40:04 <tflink> #topic (967521) /var/log/journal breaks system startup
17:40:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=967521
17:40:04 <tflink> #info Proposed Blocker, plymouth, MODIFIED
17:40:11 <jreznik> cmurf: I can help you too - especially as thinp was f20 change
17:40:32 <cmurf> jreznik: sounds good
17:41:00 <cmurf> so on this one, i still see no justification based on written criteria this is blocker worthy
17:41:01 * roshi secretarializes
17:41:44 <cmurf> see comment 117 for the justification and 121 for my response, and then nothing after that to justify it
17:42:03 <tflink> roshi: thanks
17:42:11 <tflink> is it just making startup slow?
17:42:18 <cmurf> sounds like it
17:42:31 <cmurf> but honestly 140 comments and i can't actually tell...
17:42:57 <cmurf> it's even an open question if we accept it as FE if it's a risky fix, i don't know so we need a plymouth dev to answer that
17:42:59 <tflink> which makes it all the less likely to be a blocker :)
17:44:19 * cmurf is sortof a dick when it comes to proposed blockers that don't have clear justification
17:44:23 <tflink> is anyone +1 on this?
17:44:29 <cmurf> it's like, don't make other people do your homework for you
17:44:30 <nirik> slow boot is no blocker... ;) I guess some folks have said it prevents boot 'sometimes' for them?
17:44:53 <cmurf> nirik: suggested i think but no logs or data showing this or how common it is
17:45:18 <nirik> right, and if it's just 'cycle and reboot and it works the next time' it's less a problem than 'never boots'
17:45:28 * nirik is -1
17:45:28 <tflink> wow, there is a lot of text in this bug
17:45:34 <cmurf> right and it can be fixed with an update
17:45:37 <roshi> I'm still reading
17:45:41 <cmurf> i'm -2 haha
17:46:04 <cmurf> i'm even a -1 FE but i'm open to being convinced otherwise
17:46:07 <tflink> -1 - repropose if they can justify why thi sshould block release
17:46:15 <jreznik> -1/-1
17:46:35 <cmurf> and if the fix is safe and tested
17:46:55 <roshi> -1/-1
17:47:03 <cmurf> we're right about at RC and this is just now coming up?
17:47:16 <cmurf> the bug started in May
17:47:19 <cmurf> it's an F19 bug
17:47:24 <cmurf> pfff
17:47:38 <cmurf> -1/-1
17:48:28 <tflink> proposed #agreed 967521 - RejectedBlocker RejectedFreezeException - Slow bootup is not a blocker or FreezeException worthy issue, especially for an issue that has been around as long as this one has. Please re-propose with a better justification for why this bug should block release if there is more going on than we understand.
17:48:36 <cmurf> ack
17:48:40 <roshi> ack
17:49:01 <jreznik> ack
17:49:50 <tflink> #agreed 967521 - RejectedBlocker RejectedFreezeException - Slow bootup is not a blocker or FreezeException worthy issue, especially for an issue that has been around as long as this one has. Please re-propose with a better justification for why this bug should block release if there is more going on than we understand.
17:50:16 <tflink> ok, that's all of the proposed blockers - moving on to the accepted blockers which are not on_qa or verified
17:50:27 <tflink> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
17:50:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
17:50:32 <tflink> #info Accepted Blocker, anaconda, MODIFIED
17:50:51 <tflink> bah, this moved to ON_QA
17:50:53 <tflink> #undo
17:50:53 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x37c6b6d0>
17:50:55 <tflink> #undo
17:50:55 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2901f4d0>
17:50:58 <tflink> #undo
17:50:59 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x24a9b450>
17:51:13 <tflink> #topic (1000891) DVD is oversized (larger than 4.7 GB)
17:51:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
17:51:14 <tflink> #info Accepted Blocker, distribution, MODIFIED
17:52:09 <tflink> do we know more about the status of this?
17:53:09 <jreznik> it depends on pungi fix, as you said, dennis is not happy with that big fix dan sent to him
17:54:11 <jreznik> (it's how I understand it now)
17:55:49 <roshi> I'm under the same impression
17:56:19 <tflink> #info waiting on a workable fix for pungi in order to be able to move forward on this
17:56:26 <tflink> does that sum things up well enough?
17:56:30 <nirik> yep
17:56:43 <jreznik> on the other hand, what I was told - pungi we use is not on par with his and is lacking a lot of related patches/fixes
17:56:59 <jreznik> so it's the reason why he created a big one update to be picked up
17:57:25 <tflink> so there are 2 upstreams for pungi?
17:57:28 <jreznik> tflink: it's more like - we have working fix but not sure it's something we can use
17:58:19 <jreznik> tflink: one upstream but a lot of development happens downstream :(
17:58:57 <tflink> is there anything else that we need to cover on this?
17:59:46 * tflink assumes not
17:59:50 <jreznik> it's now up to dennis what he thinks about that, also I can ask Dan to create a minimal fix
18:00:35 <cmurf> if RC1 happens today and is perfect is go still possible? what's the cutoff for go?
18:00:38 <tflink> does someone want an #action for poking the people involved?
18:00:48 <jreznik> tflink: me
18:00:55 <tflink> cmurf: I suspect that will be the next topic after blocker bugs
18:01:10 <cmurf> gotit
18:01:14 <tflink> #action jreznik to coordinate with dgilmore and dmach on getting a workable pungi fix
18:01:21 <tflink> anything else on this bug?
18:01:34 <jreznik> (any help welcomed as I'm not sure I won't die again in my bed :)
18:01:53 <jreznik> move on
18:01:59 <tflink> jreznik: you died already?
18:02:14 <jreznik> tflink: yesterday? I feel like several times :D
18:02:16 <tflink> sorry, couldn't resist even though you're ill
18:02:17 <cmurf> it's his 3rd resurrection in 24 hours
18:02:22 <tflink> we have a zombie pm :)
18:02:33 <jreznik> brainz
18:02:56 <tflink> moving on before someone gets eaten :-D
18:02:58 <tflink> #topic (1023767) shim update to 0.5 fails to boot
18:02:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023767
18:02:59 <tflink> #info Accepted Blocker, shim, NEW
18:03:14 <tflink> #info this will be addressed for TC7/RC1
18:03:25 <tflink> i suppose more details would be god
18:03:26 <tflink> good
18:03:28 <tflink> #undo
18:03:28 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2e817750>
18:03:59 <tflink> #info this will be addressed for TC7/RC1 by removing shim-0.5-1 and thus, working around the release blocking behavior
18:04:29 <tflink> #info once the releace blocking behavior has been mitigated, this bug will no longer block release
18:04:44 <tflink> this one's pretty straight-forward, anything else?
18:05:13 <jreznik> pjones wants a different version of shim to be used
18:05:32 <tflink> yeah, that's in the releng ticket
18:06:06 <tflink> but for the purposes of mitigating the blocking behavior, either version would work
18:06:23 <jreznik> and it's even .fc19, I don't see f20 version in koji
18:07:36 <tflink> if there's nothing else, this is the last accepted blocker that's not VERIFIED or ON_QA
18:07:40 <jreznik> so I'd prefer to revert back to that we have before than trying to play with shims
18:08:16 <cmurf> i think so
18:08:28 <cmurf> i can't find the sister bug with the FE but I think it was a final FE request?
18:08:40 <tflink> beta fe request
18:08:47 <cmurf> got it
18:08:50 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1010474
18:09:28 <cmurf> considering how variable UEFI firmware behaviors are in a sense it makes sense to get what they ideally want in beta so as many people are testing it on install media as possible
18:10:15 <cmurf> so yes we could regress to 0.4-1
18:10:44 <cmurf> but ideally… we want 0.5-X to be in beta to get as much install media testing as possible
18:11:11 <cmurf> in many cases shim updated on working install still worked; but failed on install media
18:11:52 <tflink> sure, but that's assuming a shim build can happen fast enough to be included
18:11:58 <cmurf> understood
18:12:49 <jreznik> pjones: hi!
18:12:56 <pjones> What's the confusion?
18:13:33 <tflink> I don't think there's much confusion, just not sure if a fc19 shim build can be used for f20
18:13:52 <tflink> and also not sure how long it takes for shim builds, assuming 0.5-2 fixes the bug
18:14:06 <pjones> It can - but we didn't use it on F19 media on purpose.  There's a bug where it'll give you an incorrect warning message.
18:14:31 <tflink> pjones: isn't the shim version you requested a fc19 build?
18:14:43 <pjones> Right, so if 0.5-2 fixes the bug (which I think it does), then I'll tag that as 0.6 upstream and do a build to be signed.  But that takes some time.
18:14:52 <pjones> tflink: is it?  Let me check and be sure I got the right one.
18:15:02 <pjones> I want the one that's on the F19 /media/.
18:15:09 <cmurf> TC5 = shim-0.4-1.fc19
18:15:13 <pjones> Assuming we can't get the new version in
18:15:41 <pjones> cmurf: right, and it gives the warning about fallback.efi being missing.  Which is true and completely irrelevant and we don't really need every user to see it.
18:16:17 <cmurf> so is it better to regress to 0.4-1.fc19 for beta, or hold beta for 0.5-X?
18:16:22 <cmurf> if it comes to that
18:16:31 <tflink> I see shim-0.2-4.4.fc19 in the releng ticket
18:16:40 <pjones> shim-0.2-4.4.fc19.x86_64.rpm  shim-unsigned-0.2-3.fc18.x86_64.rpm
18:16:45 <pjones> that's the right pair of things.
18:17:14 <jreznik> how risky is to go back to 0.2 from 0.4 that was tested probably in all TCs?
18:17:35 <tflink> ah, so we'd need a different shim-unsigned build as well. does that need to be added to the releng ticket?
18:17:39 <pjones> jreznik: we shipped two distros on it without anybody reporting any bugs?
18:18:10 <pjones> (bugs related to install media, that is)
18:18:31 <pjones> I'd still like to get 0.6-1 in if I can, but I understand we're running awfully late in the schedule.
18:18:41 <pjones> tflink: I suppose it probably does, yes ;)
18:18:42 <jreznik> pjones: we shipped one distro nearly half year ago but I got it as "it's ok"
18:19:08 <pjones> jreznik: no, that build of code is on F18 and F19 media as I recall...
18:19:09 <tflink> doesn't the shim expire at some point?
18:19:17 <pjones> not in any meaningful way, no.
18:19:39 <tflink> ok, I thought that I remembered hearing that it wouldn't work once the cert expired
18:19:52 <pjones> technically there's a validity window on the signing certificate, but anybody is checking those you'll have bigger problems when e.g. video cards stop working.
18:19:56 <tflink> any guesses on a timeline for 0.6-1 build?
18:20:41 <jreznik> as we still did not decide on what we want to do with beta now, so there could be some time, we're also waiting for pungi fix
18:20:44 <pjones> Well, I already built -unsigned.  If all goes well, I'll probably submit it for signing today, and ask them to be quick about it this time, given the very limited changes.
18:21:39 <pjones> That said, I can't determine the signing schedule.
18:21:53 <tflink> ok, so we can revisit once it's been signed
18:22:29 <jreznik> yep, that's everything we can do now
18:22:45 <pjones> Yeah.  And we can always put the various things it fixes in an update, just like we did with 0.2-4.4 (which is fine except for the one warning message)
18:22:55 <pjones> tflink: happen to have the ticket url handy?  I seem to have lost it?
18:23:21 <tflink> pjones: https://fedorahosted.org/rel-eng/ticket/5787
18:23:26 <pjones> thanks
18:23:33 <tflink> np, thanks for the info
18:24:49 <tflink> since we still have unaddressed blockers, qa is no-go
18:25:27 <jreznik> too fast!
18:25:43 <jreznik> #topic Go/No-Go decision
18:25:54 <tflink> since we still have unaddressed blockers, qa is no-go
18:26:01 <cmurf> haha
18:26:05 <cmurf> i count 2?
18:26:22 <jreznik> #info qa is no-go because of unaddressed blockers
18:26:27 <tflink> what's the other one?
18:26:47 <cmurf> actually i only count 1
18:26:50 <cmurf> DVD size
18:26:51 <tflink> the shim blocker is addressed from a practical POV
18:28:05 <cmurf> dvd size is the only one yes?
18:28:15 <tflink> yep
18:29:00 <jreznik> dgilmore is reviewing the code dan sent him
18:29:39 <cmurf> ok so what's the realistic cutoff or is this time now?
18:29:56 <jreznik> so what are our options now? with one week slip we are heading to holidays but we still don't have rc yet and we don't know we get it soon for sure
18:30:20 <tflink> I am very, very strongly against less than a 1 week slip if we do slip
18:30:24 <dgilmore> jreznik: im going to build pungi in teh next 10 minutes
18:30:39 <dgilmore> the code looked okay and most of it is touching paths nit sed in fedora
18:30:46 <nirik> so, I suppose we could have a marathon and keep the meeting open
18:30:56 <cmurf> i'd really rather have hell days of testing than slip to holidays like last year
18:30:59 * nirik isn't really a fan of the idea, but...
18:31:07 <tflink> I'm not sure we have enough people for that
18:31:17 <cmurf> FILLIBUSTER @ GO/NOGO!
18:31:31 <tflink> we're -3 on the redhat folks allocated to fedora qa
18:31:52 <nirik> "I do not like green eggs and ham. I do not like them, sam I am"
18:32:25 <cmurf> nirik: too short for a good fillibuster
18:32:41 <cmurf> cmurf: how to build a car in 24563 steps
18:32:41 <tflink> actually, more like -4 depending on how you count
18:32:50 <jreznik> what needs most of the coverage? DVD?
18:32:58 <tflink> anaconda
18:33:10 <jreznik> and yeah, not verified anaconda bugs
18:33:18 <tflink> there were several blockers addressed in last night's build
18:33:50 <jreznik> seems like trying to make it today is like shooting ourselves to the knee
18:33:57 <cmurf> i'm confident in the verified/qa anaconda bugs being squashed
18:34:00 <nirik> verify sb/shim, dvd/netinstall, anaconda changes (which means most everything)
18:34:00 <robatino> new proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=983110
18:34:09 <cmurf> nooooo!
18:34:26 <tflink> has TC7/RC1 even been started yet?
18:34:28 <jreznik> and I'd say tflink and dgilmore are not a big fans of having less than one week slip (aka trying another go/no-go round tomorrow0
18:34:47 <jreznik> tflink: he's working on pungi right now
18:34:50 <dgilmore> tflink: no the ticket wasnt opened
18:35:15 <tflink> dgilmore: did someone close it again after last night?
18:35:41 <tflink> it's open
18:35:44 <dgilmore> well i missed it in #fedora-releng which is where i look for it
18:36:14 <nirik> why are people bringing up all these bugs as blockers that have existed for many months. Anoying.
18:36:28 <tflink> i think this is another variation of the bug we just rejected
18:36:43 <cmurf> nirik: it's the same person as that other 5 month old plymouth bug i think
18:37:09 <dgilmore> tflink: it as just completely missed that it was opened again
18:37:12 <nirik> yeah, still reading.
18:37:50 <cmurf> at least this has beta criteria cited
18:38:33 <tflink> dgilmore: no worries, we also forgot to let you know that we were planning to submit a TC/RC request when the anaconda build finished last night
18:39:32 <dgilmore> tflink: yeah, had i known and seen it the compose would have been done
18:39:37 <cmurf> re the newly proposed blocker does someone want me to try to reproduce this?
18:39:49 <cmurf> i'm skeptical it happens every time or we'd have heard about this long before now
18:40:11 <jreznik> cmurf: I remember this one, kparal hit this one for f19 and it was very random one
18:40:23 <cmurf> automatic reject then
18:40:32 <cmurf> transient does not qualify
18:40:43 <cmurf> unless it eats data and then, maybe
18:41:03 <jreznik> no
18:41:06 <cmurf> nirik?
18:41:34 <nirik> I have no idea if it's repeatable...
18:41:42 <cmurf> 983110, another 100+ comment bug from 4 months ago
18:42:03 <cmurf> while we stall waiting for pungi status can we do this blocker and send it away?
18:42:15 <cmurf> stall= are still
18:42:43 <nirik> I'd say -1 to blocker, releasenote/common bug, since it's workaroundable.
18:42:46 <tflink> yeah, this sounds like a very unclear and not-always-reproducable bug
18:42:53 <cmurf> -1/-1
18:43:18 <cmurf> kick
18:44:07 <tflink> #topic (983110) several autostart apps (e.g. polkit-kde, kmix) and logout/shutdown countdown fails
18:44:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=983110
18:44:12 <tflink> #info Proposed Blocker, kde-workspace, NEW
18:44:40 <tflink> -1 as it's workaroundable and seems to be very inconsistant in how and how fequently it manifests
18:44:47 <cmurf> -1
18:45:03 <cmurf> comment 100 is the most convincing and as yet not convincing enough
18:45:39 <cmurf> and it could be fixed with an update
18:45:55 <cmurf> and no comments mention the problem happens with live media
18:46:27 <cmurf> ok i'm wrong a few do
18:46:49 <cmurf> but then sometimes it doesn't happen on the same hardware, same person, with live
18:47:02 <jreznik> [19:44] <rdieter> jreznik: not very reproducible
18:47:09 <tflink> proposed #agreed 983110 - RejectedBlocker - This bug has been around for a long time, has reasonable workarounds and does not appear to be hitting with much consistencty.
18:47:14 <cmurf> ack
18:47:34 <jreznik> ack
18:47:46 <cmurf> maybe patch pointing out a fix can be done with an update?
18:48:14 <tflink> it can affect lives, though, right:?
18:48:29 <cmurf> intermittantly affects lives for those it affects at all
18:49:01 <cmurf> so "reasonable workround" is reboot again and update to get it fixed
18:49:16 <tflink> other ack/nak/patch?
18:49:42 <jreznik> I'd let it worded as it is, we are not sure about that update
18:49:50 <cmurf> fair enough
18:51:20 <tflink> anyone? bueller?
18:51:25 <nirik> ack
18:51:33 <tflink> #agreed 983110 - RejectedBlocker - This bug has been around for a long time, has reasonable workarounds and does not appear to be hitting with much consistencty.
18:51:55 * cmurf paid his bookie, has money riding on RC1 being gold colored
18:52:15 <tflink> #topic Go/No-Go decision
18:52:24 <cmurf> pungi?
18:52:38 <tflink> ?
18:53:02 <cmurf> is it built? it's been 10 minutes
18:53:08 <nirik> it's already built, yes.
18:53:10 <dgilmore> cmurf: its built
18:53:35 <jreznik> what are our options now?
18:53:53 <jreznik> dgilmore: how long it will take to finish RC (as Pungi is built?)
18:54:09 <dgilmore> jreznik: about 8 hours
18:54:34 <dgilmore> it takes 6-8 hours to go through a full compose run
18:54:45 <jreznik> and with qa resources, I'm not sure we're able to make it today in a reasonable time
18:55:33 <cmurf> me neither, but i'll give it a shot
18:55:53 * nirik is happy to help with testing too... but yeah...
18:55:55 * cmurf is out all next week
18:56:20 <roshi> I'm here for testing
18:56:23 <tflink> I don't think that getting done today is reasonable
18:56:34 <jreznik> another option is to try tomorrow's go/no-go but tflink and dgilmore are not fans of less than week slips... on the other hand holidays are really close (12-17 GA)
18:57:00 <cmurf> neither prospect is ideal
18:57:20 <cmurf> i'd say try tomorrow
18:57:29 <jreznik> cmurf: or perfect final without any slips :)
18:57:31 <nirik> we could also slip a week and look at carving out a week between beta/final freeze... but I know folks aren't fans of that either.
18:57:52 <cmurf> jreznik: this is why i'm trying to pounce on beta so much, hopefully a perfect final
18:58:08 <dgilmore> jreznik: due to timing id object less to a single day than normal
18:58:23 <jreznik> nirik: that's another option, with TCs soon, early final freeze...
18:58:50 <cmurf> i like that idea also
18:59:06 <jreznik> tflink: ?
18:59:30 <tflink> we can try for tomorrow, but I think that's really pushing it
19:00:46 <nirik> yeah, I do too, but we can always just no go tomorrow.
19:01:01 <tflink> we've already had 2 all-nighters in f20
19:01:01 <jreznik> tflink: what's your confidence to cover missing bits from qa side?
19:01:40 <tflink> what's the deadline?
19:01:50 <jreznik> on the other hand, even f18 survived christmas...
19:01:54 <jreznik> tflink: what deadline?
19:02:09 <nirik> 18UTC tomorrow?
19:02:09 <tflink> for tomorrow? are we talking about 12 hours, 18 hours, 24 hours?
19:02:34 <tflink> that's less than 12 hours to run through the entire beta matrix and verify all blocker fixes
19:02:49 <cmurf> 23?
19:02:49 <dgilmore> tflink: i would think 24 hours from now
19:02:50 <jreznik> tflink: it's more
19:02:52 <roshi> and we'd still have to verify the alpha matrix
19:03:05 <roshi> since that's a beta release crit
19:03:11 <tflink> but RC1 isn't due for another 8 hours
19:03:14 <dgilmore> tflink: so it gives ~ 18 hours for testing
19:03:15 <roshi> or am I reading it wrong?
19:03:15 <jreznik> do you know, will be brno's guys available tomorrow?
19:03:21 <cmurf> i'm counting 23 from 18UTC as it's 19UTC now
19:03:32 <cmurf> got it
19:03:34 <tflink> yeah, I'm counting wrong
19:03:37 <jreznik> cmurf: tflink is right, -8 hours for compose
19:03:43 <cmurf> yepyep
19:03:51 <tflink> 15 hours
19:03:53 <cmurf> 15 hours testing
19:03:54 <cmurf> yes
19:04:00 <dgilmore> on the compose front
19:04:01 <cmurf> tight
19:04:18 <dgilmore> we can not downgrade to the versions of shim and shim-signed that pjones wants
19:04:32 <cmurf> ruhroh
19:04:44 <cmurf> fedup?
19:04:47 <jreznik> let's have a deal - try it, but with a strict deadline 18 UTC, no way to have neverending meeting?
19:04:59 <cmurf> jreznik: ;-)
19:05:04 <cmurf> deal
19:05:13 <tflink> so who's staying up all night:?
19:05:33 <cmurf> dgilmore: explain
19:05:33 <jreznik> tflink: 8 hours compose mean my 8 hours of sleep :)
19:05:35 <roshi> this guy
19:06:05 * cmurf will sleep when he's dead
19:06:34 <cmurf> dgilmore: we had those versions of shim on F18 and F19 if I recall correctly
19:06:53 <tflink> I'm OK with trying it but I'm not thrilled about the idea - seems a bit unfair to make us stay up all night just because fixes landed at the last minute
19:07:21 <jreznik> tflink: well, you can let it on us - in our timezone
19:07:35 <tflink> jreznik: most of the brno fedora-qe folks are on pto tomorrow
19:08:11 * satellit I am off line tommorrow (driving for 8 hrs)from 7AM PST
19:08:23 <jreznik> tflink: ok, that's the info I did not know... :(
19:08:28 <cmurf> guys, we may not have a compose if we can't downgrade shim to the versions pjones wants
19:08:45 <dgilmore> cmurf: we can only go back to what is the most recent stable build
19:08:54 <tflink> cmurf: as i understood it, 0.4 can work but it's not optimal
19:09:33 <jreznik> tflink: and it seems it would be mostly on you, I can't ask you to do that... without QA guys, it doesn't make sense to try tomorrow's go/no-go
19:09:35 <dgilmore> fedora policy forbids us pulling in the older nvr stable builds from previous releases
19:10:11 <dgilmore> and how to actually get the tooling to do it is not simple
19:10:23 <dgilmore> i would have to mess in different places
19:10:28 <cmurf> i see
19:10:48 <jreznik> seems like pjones has to survive that bogus warning
19:10:55 <cmurf> so we have to accept the superfluous warnings on many machines with 0.4-1
19:11:08 <cmurf> and maybe some useless bug reports
19:11:10 <cmurf> *shrug*
19:11:23 <jreznik> yep
19:11:29 <cmurf> ok so 0.4-1 it is
19:12:01 <tflink> jreznik: yeah, all the fulltime brno folks on fedora-qe are  on PTO tomorrow
19:12:17 <jreznik> so it really doesn't make sense to push it
19:12:40 <cmurf> ok so it's somewhere between impossible and miracle required
19:12:41 <tflink> we might have martin and 2 interns but I don't know what their schedule is off hand
19:12:43 <jreznik> I know pschindl is on PTO tomorrow for Tmou
19:14:10 <jreznik> it seems like we're going to have full week slip and maybe we will be happy to have shim signed and ready
19:14:22 <cmurf> good points
19:14:37 <tflink> yeah, I don't have high confidence that we'd be able to test everything before monday or tuesday
19:14:39 <cmurf> i still like the idea of an early final freeze
19:14:39 <nirik> yeah, lets no go and possibly ask fesco about moving up a week between beta/final
19:14:48 <cmurf> good
19:16:04 <jwb> can someone point me to the wiki page or doc describing this policy?
19:16:14 <tflink> jwb: which policy?
19:16:18 <jreznik> nirik: I'm not happy about that neither but with earlier final freeze, it could be doable... also early TCs really work
19:16:30 <jwb> tflink, "edora policy forbids us pulling in the older nvr stable  builds from previous releases
19:16:33 <jwb> "
19:17:09 * tflink has no idea
19:17:14 <jwb> i honestly don't remember that being a policy.  i'd just like to read it so i understand the rationale there
19:17:33 <nirik> dunno. It does seem like a bad idea in many cases to do that. ;)
19:17:48 <nirik> ie, older build has broken deps against new libraries/packages.
19:17:57 <jwb> nirik, there is a difference between "policy" and "bad idea/i don't like that"
19:18:07 <nirik> sure.
19:18:15 <jwb> nirik, and we've shipped packages from the prior release before in cases where there isnt' a mass rebuild
19:18:16 <jwb> so... where is the POLICY
19:18:25 <jwb> or if there isn't one, please just say "i don't want to do that because..." and then write one.
19:18:26 * nirik repeats his 'dunno'
19:18:43 * tflink seconds the 'dunno'
19:18:49 <jwb> dgilmore, ?
19:19:09 <nirik> he's discussing with pjones now in another channel
19:19:30 * dgilmore looks up
19:19:51 <dgilmore> jwb: that nvrs can not go backwards
19:20:19 <jwb> sure, if that's the one you're referring to.  is that written somewhere?
19:20:31 <dgilmore> as far as i know it is
19:20:47 <jwb> cool.  i'll hunt for it, but if you have a pointer i'd appreciate it
19:21:59 <jreznik> proposal - full week slip due to unresolved blocker bugs by the go/no-go meeting and unavailability of QA resources for one day slip; propose shorter "beta to final cycle" to FESCo due to potential clash with holidays with early freeze date
19:22:14 <dgilmore> its been in my head so long that id have to dig it up
19:22:26 <tflink> ack
19:22:27 <dgilmore> but i believe FESCo had voted on it
19:22:32 <nirik> ack
19:22:56 <dgilmore> if FESCo wanted to change that they can
19:23:06 <jreznik> any other acks?
19:23:10 <roshi> ack
19:23:25 <dgilmore> jreznik: ack
19:23:50 <jreznik> #agreed full week slip due to unresolved blocker bugs by the go/no-go meeting and unavailability of QA resources for one day slip; propose shorter "beta to final cycle" to FESCo due to potential clash with holidays with early freeze date
19:24:17 <jreznik> ok, thanks!
19:24:58 <jreznik> #action jreznik to announce slip and propose shorter beta to final period to FESCo
19:25:10 <jreznik> #topic Open floor
19:25:27 <jzb> jreznik: lemme know if there's specific testing or something I can promote on magazine, etc.
19:25:43 <jzb> help direct folks to any testing, etc.
19:26:18 <dgilmore> jwb: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313#Document_.22Rawhide_cannot_go_backwards.22_rule apparently you were going to document it
19:26:24 <jreznik> jzb: there are always test matrices - linked in the first item of this meeting, I expect it will help qa guys
19:26:28 <dgilmore> that actually only says rawhide though
19:26:52 <jwb> dgilmore, ha!  but yeah, only says rawhide
19:26:59 <dgilmore> jwb: yeah.
19:26:59 <jreznik> ;-)
19:27:01 <dgilmore> https://fedorahosted.org/fesco/ticket/96
19:28:26 * jreznik is going to end this meeting, as this discussion happens in #anaconda now
19:28:34 <jreznik> in 3...
19:29:55 <jreznik> 2...
19:31:00 <jreznik> 1...
19:31:11 <jreznik> thanks for coming everyone!
19:31:41 <jreznik> #endmeeting