17:00:37 <jreznik> #startmeeting F21 Beta Go/No-Go meeting
17:00:37 <zodbot> Meeting started Thu Oct 30 17:00:37 2014 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:39 <jreznik> #meetingname F21 Beta Go/No-Go meeting
17:00:39 <zodbot> The meeting name has been set to 'f21_beta_go/no-go_meeting'
17:00:51 <jreznik> #topic Roll Call
17:00:54 <jreznik> hi all!
17:00:56 <nirik> .hello kevin
17:00:57 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:01:02 <danofsatx> .hello dmossor
17:01:03 <zodbot> danofsatx: dmossor 'Dan Mossor' <danofsatx@gmail.com>
17:01:29 * pwhalen is here
17:01:38 <adamw> ahoy
17:01:43 <adamw> .hello adamwill
17:01:44 <zodbot> adamw: adamwill 'Adam Williamson' <adamw+fedora@happyassassin.net>
17:02:03 <stickster> .hello pfrields
17:02:04 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
17:02:22 <jreznik> #chair adamw nirik stickster roshi
17:02:22 <zodbot> Current chairs: adamw jreznik nirik roshi stickster
17:02:38 <roshi> .hello roshi
17:02:39 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:02:48 * roshi sits in his shiny new chair
17:03:41 * jreznik is pinging a few more folks
17:04:22 <jreznik> #topic Purpose of this meeting
17:04:23 <jreznik> #info Purpose of this meeting is to see whether or not F21 Beta is ready for shipment, according to the release criteria.
17:04:25 <jreznik> #info This is determined in a few ways:
17:04:26 <jreznik> #info No remaining blocker bugs
17:04:28 <jreznik> #info Release candidate compose is available
17:04:29 <jreznik> #info Test matrices for Beta are fully completed
17:04:31 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist
17:04:32 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Install
17:04:34 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Base
17:04:35 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Desktop
17:04:37 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Server
17:05:09 <jreznik> #topic Current status
17:06:24 <jreznik> for current status - F21 Beta RC4 is currently undergoing release validation
17:06:52 <jreznik> according to blockerbugs app, there are currently 3 proposed blockers
17:07:50 <jreznik> and not all accepted blocker are marked as VERIFIED/CLOSED
17:08:14 <jreznik> so let's start with the mini blocker review today, unless anybody has more for update
17:09:08 <jreznik> roshi: may we use your services again? :)
17:09:10 <jreznik> #topic Mini blocker review
17:09:25 * oddshocks is here
17:09:32 <roshi> sure thing
17:09:42 <roshi> #link http://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
17:09:46 <stickster> roshi++
17:09:59 <roshi> ^^ Release Criteria we're considering
17:10:14 <roshi> first blocker
17:10:15 <roshi> #topic (1158533) LVMError: lvactivate failed for home: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda$|","r|/sdc1$|","r|/sdc2$|","r|/sdc$|"] }  fedora/home failed
17:10:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158533
17:10:22 <roshi> #info Proposed Blocker, anaconda, NEW
17:10:33 <adamw> i asked in #anaconda if anyone's available to review these
17:11:16 <roshi> this requires multiple passes through the custom spoke, right?
17:11:29 <adamw> well, satellit said his case didnt'
17:11:37 <roshi> ah
17:12:53 <kparal> I think the error is somewhat generic and can be caused by multiple root causes
17:13:08 <adamw> yeah
17:13:22 <adamw> i'd like a bit wider understanding of it, but not sure if we can arrive at that here
17:13:29 <roshi> is USB hdd as an install location a supported config?
17:13:34 <adamw> i'd also like to know if it's changed since TC4 or since RC1
17:13:36 <adamw> sure
17:13:59 <danofsatx> not for uefi ;)
17:14:20 * roshi just didn't see it on the test matrix under storage devices
17:14:30 <adamw> i would be -1 on the 'choose your adventure' incarnation - we can't really block on 'do this, then do that, then stand on your head' bugs when they're discovered minutes before go/no-go, that way madness lies - but it'd be nice to have at least a reasonable understanding of other cases where this might happen, and whether it's a 'regression' (quotes to pacify wwoods)
17:14:55 * nirik is with adamw
17:14:56 <jreznik> based on kparal comments that no one from the team could reproduce it in one pass, so it seems to work at least somehow for standard use cases, I'm -1 blocker
17:15:00 <adamw> roshi: the criteria are quite a lot wider than the test case set here - which is sort of a problem as it tends to mean we run into things somewhat at random like this
17:15:09 <adamw> but a matrix that enforced the full extent of the criteria would be the stuff of nightmares
17:15:39 <kparal> jreznik: I actually think it is a standard use case to visit the spoke multiple times. but probably not serious enough to block Beta on
17:15:39 <adamw> the idea is that we should block on certain types of issues if we find them, but we might want to see if can tweak the approach a bit *somehow*
17:16:01 <roshi> I was just curious :)
17:16:23 <adamw> i agree with kparal - not really *that* weird a use case, but in practice it's hard to block beta on this kind of thing as there's just so many permutations
17:16:26 <roshi> but if it works with a sata disk but not usb, I'd be willing to fudge on the USB bit
17:16:44 <roshi> votes?
17:18:14 * jreznik is not saying weird, just a bit too much for Beta
17:18:18 <kparal> -1 for Beta, re-propose for Final
17:18:22 <roshi> I'm of the same mind as kparal and adamw
17:18:29 <jreznik> -1 for Beta
17:18:34 <roshi> -1 Beta, repropose for final
17:19:25 <danofsatx> -1
17:19:35 <roshi> proposed #agreed - 1158533 - RejectedBlocker - This bug has a multitude of paths to hit it, so isn't considered to block beta. Re-propose for Final.
17:19:48 <jreznik> ack
17:19:50 <adamw> given what we know, ack, but i'm a bit worried.
17:19:50 <nirik> ack
17:19:58 <adamw> but hey, it's a beta
17:20:07 <adamw> and we have to make a call...
17:20:15 <danofsatx> ack
17:20:18 <roshi> yeah, I'm a bit worried as well
17:20:24 <roshi> #agreed - 1158533 - RejectedBlocker - This bug has a multitude of paths to hit it, so isn't considered to block beta. Re-propose for Final.
17:20:31 <nirik> don't worry, be happy. :)
17:20:40 <roshi> :)
17:20:45 <roshi> next up...
17:20:46 <roshi> #topic (1158975) IOException: Partition(s) 2 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making ...
17:20:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158975
17:20:53 <roshi> #info Proposed Blocker, anaconda, NEW
17:21:37 * pschindl_mobile is here, but from mobile phone so I'll be mostly watching
17:21:38 <sgallagh_mobile> Sorry folks. Family emergency. I can't be here.
17:22:02 <adamw> sgallagh: sorry to hear :(
17:22:10 <adamw> pschindl_mobile: oh, good timing
17:22:18 <roshi> np sgallagh_mobile family takes priority, IMO :) Good luck
17:22:21 <jreznik> sgallagh_mobile: np, family is important, gl
17:22:35 <adamw> pschindl_mobile: the description here isn't entirely clear to me - can you clarify a bit on "I had to go to reclaim space twice to do it (I wanted to delete just one partition which doesn't work with mbr on UEFI)" ?
17:23:10 <satellit> bz 1158975 shows up in gparted for me in RC2
17:23:20 <pschindl_mobile> Firstly I'd like to delete just one Partition
17:24:31 <pschindl_mobile> But then I realized that I booted to uefi and there is mbr on the thisk. A aconda also complain about it. So I had to visit instalation destination again
17:25:03 <adamw> pschindl_mobile: so, wait, you get all the way through the 'free up space' workflow but then you get an error/warning when you arrive back at the hub?
17:25:24 <pschindl_mobile> And this time I removed the last partition (in reclaim space dialog)
17:26:15 <pschindl_mobile> No. Anaconda just complained about something beeing wrong in inst dest
17:26:37 <pschindl_mobile> The error raised on the beginning of the installation
17:26:45 <adamw> sorry, that's what I meant
17:26:58 <adamw> Southern_Gentlem: you go through once, and it lets you, but then prints one of those 'road warnings' at the hub
17:27:04 <adamw> hah, auto-complete
17:27:05 <adamw> so: you go through once, and it lets you, but then prints one of those 'road warnings' at the hub
17:27:21 <pschindl_mobile> I saw this in gnome-disks too.
17:27:22 <adamw> then you go through again, and select to delete all partitions this time, and it lets you, but install crashes on partitioning
17:27:23 <adamw> right?
17:27:29 <adamw> the message itself isn't that uncommon
17:27:34 <adamw> it comes from parted iirc
17:27:48 <stickster> *nod
17:27:55 <adamw> but anaconda should of course be making things so it doesn't run into it on 'supported' paths
17:28:14 <roshi> bz isn't loading for me
17:28:39 <adamw> for me this is a bit like the last one, if it's choose-your-own-adventure and you can fix it by just starting over and doing the right thing first time, -1 beta blocker
17:28:40 <pschindl_mobile> adamw: it's as you said.
17:28:54 * nirik is -1 beta blocker.
17:29:05 <Southern_Gentlem> -1
17:29:28 <kparal> repropose to Final
17:29:46 <jreznik> -1, for final, it would be nice to get fix
17:29:51 <pschindl_mobile> I'm -1 beta too. I hadn't enough time to investigate. I had to leave rigbt after this showed up
17:30:08 <adamw> it seems like we have a kind of consensus on what should block beta and what shouldn't, but it's so hard to write down in the criteria :/ i can always take another cut at it...
17:30:50 <pschindl_mobile> Yep . I'll try to find out what happened and I'd repropose it for final
17:30:53 <jreznik> adamw: next part of decision is common sense (and it's hard to write it down on paper) but I understand what you'd like to tell
17:31:07 * adamw doesn't believe in common sense
17:31:07 <jreznik> (and review)
17:31:21 <adamw> one of my favourite quotes (dunno where I picked it up): common sense: rarely either
17:31:22 <roshi> proposed #agreed - 1158975 - RejectedBlocker - This bug doesn't get hit when doing a standard install, but only with a specific configuration. Rejected as a blocker for Beta, re-propose for Final.
17:31:22 <jreznik> the third is probably the most important
17:31:30 * roshi wasn't sure how to write that one
17:31:35 <danofsatx> -1
17:31:42 <jreznik> ack
17:31:45 <danofsatx> ack
17:31:45 <nirik> ack
17:31:50 <pschindl_mobile> Ack
17:32:26 <roshi> #agreed - 1158975 - RejectedBlocker - This bug doesn't get hit when doing a standard install, but only with a specific configuration. Rejected as a blocker for Beta, re-propose for Final.
17:32:39 <roshi> alright, final proposed...
17:32:40 <roshi> #topic (1154347) Local standard SATA disks incorrectly detected as a multipath device, unavailable for selection as install target in anaconda
17:32:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154347
17:32:46 <roshi> #info Proposed Blocker, device-mapper-multipath, NEW
17:33:08 <adamw> so this one came back from the dead
17:33:36 <adamw> the info we got from ben is somewhat useful and i've provisionally identified a difference between 20 and 21 which may account for this, but still, it seems like we've done a lot of live testing and no-one else has hit this
17:34:46 <nirik> yeah.
17:34:51 <nirik> and even reporter doesn't hit it always
17:34:52 <adamw> right now we have one confirmed reporter who's only testing with live images and who hits the bug 'sometimes', i kinda like those odds
17:34:55 <adamw> right
17:35:07 <Southern_Gentlem> if unable to recreate -1 as blocker but put in commonbugs
17:35:16 <nirik> might rate a common bugs? "If you see no disks, power cycle, etc"
17:35:22 <adamw> i get the feeling maybe a couple other people will hit it and it's something we'll need to clean up for final maybe, but if i have to make a call, not beta blocking
17:35:23 <nirik> but not sure how common it really is
17:35:34 <adamw> nirik: yeah, commonbugs for sure
17:35:39 <adamw> eh, the names a bit misleading
17:35:47 <nirik> -1 beta blocker here.
17:35:57 <adamw> i like 'Errata' more, but it's kinda baked into fedora
17:36:00 <roshi> -1 since it's not 100% reproducable
17:36:08 <roshi> KnownBugs
17:36:12 <roshi> AnnoyingBugs
17:36:18 <adamw> Bugs
17:36:26 <roshi> for this, perhaps Mites
17:36:31 <adamw> boycottbugs.org
17:37:01 <kparal> -1
17:37:03 <stickster> lulz
17:37:10 <nirik> ha.
17:37:20 <pschindl_mobile> -1 for beta
17:37:37 <stickster> forkbugs.org
17:37:37 <jreznik> -1
17:37:37 <danofsatx> -1
17:37:54 <roshi> proposed #agreed - 1154347 - RejectedBlocker - Because this bug isn't 100% reproducible it isn't considered to block Beta. If reproduction can be solidified, re-propose for Final.
17:38:06 <nirik> ack
17:38:26 <jreznik> ack
17:38:27 <kparal> ack
17:38:35 <roshi> #agreed - 1154347 - RejectedBlocker - Because this bug isn't 100% reproducible it isn't considered to block Beta. If reproduction can be solidified, re-propose for Final.
17:38:40 <roshi> that's it for proposed blockers
17:38:49 <adamw> yaay
17:39:09 <pschindl_mobile> How many got accepted?
17:39:11 * roshi hands the meeting back to jreznik
17:39:13 <roshi> 0
17:39:24 <pschindl_mobile> Coool
17:39:30 <jreznik> thanks roshi!
17:39:37 <roshi> np :) glad to be of service
17:39:54 <jreznik> #topic Accepted blockers status
17:40:28 <roshi> The NEW bug is AMIs, which are being built and updated now
17:40:30 <jreznik> looking on current list of accepted bugs, there are still some not in VERIFIED/CLOSED state
17:40:36 <roshi> oddshocks can speak to this bit
17:42:04 <stickster> He was just here a second ago... :-)
17:42:25 <jreznik> there's also 1147998 cloud-utils MODIFIED
17:42:27 <oddshocks> hey!
17:42:27 <adamw> roshi: we should be able to close https://bugzilla.redhat.com/show_bug.cgi?id=1147998 now right?
17:42:37 <roshi> he's having some connection issues
17:42:49 <roshi> yes
17:42:55 * pschindl_mobile has to leave. Wife's calling :-) Have a nice day everyone
17:42:55 <oddshocks> sorry i lost all my internet and had to tether to my phone and experienced a horrible moment of panic as i couldnt get anything to connect
17:42:55 <stickster> I see e.g. http://alt.fedoraproject.org/pub/alt/stage/21_Beta_RC4/Cloud/Images/x86_64/
17:42:59 <roshi> I can confirm, so can others, that reboots work
17:43:07 <stickster> \o/
17:43:16 <jreznik> good
17:43:17 <roshi> which is a good thing :)
17:43:35 <oddshocks> hey -- so in short my status is that 64 bit base AMI is now available in all EC2 regions. 32 bit base is registering now, working out some kinks. same for 64 bit atomic
17:43:52 <adamw> on the NTFS bug we just need to confirm that RC4 doesn't allow ntfs resizing, that was agreed to be sufficient that the bug would no longer block
17:43:54 <adamw> i'm confirming that now
17:44:01 <jreznik> thanks adamw
17:44:07 <oddshocks> adamw: cool
17:44:10 <adamw> (this is planned to be a temporary workaround for beta, and the idea is to fix the bug properly for final)
17:44:17 <jreznik> 1156603 can be closed too, rigth? as we have cloud images now
17:44:43 <roshi> we can, but I was going to wait until they were all up there
17:45:00 * nirik tested the cloud images in openstack.
17:45:05 * oddshocks agrees
17:45:06 <nirik> both 32 and 64 bit work fine.
17:45:10 <roshi> awesome
17:45:13 <oddshocks> nirik: _awesome_
17:45:24 <roshi> can I put you down on the matrix for reporting all those tests as passed?
17:45:25 <adamw> ok, ntfs resize confirmed
17:45:43 * roshi couldn't get to his openstack instance to test them last night...
17:45:59 <adamw> roshi: there's a separate bug for the AMIs being missing, so i think we can close the generation bug right now
17:46:09 <roshi> oh, yeah
17:46:09 <jreznik> yep
17:46:17 * adamw does it
17:46:24 <nirik> roshi: I did update the openstack ones in the test matrix. Feel free to update anywhere I missed.
17:46:48 <roshi> ah, cool - didn't see it last time I looked :) thanks
17:47:13 <adamw> ok, i closed out the cloud generation and reboot bugs, and dropped blocker status from NTFS bug
17:47:26 <oddshocks> right on :)
17:48:16 <jreznik> so now AMIs bug
17:49:38 <roshi> I can close that once oddshocks is done working his magic
17:50:25 <jreznik> do we want to wait for it? or meanwhile we can take a look on test matrices coverage
17:50:25 * oddshocks nod nod
17:50:39 <roshi> sure
17:51:09 <roshi> https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Summary
17:51:20 <roshi> in case someone didn't already have it open...
17:51:24 <jreznik> #info all accepted blocker bugs are closed/verified now except we're are waiting for AMIs one to finish
17:51:35 <jreznik> #topic Test Matrices coverage
17:51:50 <adamw> also:
17:52:00 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Summary
17:52:05 <adamw> https://www.happyassassin.net/testcase_stats/21/
17:52:29 <adamw> coverage looks really pretty good, frankly better than i expected - great testing job folks
17:52:49 <roshi> for sure
17:52:49 <adamw> just about the only thing we're missing for rc4 is QA:Testcase_upgrade_fedup_cli_previous_kde - is anyone working on that?
17:53:06 <danofsatx> I can't :(
17:54:02 * roshi isn't
17:54:06 * tflink can start
17:54:11 <adamw> let's race!
17:54:28 <adamw> but eh, it seems pretty unlikely it'd be busted.
17:54:29 <tflink> actually, I think I might have a f20 kde vm setup
17:54:31 <danofsatx> well, this workstation I'm on is KDE, F20 fully updated.....
17:54:44 <danofsatx> but, it's btrfs. I don't trust it.
17:55:01 * jreznik also did kde update but it's not recent
17:55:16 <jreznik> s/update/upgrade
17:56:19 <adamw> FWIW we've had 215 reports from 18 testers since RC4 landed just ~16 hours ago
17:56:21 <adamw> awesome job folks
17:56:38 <roshi> that's a lot of reports :)
17:56:39 <stickster> Holy moley
17:56:43 <adamw> that's 13.44 Tests Per Hour, or TPHs
17:56:49 <adamw> :P
17:56:56 * roshi needs a dashboard widget for that...
17:56:56 <danofsatx> I wish some of those were mine. <sigh>
17:57:07 <roshi> so do we danofsatx , so do we
17:57:10 <roshi> :P
17:57:13 <stickster> "Every time a bell rings, a QA tester gets their wings"
17:57:13 * roshi kids
17:57:31 <jreznik> and what mpg for that tph? :)
17:57:39 <danofsatx> heh....sorry, I've been fighting with iterations of FreeIPA or Openstack all morning.
17:57:50 <adamw> TPLW (Tests Per Litre of Whiskey)
17:57:57 <adamw> danofsatx: don't apologize for that!
17:57:58 <roshi> oh don't worry about it danofsatx :) I was just giving you a hard time :)
17:57:59 <danofsatx> a more accurate measure
17:58:29 <roshi> on the TPLW, which is better, a higher Litre count or testcount?
17:58:30 <danofsatx> i know ;)
17:58:36 <roshi> that could be read both ways...
17:58:43 * adamw has f20 KDE install running, but i don't mind if we want to call coverage sufficient with the RC1 result and move on
17:59:04 <roshi> cloud coverage is iffy at this point
17:59:10 <roshi> but I think it's enough
17:59:16 <jreznik> adamw: let's go with it
17:59:30 <roshi> but tbh - not sure how thin the ice I'm standing on is, or how deep the water is underneath it
18:00:07 <adamw> oh, i thought we were ok for cloud, sorry
18:00:13 * jreznik will be back in a minute, call of nature and urgent...
18:00:26 <roshi> I think we are simply because cloud images are *so* similar
18:00:43 <roshi> but from a % tc ran perspective, I could see it being argued
18:00:45 <nirik> what other cloud tests are there?
18:00:49 <adamw> how long would it take to get sufficient testing?
18:01:07 <roshi> as soon as these AMIs get uploaded it shouldn't take long
18:01:08 <adamw> nirik: looks like we haven't tested the 'official' 64-bit AMI yet, and no 32-bit ec2/openstack tests
18:01:30 <roshi> atomic is the only one I really want to check
18:01:34 <adamw> atomic is not blocking
18:01:40 <nirik> adamw: I did do 32bit openstack.
18:01:48 <adamw> nirik: ah, it's not in the page
18:02:01 <nirik> perhaps I screwed up editing. Shoudl have used retval. :)
18:02:05 <roshi> the blocking images all worked on local and openstack
18:02:18 <roshi> I've no reason to think it won;t work on EC2
18:02:24 <tflink> the 32 bit openstack results are there
18:02:31 <roshi> oddshocks: that sound about right to you?
18:02:49 <roshi> I don't see niriks results...
18:02:51 <adamw> tflink: huh, guess i'm stuck in a Wiki Cache Of Death
18:02:51 * roshi refreshes
18:03:37 <oddshocks> roshi: affirmative
18:03:42 <roshi> I don't see them, but I trust nirik on his word :)
18:03:55 <oddshocks> if the images boot on local and openstack -- especially if nirik says they do -- then that's good in my book
18:04:19 <tflink> we're talking about https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Installation#Cloud_images right?
18:04:23 <roshi> any issue we would have with EC2, would be an EC2 issue - *not* an image issue
18:04:29 * jreznik is back
18:04:31 <oddshocks> the AMI problems are issues separate, and likely related to EC2 -- exactly.
18:04:51 <tflink> how long until the upload is finished?
18:05:28 <oddshocks> If you ask me, we don't block on the AMI images being only partially available, especially since this is a configuration problem that can easily be solved during beta, if not within the next 24-48 hours
18:05:29 <roshi> tflink: https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Cloud#x86_64
18:05:38 <roshi> is what we're talking about, well, what I'm talking about
18:05:55 <tflink> ah, I was talking about a different page
18:06:05 <nirik> yeah, me too.
18:06:10 <roshi> nirik: those are the testcases I was asking if you filled in :)
18:06:13 <roshi> sorry
18:06:25 * roshi should move what you filled in to the cloud page
18:06:38 <adamw> oddshocks: we're not gonna slip or anything, just thinking about waiting to sign off on the images until we can run the tests on them
18:06:57 <adamw> given "<roshi> any issue we would have with EC2, would be an EC2 issue - *not* an image issue" i think maybe we don't have to wait
18:07:03 * adamw fires up kde fedup
18:07:23 <roshi> my kde install is at post installation tasks
18:07:41 <nirik> roshi: ok, I just did the ones at https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_RC4_Installation#Cloud_images I can do the 32bit ones on that other page. I am pretty sure they are all great.
18:08:03 <roshi> if you could log in via ssh, install stuff and logging worked, we should be good
18:08:12 <oddshocks> adamw: word
18:08:46 <nirik> roshi: yes, yes and yes. ;) I did a xfce group install. 480 packages.
18:09:05 <roshi> nice
18:09:08 <roshi> wfm then :)
18:09:35 <oddshocks> nirik++
18:10:24 <tflink> kde upgrade is running, so far so good
18:12:18 * stickster in another meeting but keeps lurking
18:12:27 <jreznik> thanks stickster for coming
18:12:49 <stickster> FWIW all the decisions here made sense to me :-)
18:12:58 <oddshocks> :)
18:13:26 <adamw> stickster: seek professional help immediately
18:13:33 <stickster> And it sounds like oddshocks is on the case with AMI images which are on the way
18:13:42 <stickster> adamw: professional help: rarely either
18:13:45 <adamw> haha
18:16:22 * adamw watches package count rise, whistles badly
18:17:44 <danofsatx> I've got to run. Can I submit my vote early?
18:17:47 <oddshocks> adamw: shhhh
18:17:49 <oddshocks> ;)
18:19:06 <adamw> danofsatx: qa team vote is done according to a policy, fwiw, but personal vote sure
18:19:31 <adamw> "QA team's determination must be based on the blocker bug process. QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are unaddressed in the candidate compose. QA does not approve the release if there are any accepted blocker bugs that are unaddressed in the candidate compose or if validation testing is incomplete."
18:19:34 <adamw> from https://fedoraproject.org/wiki/Go_No_Go_Meeting
18:20:01 <danofsatx> ok, at this point I'm +1 go.  Based solely on the information at this point. If KDE fails, well then, my vote don't matter, does it? ;)
18:20:03 <adamw> hum, my KDE fedup run isn't using the graphical upgrade screen. no problem, just interesting
18:20:06 <adamw> hehe
18:20:21 <tflink> me neither - just console output
18:20:29 <adamw> i kinda like that more anyway
18:20:32 <tflink> that's weird
18:20:34 <adamw> data! the illusion of control!
18:20:47 <danofsatx> don't you mean allusion?
18:20:54 <adamw> no, i mean illusion.
18:20:56 <tflink> the output just got all corrupted-looking
18:21:22 * tflink just waits to see if it finishes
18:21:59 <tflink> showing progressivly less information as time goes on
18:22:44 <tflink> and it's back - I think it's an issue with this VM's display connection
18:23:02 <roshi> I've seen that before
18:27:09 <tflink> well, that didn't work
18:27:24 <tflink> the vm just shut off
18:27:30 <tflink> only f20 kernels are installed
18:27:44 * tflink probably screwed something up, best wait for adamw's run
18:27:53 <adamw> mine's still going, i used fedup from updates-testing...
18:28:02 <tflink> oh
18:28:06 <tflink> that's what I missed
18:28:14 <danofsatx> someone reported the same issue in #kde last night (rebooted to F20)
18:30:18 <adamw> mine's on cleanup atm
18:30:38 <adamw> iirc someone else reported a run where they got an f20 kernel but various f21 packages. i mean, it's clearly installing f21 packages, here.
18:30:48 <tflink> yeah, it was installing f21 packages
18:30:55 <tflink> and the login splash changed
18:31:48 <adamw> welp, i got a 21 kernel
18:31:51 <adamw> booting now
18:33:34 <jreznik> boot! boot! boot!
18:33:35 <adamw> huh. initial-setup ran on boot.
18:33:44 <jreznik> on boot? uf
18:33:54 <adamw> i'm clearly not getting enough sleep because it didn't strike me as odd until just now
18:34:09 <danofsatx> umm....it's not sposta do that with fedup, is it?
18:34:35 <adamw> no...
18:35:00 <danofsatx> but, can you log in?
18:35:07 <adamw> still, it *worked*
18:35:11 <danofsatx> is your old data still there?
18:35:14 <adamw> well yeah, but i'm not sure if i just re-created my user account
18:35:16 <adamw> i dunno, i didn't have any
18:35:23 <danofsatx> hmmm....
18:35:42 <adamw> the mtime on the files in /home/test is 11:05, not 11:35, so...
18:35:43 <jreznik> I'd say data should stay unless there's a big rm -rf somewhere in fedup
18:35:44 <zbyszek> adamw: check the timestamps of .bashrc
18:36:06 <adamw> aug 2013
18:36:16 <adamw> so, looks like it didn't wipe data at least.
18:36:33 <adamw> needs a bit of looking into, but i wouldn't call it a blocker.
18:36:59 <jreznik> adamw: but would be nice not to forget it for final
18:37:50 <danofsatx> I just created a new user (on F20) and got a .bashrc dated Oct 6 2014.
18:38:40 <jreznik> if not a blocker, what we're now waiting for? not sure what was the conclusion with AMIs, if we have to wait or not
18:39:00 <danofsatx> not a blocker - go
18:39:14 * roshi just pinged oddshocks for status
18:39:24 * roshi doesn't think we have to wait on the AMIs
18:39:32 <adamw> yeah, i think we can say cloud is covered
18:39:40 <roshi> the images are fine it seems - just EC2 stuff
18:39:45 <adamw> seems very unlikely we'll somehow hit a problem which involves an image respin
18:40:18 <jreznik> ok, so let's move on
18:40:23 <roshi> yup
18:40:57 <jreznik> #topic Go/No-Go decision
18:41:01 <sgallagh_mobile> adamw: you use FreeIPA/SSSD right?
18:41:39 <sgallagh_mobile> halfline and I found and fixed that a week or so ago. Might not be in stable
18:41:40 <adamw> sgallagh: yeah
18:41:53 <adamw> sgallagh: er, fixed what?
18:41:59 <adamw> the kde test i just did didn't involve freeipa.
18:42:05 <sgallagh_mobile> There was a startup race causing g-I-s to run
18:42:11 <adamw> oh, no, not in that test.
18:42:12 <sgallagh_mobile> With SSSD users
18:42:38 <adamw> so i think we can say there are no unresolved blockers and test coverage is considered complete, ergo QA vote is Go
18:43:08 <roshi> \o/
18:43:09 <jreznik> #info there are no unresolved blockers and test coverage is considered complete, ergo QA vote is Go
18:43:21 <danofsatx> woop!
18:43:28 <jreznik> nirik, sgallagh_mobile: from engineering? any showstopper?
18:43:41 <nirik> pass go! collect $200!
18:43:43 <jreznik> dgilmore: we need you, go/no-go decision
18:43:59 <sgallagh_mobile> I'm not aware of any (but I'm sitting in a doctor's office out of the loop at the moment.)
18:44:00 <nirik> jreznik: he's likely asleep... he's in .au
18:44:05 <jreznik> nirik: aha
18:44:05 <sgallagh_mobile> So: go!
18:44:19 <nirik> I know of no releng blockers.
18:44:30 <jreznik> nirik: but I'll write it to ticket, we have this backup process to let releng know
18:44:50 <jreznik> #info Engineering is Go
18:45:23 <adamw> jreznik: nirik is releng, he can vote. :)
18:45:45 * nirik can sure. I haven't been doing composes this cycle, but have been watching for any issues.
18:46:14 <jreznik> so yeah, I'll take nirik as the voice of releng
18:47:10 <jreznik> really, the reason why I want to know dgilmore knows about go was that miscommunication when we missed him and nobody noticed him about go... now, we update tickets
18:47:27 <jreznik> still it would be nice to have an ack that mirroring is happening
18:47:28 <nirik> jreznik: sure. do feel free to update the ticket too...
18:47:40 <jreznik> proposal #agreed Fedora 21 Beta status is go by Release Engineering, QA and Development
18:47:50 <nirik> yeah, thats not started yet, but should be when dgilmore is up.
18:48:39 <jreznik> adamw, nirik & co, pls ack
18:49:59 <jreznik> seems like nobody wants beta out :)
18:50:03 <roshi> ack (if I count, that is)
18:50:17 <nirik> ack
18:50:25 * nirik was finishing up another meeting
18:50:32 <jwb> jreznik, everyone is just shocked it's ready
18:50:51 <adamw> ack for QA
18:50:56 * adamw is multitasking as usual
18:51:05 <sgallagh_mobile> Ack for eng
18:51:06 * jreznik is shock-resistant after several releases behind him
18:51:15 <mattdm> YAAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
18:51:25 <jreznik> #agreed Fedora 21 Beta status is go by Release Engineering, QA and Development
18:51:41 <adamw> this is an official QA team announcement: everyone please switch from your Stress Relief Whisky to your Celebration Whisky
18:51:46 * roshi was really tempted right there to claim he'd found a new blocker in systemd
18:51:56 <jreznik> #action jreznik to announce go decision
18:51:57 <adamw> .fire roshi no cake for you
18:51:58 <zodbot> adamw fires roshi no cake for you
18:52:00 <roshi> haha
18:52:05 <stickster> Yippee!!!
18:52:13 * roshi switches his likkers
18:52:21 <stickster> adamw: Stress relief: rarely either
18:52:23 <jreznik> no whisky for roshi :D or more whisky to shut him up? :))))
18:52:35 <roshi> haha
18:52:53 <roshi> I want it noted: I did *not* do that, was merely tempted to troll
18:52:55 <roshi> :p
18:53:04 <adamw> stickster: oh god, I've created a monster
18:53:13 <stickster> lulz
18:53:14 <jreznik> thank you everyone for an amazing job on beta, especially goes to qa for fast test coverage of RC4
18:53:19 <jreznik> #topic Open floor
18:55:13 <adamw> QA folks, if we could get karma for all the unpushed fixes that'd be great
18:55:21 <jreznik> I have one question - but not very nice :) we're 2014-12-09 with final, do we want to cut one week from beta to final? it's not a nice move but seems we're really close to holidays and the last week before, we can't expect many folks to be available
18:55:48 <jreznik> I know it's last resort thing, we did it already and it's always very tight but thinking loudly
18:56:24 <Southern_Gentlem> suggestion if we have images that are fully tested then we can discuss releasing early
18:56:33 <adamw> i don't know if that'd just wind in an inevitable slip back to the original date
18:56:53 <jreznik> probably yes, it's hard to say
18:56:55 <adamw> Southern_Gentlem: well pushing forward the final date pushes forward the TC1 date
18:57:18 <adamw> we currently have 13 proposed final blockers, fwiw
18:57:47 <jreznik> buffer is one week slip with some confidence, two weeks would mean christmas present :)
18:57:55 <Southern_Gentlem> adamw,  and if the tc1 has all everything fixed why not push it out the door
18:57:57 <stickster> Two weeks = major UGH
18:58:22 <adamw> Southern_Gentlem: no, tc1 almost certainly won't, but the point is that we *start the process* earlier if we change the proposed final date
18:58:37 <nirik> we could just keep the schedule, but move tc1 up sooner.
18:58:42 <Southern_Gentlem> talk later then
18:58:46 <jreznik> adamw: well, maybe we should start the process earlier even without date change
18:58:57 <jreznik> nirik: yep
18:58:58 <stickster> jreznik: I think we need some sense about how many "lingering bugs," for example those that might be pushed to Final, do we have -- in other words are we setting up for failure
18:59:15 <Southern_Gentlem> 13
18:59:26 <stickster> If we've pushed a lot off to Final, and we are thinking about reining in the time, that puts quite some pressure to get those all fixed
18:59:31 <stickster> (which isn't bad in and of itself)
18:59:34 <jreznik> stickster: adamw posted it but number is not an answer
18:59:46 <stickster> jreznik: Yeah, it's more than just quantity, I agree
19:00:04 <jreznik> let's try to start with earlier tc1 and we will see
19:00:06 <stickster> jreznik: 13 trivial bugs should be no big deal; 13 substantial bugs could be a big deal
19:00:14 <Southern_Gentlem> the sooner the TC the more time to test
19:00:22 <jreznik> we can react later once we have better overview of what's going on
19:00:24 <adamw> note that if we move the TC up one week, that means we do final tC1 in...four days.
19:00:28 <adamw> sorry, five.
19:00:35 <adamw> i.e. we spin final tC1 on the day we ship beta.
19:00:35 <stickster> jreznik: So are you proposing we try to rein in the time on the front end, unofficially, and then decide about an earlier release then?
19:01:12 <adamw> this does not give much time to get the final criteria and test cases in shape. i.e., it doesn't give any time to get the final criteria and test cases in shape.
19:01:28 <jreznik> adamw: that's good point, I don't want to force you into neverending release validation
19:01:38 <adamw> well, that's kinda what you're proposing :P
19:02:15 <jreznik> adamw: I know and I don't want to force you into it... if you don't feel it's doable and finalizing release criteria is good argument
19:02:22 <adamw> it's *doable*
19:02:27 <adamw> i just worry about people exploding
19:02:32 <roshi> I know cloud has some final criteria to look at
19:02:32 <adamw> and/or getting compose fatigue
19:02:38 <nirik> perhaps we move it up not a full week...
19:02:42 <nirik> ask for it end of next week?
19:02:44 <roshi> and some test cases as well
19:03:01 * jreznik sends whisky to adamw
19:04:18 <jreznik> let's take a look on it mid next week, if we can have tc1 later next week or keep current schedule
19:05:04 <jreznik> there's more stuff to be done, commonbugs, finish announcement, final criteria, so we have work to do early next week
19:05:42 <jreznik> thanks for coming again and have a nice afternoon/night! and some whisky :)
19:05:44 <jreznik> setting fuse
19:05:46 <jreznik> 3...
19:06:32 <adamw> stable pushes.
19:06:35 <adamw> (on the list of things to do)
19:07:23 <jreznik> and stable pushes... 2...
19:07:32 <stickster> :-)
19:07:45 * drago01 forgot to join the channel
19:07:52 <drago01> go or no go? ;)
19:08:01 <nirik> go!
19:08:01 <Southern_Gentlem> go
19:08:02 <roshi> go :)
19:08:02 <zbyszek> drago01: go
19:08:11 <drago01> ok ;)
19:08:11 <jreznik> go? where?
19:08:17 <drago01> pub
19:08:20 <jreznik> 1...
19:08:21 <roshi> +!
19:08:38 <jreznik> #endmeeting