00:03:18 <jlaska> #startmeeting F-13-Beta engineering readiness meeting
00:03:18 <zodbot> Meeting started Thu Apr  1 00:03:18 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:03:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:03:27 <jlaska> #meetingname f-13-beta-eng-readiness
00:03:27 <zodbot> The meeting name has been set to 'f-13-beta-eng-readiness'
00:03:32 <jlaska> #topic Waiting for critical mass ...
00:03:55 * poelcat here
00:03:57 * adamw gets massy
00:04:11 * jlaska tips hat
00:04:36 <stickster> c=GM/Fe.Doc
00:04:38 <stickster> oops
00:04:40 <jlaska> I don't see a notting around, so we might need to role play again
00:04:53 <jlaska> Oxf13 about?
00:04:58 * Oxf13 here.
00:05:02 <Oxf13> notting is on vacation
00:05:09 <jlaska> lucky guy!
00:05:21 <jlaska> he gets all the #actions
00:05:33 <adamw> and the blame
00:05:37 <jlaska> okay, shall we get started
00:05:55 <jlaska> the basics ...
00:05:57 <jlaska> #topic Why are we here?
00:06:05 <jlaska> #info The purpose is to decide whether the beta has met the release criteria
00:06:25 <jlaska> I'm sure everyone has this memorized by now ... but the beta release criteria can be found at
00:06:29 <jlaska> #link https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
00:06:59 <jlaska> #info Oxf13 representing release engineering
00:07:07 <jlaska> #info adamw representing QA
00:07:16 <jlaska> who wants to play the role of notting?
00:07:52 <jlaska> well, we can just get moving and pull in folks as needed
00:08:03 <jlaska> #info ______ representing devel
00:08:04 <Oxf13> what role does notting usually represent?
00:08:09 <Oxf13> ah devel.
00:08:10 <adamw> puck
00:08:15 <jlaska> heh
00:08:26 <jlaska> #topic Go or No Go?
00:08:48 <jlaska> want to walk the 4 bugs on F13Beta - https://bugzilla.redhat.com/showdependencytree.cgi?id=F13Beta&hide_resolved=1 ?
00:09:47 <adamw> sure
00:09:51 <jlaska> .bug 567346
00:09:53 <zodbot> jlaska: Bug 567346 gpk-update-viewer does not install updates if there is any dependency issue, and does not correctly report this - https://bugzilla.redhat.com/show_bug.cgi?id=567346
00:10:12 <adamw> i'm happy with this one, i reckon it could be closed
00:10:20 <adamw> anyone seen the bug since the newer pk landed?
00:10:40 <jlaska> I just completed 2 pk updates from RC3 -> updates-testing
00:10:49 <jlaska> but I don't believe there were any deps problems
00:10:54 <wwoods> what's the test case? does it fail if there's anything that has extra deps, or only when there's broken deps?
00:11:28 <wwoods> (if the latter.. we should probably set up an intentionally-broken repo to use for future testing)
00:11:32 <adamw> the reliable case was broken deps
00:11:37 <adamw> i once saw it without any dep problems
00:11:40 <jlaska> wwoods: that wouldn't be a bad idea
00:11:40 <adamw> but haven't seen it since the new pk
00:11:56 <jlaska> #idea test case idea - create a test repo with intentionally broken deps
00:11:56 <adamw> an intentionally-broken test repo is a good idea, yes.
00:12:23 <wwoods> wouldn't be too hard to have a fake glibc package with an epoch of 1337 which depended on libnotappearinginthisdistro
00:12:41 <jlaska> okay, what's the action on this bug ... close it out?
00:12:48 <adamw> yeah, i think so.
00:13:06 <jlaska> .bug 577708
00:13:07 <zodbot> jlaska: Bug 577708 Black screen during graphical kickstart install - https://bugzilla.redhat.com/show_bug.cgi?id=577708
00:13:28 <jlaska> This was found during RC testing, and we realized this would impact preupgrades too
00:13:53 <jlaska> preupgrade uses Branched nightly images ... not the beta images
00:14:29 <adamw> my bottom line on this one is if we can fix preupgrade before beta release, we're okay...
00:14:29 <wwoods> so a fix can be pushed out post-beta?
00:14:41 <jlaska> wwoods: yeah, I believe so
00:14:54 <jlaska> shall we leave it on the list to track getting the anaconda fix post-Beta?
00:14:54 <wwoods> or, really, "async from the beta images/trees"
00:14:57 <adamw> and even if we can fix it shortly after. but we do need to make it possible to test pre-upgrade.
00:15:17 <jlaska> Oxf13: objections?
00:15:31 <adamw> jlaska: no, i'd say that's an abuse of the blocker list...we have to clear it. if it's not blocking the release, it shouldn't be o n the blocker list
00:15:46 <adamw> it's not an 'important bugs' list
00:15:52 <jlaska> adamw: right, I was treating this like we treated preupgrade from N-1 release
00:16:04 <jlaska> we left it on the list until the N-1 preupgrade was available
00:16:20 <adamw> well, that was different: we decided that had to be fixed before the release went out, but could be done after the images  were done
00:16:22 <jlaska> either way ... as you said, would be good to have the fix available for beta testers
00:16:32 <adamw> in this case we're okay with the fix coming after the beta release, as long as it's not too far after
00:16:38 <jlaska> okay
00:16:45 <adamw> so we're not blocking the release on it
00:16:50 <jlaska> alright, I'll remove it
00:16:53 <Oxf13> sorry back at the keyboard
00:17:32 <Oxf13> I'm on the fence, since I think we're going to slip, so we could conceivably get this in.
00:17:40 <Oxf13> also the fix was more targetted than I thought it was
00:18:02 <jlaska> want to come back to this once we hit the last bug?
00:18:57 <adamw> whether we take a fix if we slip seems a differnet question from whether it's a blocker
00:18:57 <jlaska> .bug 578391
00:19:00 <zodbot> jlaska: Bug 578391 Get an error to transfer the install image to hard drive - https://bugzilla.redhat.com/show_bug.cgi?id=578391
00:19:07 <jlaska> adamw: right
00:19:19 <jlaska> okay, this bug was the reason for RC#3
00:19:23 <Oxf13> yeah, I guess, we're not really talking about "would we take it" we're more talking about "would we slip for it"
00:19:42 <jlaska> I've confirmed the issue is resolved when installing from boot.iso and DVD iso
00:19:57 <wwoods> nothing bad happened here
00:20:06 <jlaska> wwoods: you got through one too?  goodly
00:20:26 <Oxf13> I also confirmed
00:20:34 <jlaska> nice, this seems to be looking in good shape then
00:20:43 <jlaska> alright ... main event time ...
00:20:45 <wwoods> yeah, I did a netinst and a DVD install
00:20:46 <Oxf13> and I did a split-media install with multiple switching and the original problem of eject at end of install is also fixed
00:21:02 <jlaska> okay, I'll move it off the list then ... I think we have more eyes on it now
00:21:16 <adamw> if we have three people confirming it's fixed can't we just close it?
00:21:23 <jlaska> yup, doing that
00:21:26 <adamw> seems definitive enough
00:21:26 <Oxf13> well
00:21:30 <Oxf13> hold on a sec
00:21:33 * jlaska holds
00:21:42 <Oxf13> we've all confirmed it using an anaconda build that isn't even in updates-testing yet
00:21:58 <jlaska> oh I see
00:22:00 <Oxf13> what we should do, is create the anaconda update request, and then all of us give it karma
00:22:05 <Oxf13> and let the bodhi system manage the bug
00:22:15 <adamw> fair enough
00:22:47 <jlaska> okay ... last one
00:22:51 <jlaska> .bug 578633
00:22:52 <zodbot> jlaska: Bug 578633 Unable to enter passphrase to unlock encrypted disk partitions - https://bugzilla.redhat.com/show_bug.cgi?id=578633
00:24:07 * halfline materializes
00:24:15 <jlaska> I don't believe the criteria explicitly mention that the system must boot with encryption ... but I gather that's implied in the Alpha criteria
00:24:20 <Oxf13> and this one is probably my fault
00:24:24 <jlaska> "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled "
00:24:38 <Oxf13> I didn't dig deep enough into a proposed Beta blocker, and wound up pulling a build that wasn't necessary
00:24:45 <adamw> lemme see
00:25:27 <adamw> jlaska: you could argue that the install completes. that's just bad phrasing in the criteria, though. i think we clearly intend for the installed system to be bootable.
00:26:18 <jlaska> adamw: yeah, I would agree
00:26:33 <Oxf13> yeah, I don't believe we consider the "install complete" until you've successfully rebooted afterward
00:26:46 <adamw> do we have any kind of workaround for this? text boot?
00:27:07 <Oxf13> nope, text boot is still horked
00:27:13 <Oxf13> (still uses plymouth)
00:27:31 <halfline> well i think the issue is just text boot if i understand it right
00:27:38 <adamw> if there isn't a workaround, i think it's pretty hard to ignore
00:27:40 <Oxf13> halfline: oooh?
00:27:45 <jlaska> halfline: in the case where it worked for me ... I saw the blue bars at the bottom
00:28:04 <jlaska> but I've not managed to reproduce that scenario yet
00:28:16 <halfline> jlaska: what about in the case where it failed?
00:28:24 <halfline> blue bars is text boot
00:28:39 <adamw> fedora logo is graphical boot
00:28:43 <jlaska> no blue bars ... just that assert and the passphrase prompt
00:29:11 <halfline> but the expectation is you would have gotten blue bars right?
00:29:19 <halfline> this is in a vm?
00:29:25 <jlaska> yeah
00:29:33 <halfline> right, i think this only affects text boot
00:29:43 <Oxf13> let me see if I can do a gui install here
00:29:50 <Oxf13> I think this radeon is capable of it
00:29:55 <halfline> so workaround would be vga=0x318 or similar
00:30:13 <adamw> didn't we have a rather similar issue in f12?
00:30:24 <halfline> who knows, that was ages ago
00:30:29 <Oxf13> halfline: I see the problem even with KMS is involved and my text gets really small
00:31:17 <jlaska> so how's this looking for a go/no_go call tonight?
00:32:02 <halfline> Oxf13: how are you seeing text if you're doing a graphical boot?
00:32:10 <halfline> booting without rhgb ?
00:32:19 <Oxf13> I'm attempting to setup a graphical boot right now
00:32:30 <Oxf13> the time I reproduced this problem I don't think I had the full graphical plymouth setup
00:32:56 <Oxf13> text was tiny, prompt at the top of the screen for hte passphrase
00:33:06 <halfline> ohh you didn't have the splash plugins installed?
00:33:13 <Oxf13> apparently not
00:33:16 <adamw> Oxf13: whether kms kicks in isn't important to plymouth, whether it's in text or graphical mode is more important
00:33:26 <adamw> (right halfline?)
00:34:05 <halfline> well for this bug, whether or not a graphical splash is run is what's revelent i think
00:34:08 <Oxf13> jlaska: I'm still leaning toward no go, seems any minimal + encryption install would fal
00:34:32 <jlaska> okay
00:34:34 <halfline> yea, honestly, even if vga=0x318 is a workaround
00:34:51 <halfline> it's still a pretty bad out of the box experience
00:35:10 <jlaska> so I'm hearing 2 no_go's
00:35:14 <adamw> i'm pretty on the fence if it only affected text mode, but i wouldn't be unhappy if we slip
00:35:20 <halfline> well i'm not sure my vote counts :-)
00:35:24 <Oxf13> channeling notting, pretty sure he wouldn't go with this.
00:35:30 <adamw> just as a point of info, if we slip, that slips the final release too, right?
00:35:35 <jlaska> halfline: you get the devel vote tonight
00:35:35 <Oxf13> halfline: I think it does, given your the package owner, and you can represent devel
00:35:45 <halfline> in that case NO GO
00:35:47 <Oxf13> adamw: since we slipped Alpha, I believe that holds true
00:35:51 <poelcat> adamw: i think it should
00:36:08 <jlaska> I've got 3 +1's on no_go
00:36:18 * jlaska pulls out the #agreed stamp
00:36:47 <jlaska> #agreed not enough information known about bug#578633 failure conditions
00:37:04 <adamw> i'd say '#agreed even in the most conservative case we consider it a no-go'
00:37:05 * Oxf13 thinks this will be another case of having everything ready to go tomorrow (:
00:37:24 <jlaska> Oxf13: probably ... that's our luck this release
00:37:28 <Oxf13> there is also the data point that our Live RC images haven't gotten much/any testing
00:37:38 <adamw> yep.
00:37:41 <Oxf13> we keep running into problems with the standalone stuff and not getting to the live images
00:37:47 <adamw> and we haven't run the desktop matrix yet.
00:37:57 <adamw> i'm not at all unhappy to get more time to do the testing better.
00:38:03 <poelcat> adamw: so the rest of the release criteria aren't met anyway?
00:38:21 <Oxf13> so this is a case of A) started RC process late, B) one too many RCs and C) jumped the gun on pulling in builds that really weren't necessary
00:38:23 <adamw> poelcat: rather, we can't yet say that they have been met. they may be met, but we don't know that =)
00:38:41 <jlaska> so we're not able to confirm they've been met
00:38:45 <adamw> Oxf13: well, the entire candidate process was late - we were behind from tc1
00:38:58 <jlaska> so 1 week slip
00:38:59 <jlaska> ?
00:39:00 <poelcat> :)  if they aren't confirmed met, they are unmet in my book
00:39:27 <poelcat> jlaska: new GA 2010-05-18
00:39:31 <jlaska> #agreed Beta release criteria have not been met, 1 week slip for F-13-Beta
00:39:58 <adamw> Oxf13: for the record i was planning to test the live images, but they came later than the traditional isos so i decided i'd start by testing traditional install to at least contribute something...didn't get to the live images before this meeting in the end.
00:40:44 <jlaska> There was general agreement that 2 slips would need to adjust the F-13 Final date ... is there any debate there?
00:40:50 <brunowolff> Note that there have been some late changes to the desktop live spin and that other spins depend on that.
00:41:01 <adamw> jlaska: i think that's a question for the project-wide meeting, as that's where it was initially decided
00:41:20 <brunowolff> I just cleanup up some fallout with that tonight for qa-test-day spin.
00:41:22 <poelcat> adamw: incorrect
00:41:31 <adamw> poelcat: ah, okay :)
00:41:38 <jlaska> yeah, I thought we discussed that here
00:41:47 * adamw must be remembering wrong
00:41:58 <poelcat> project wide meeting is just to cross-functional coordination
00:42:14 <Oxf13> jlaska: none here
00:42:22 <jlaska> okay ... so let's close this puppy out
00:42:24 <poelcat> adamw if the bits aren't ready, there is no point in starting that process
00:42:27 <jlaska> #topic What's next?
00:42:36 * poelcat will update the schedule
00:42:36 <Oxf13> announce the slip
00:42:40 <jlaska> this same meeting (hopefully different outcome) in 1 week
00:42:40 <Oxf13> update the schedule
00:42:58 <adamw> poelcat: well, we did the project-wide meeting for alpha, when we slipped?
00:43:10 <poelcat> adamw: we moved it to the next week
00:43:11 <jlaska> poelcat: can you update the schedule?
00:43:17 <poelcat> jlaska: will do
00:43:19 <adamw> hmm. need to adjust my memory banks...
00:43:30 <jlaska> #action poelcat will update schedule with 1 week slip
00:43:31 <poelcat> wiki tonight.. TJ, ical, etc. tomorrow
00:43:47 <jlaska> Oxf13: are you okay doing the devel-announce@ ?
00:43:53 <Oxf13> sure
00:43:53 <jlaska> or do you need someone else to grab that
00:44:11 <jlaska> #action Oxf13 will post slip announcement
00:44:35 <jlaska> #info New go/no_go meeting @ 2010-04-08 20:00 EDT
00:44:37 <Oxf13> just to be clear, we're placing blame in improperly pulled in plymouth, and inability to complete test matrix in time given how late RC3 landed
00:45:40 <jlaska> meh ... I focus on just that we couldn't confirm Beta criteria have been met
00:45:51 <jlaska> there were lots of factors
00:46:03 * jlaska reminds folks to jot down notes at https://fedoraproject.org/wiki/Fedora_13_QA_Retrospective
00:46:12 <jlaska> okay ... anything else to discuss here?
00:46:32 <adamw> not from me
00:46:46 <jlaska> halfline: Oxf13 ?
00:47:01 <Oxf13> I don't have anything.  The anaconda build will be pushed stable this evening
00:47:15 <poelcat> https://fedoraproject.org/wiki/Releases/13/Schedule#Key_Milestones reflects new dates
00:47:18 <Oxf13> and if I get a plymouth build I can test that too
00:47:48 <jlaska> okay ... I'll close the meeting in 30 seconds ...
00:48:41 <jlaska> okay, thanks everyone
00:48:45 <jlaska> #endmeeting