16:07:23 <tflink> #startmeeting f19beta-blocker-review-8
16:07:23 <zodbot> Meeting started Wed May 22 16:07:23 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:24 <tflink> #meetingname f19beta-blocker-review-8
16:07:24 <tflink> #topic Roll Call
16:07:24 <zodbot> The meeting name has been set to 'f19beta-blocker-review-8'
16:08:26 * kparal here for once, finally
16:08:52 * adamw is here
16:08:58 <adamw> but bz is misbehaving again
16:09:11 * jreznik is proxy error 502 here
16:09:32 * tflink is trying to report a bug, hopes it goes through
16:11:37 * satellit here
16:15:43 <adamw> i think bugzilla swallowed tflink
16:15:52 <tflink> no a bug did
16:16:02 <brunowolff> bugz just worked for me.
16:16:10 <tflink> reasonably likely to be a blocker, dev was waiting on logs
16:16:21 <adamw> oh, your dmraid thing? well that's goddamn peachy
16:16:38 <tflink> yeah, fun times
16:17:56 <tflink> I really wish libreport had a "try again" button when it hits bugzilla errors
16:18:18 <tflink> do we want to try to get through what's on the list?
16:18:42 <jreznik> tflink: I'd say, we can try - collective memory of some bugs could help :(
16:19:39 <adamw> sure, let's do some bureaucracy
16:20:12 <tflink> but first, boilerplate!
16:20:18 <tflink> #topic Introduction
16:20:23 <tflink> Why are we here?
16:20:23 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:20:28 <tflink> #info We'll be following the process outlined at:
16:20:28 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:20:33 <tflink> #info The bugs up for review today are available at:
16:20:33 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:20:38 <tflink> #info The criteria for release blocking bugs can be found at:
16:20:38 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:20:40 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:20:43 <tflink> #info Up for review today, we have:
16:20:50 <tflink> #info 2 Proposed Blockers
16:20:50 <tflink> #info 1 Accepted Blockers
16:20:50 <tflink> #info 2 Proposed Freeze Exceptions
16:20:50 <tflink> #info 10 Accepted Freeze Exceptions
16:21:11 <tflink> note that the list could be out of date - it's likely that the sync isn't working all that well right now
16:21:47 <tflink> if there are no objections, we'll start with the proposed blockers
16:21:58 <tflink> #topic (965974) Software selection can't be exited in text mode
16:21:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965974
16:21:58 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:22:57 <tflink> sounds like a pretty clear blocker to me :-/
16:23:22 <adamw> well i could argue it
16:23:23 <kparal> I am pretty disenchanted by the fact that the feature was not present in RC2
16:23:40 <adamw> yeah, what's happening is sbueno is trying to make text mode basically a full mode
16:23:43 <kparal> doesn't seem like something that had to enter Beta
16:23:51 <adamw> and they keep ramming all the changes for that into every new anaconda build on the basis that it needs to be tested
16:24:19 <adamw> so you _can_ still do a text install if you dodge the software spoke...
16:24:23 <adamw> but yeah, it's a pretty weak argument
16:25:04 <jreznik> it's a weak argument but it really wasn't handled very well
16:25:18 <tflink> do we want this as a blocker, though?
16:25:22 <tflink> or is it more FE?
16:26:00 <kparal> I'm ok with FE. but we will have to respin anyway
16:26:13 * satellit does it install default?
16:26:25 <tflink> it's more of a "if this doesn't work 100%, will we block release?"
16:26:26 <adamw> well we're re-spinning for the DVD error already i believe
16:26:27 <kparal> satellit: if you don't enter the spoke, it works, yes
16:26:40 <adamw> so this has missed that boat
16:26:42 <kparal> satellit: but it says gnome is the default and installs minimal system instead :)
16:26:43 <jreznik> kparal: dgilmore already started respun of dvd
16:26:48 <adamw> 'and i don't think any other proposed blockers are in anaconda
16:26:52 <brunowolff> Can they revert just that change, or would that likely break other stuff.
16:27:11 <tflink> adamw: except for the dmraid one I'm working on
16:27:20 <adamw> it might be difficult to revert exactly the right set of bits at this point, i think, given how the commit history has been
16:27:24 <adamw> tflink: that's in kpartx isn't it?>
16:27:26 <tflink> well, as soon as I _can_ file the damn bug
16:27:35 <tflink> adamw: sounds like it's the command sent to kpartx
16:27:37 <adamw> ah
16:27:54 <tflink> not sure where the fix is yet, hoping it's pretty simple
16:28:08 <jreznik> tflink: could you sync up with guys on #anaconda without bug for now? instead of fighting bz
16:28:10 <tflink> but I digress
16:28:22 <tflink> jreznik: already working with dlehman over PM
16:28:32 <jreznik> tflink: cool, thanks
16:29:02 <tflink> anyhow, thoughts on this bug?
16:29:06 <tflink> FE? blocker?
16:29:27 <jreznik> it's probably better to accept the fix (as far as I know it exists, even as FE) than trying to revert now
16:29:58 <adamw> i'm definitely +1 fe
16:30:05 <tflink> yeah, same here
16:30:12 <adamw> it feels weird to be blocking on major new features being thrown in at the last minute, but i can see the +1 blocker argument
16:30:18 <tflink> a bit on the fence about blocker, though
16:30:28 <adamw> a fully-featured text install which invites you to shoot your foot is probably worse than a minimalist one
16:31:45 <kparal> most people will probably enter that spoke
16:31:51 <tflink> would we slip if this was the last blocker at go/no-go?
16:31:53 <kparal> however, not that many people will use text interface
16:32:22 <jreznik> tflink: see kparal - probably not many people will use it and I think it does not pass "slip" test
16:32:36 * satellit fix is to restart install?
16:32:41 <kparal> satellit: yes
16:32:48 <tflink> we could play the "blocker for now and de-blockerify it tomorrow if not fix" game but I don't care for that idea much
16:32:49 <kparal> or read the docs
16:32:50 <jreznik> so I'm definitely +1 to FE
16:32:52 <adamw> yeah, you can't get out once you're in
16:33:00 <adamw> tflink: let's not do that, that's horrible.
16:33:19 <tflink> it sounds like we're mostly -1/+1
16:33:34 <tflink> more -1 blocker than +1 blocker, anyways
16:33:35 <kparal> can we respin our respin?
16:33:39 <kparal> with anaconda 19.30?
16:33:44 <jreznik> in worst case, it could be documented to avoid the spoke in text mode (do people even know we have text mode ;-)
16:34:01 <brunowolff> I'm more +1 FE, as more of text mode can still be tested, and you can still use graphical mode for installs where you need to set software.
16:34:02 <tflink> does anyone know how big the fix is?
16:34:09 <tflink> how likely is it to make text installs worse?
16:35:09 <brunowolff> It would be nice if this one got remembered for the retrospective, as it sounds like the Anaconda team wasn't being risk adverse enough during the beta freeze.
16:35:37 <adamw> tflink: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-May/004261.html
16:35:39 <kparal> http://paste.fedoraproject.org/13750/92405271/
16:35:42 <kparal> this is the patch
16:35:58 <adamw> brunowolff: i've been talking to bcl about it. they are aware of our concerns...
16:36:26 <adamw> it at least applies entirely to the software spoke
16:36:41 <adamw> so given that the software spoke is basically just a big trap at present, it's unlikely to make things *worse*
16:36:59 <adamw> unless it somehow is such terrible code it causes the installer to fail to run at all, or something reasonably unlikely like that.
16:37:09 <jreznik> yep
16:37:57 <adamw> hi sbueno
16:38:02 <jreznik> sbueno: hi! we are trying decide how invasive is your fix
16:38:09 <jreznik> seems like pretty limited one
16:38:24 <tflink> it still sounds like we're -1 blocker
16:38:52 <sbueno> not a lot is changed. there was an issue with threading which was causing the traceback
16:39:25 <sbueno> basically, a thread was just initialized in the wrong part of software selection
16:39:56 <tflink> proposed #agreed 965974 - RejectedBlocker AcceptedFreezeException - While this does make the text installer more useful by allowing package set selection, the text installer isn't completely broken and workarounds do exist (use graphical installer or kickstart). A tested fix would be considered during beta freeze.
16:40:01 <adamw> ack
16:40:28 <jreznik> ack
16:40:41 <kparal> ack
16:41:43 <tflink> #agreed 965974 - RejectedBlocker AcceptedFreezeException - While this does make the text installer more useful by allowing package set selection, the text installer isn't completely broken and workarounds do exist (use graphical installer or kickstart). A tested fix would be considered during beta freeze.
16:41:49 <brunowolff> ack
16:41:50 <tflink> #topic (965940) Most package groups missing from F19 Beta RC3 DVD
16:41:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965940
16:41:50 <tflink> #info Proposed Blocker, pungi, NEW
16:42:02 <adamw> man, i dunno, this seems pretty borderline
16:42:03 <adamw> :P
16:42:30 <tflink> ?
16:43:11 <kparal> at least the DVD could get slimmer, when the desktops are not there
16:43:18 <brunowolff> Isn't this one moot now?
16:43:51 <tflink> do we have a release criteria for this?
16:44:04 <kparal> hehe, good question
16:44:16 <tflink> nvm, it sounds like all of the DEs are gone
16:44:42 <tflink> I believe that means that graphical DE install from DVD w/o network is not possible
16:44:54 <tflink> adamw: can you confirm my reading of the bug?
16:44:59 <kparal> unless we require all present DEs to be installable :)
16:45:07 <kparal> tflink: correct
16:45:42 <tflink> kparal: don't we require KDE and Gnome at least?
16:46:09 <j_dulaney> Indeed
16:46:13 <tflink> "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
16:46:25 <j_dulaney> +1
16:46:25 <kparal> you're right
16:46:26 <tflink> so clear blocker unless I'm misunderstanding something
16:46:32 <kparal> how clever we were
16:46:43 <kparal> +1 :)
16:46:47 <j_dulaney> Rather difficult to install that which is not there
16:47:03 <tflink> proposed #agreed 965940 - AcceptedBlocker - Violates the following F19 beta release criterion for KDE and Gnome desktop environments: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
16:47:08 <kparal> ack
16:47:09 <brunowolff> ack
16:47:32 <jreznik> ack
16:47:54 <adamw> ack
16:48:20 <tflink> #agreed 965940 - AcceptedBlocker - Violates the following F19 beta release criterion for KDE and Gnome desktop environments: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
16:48:23 <j_dulaney> ack
16:48:29 <tflink> #topic (966162) fedora-dmraid-activate shouldn't tell kpartx to use a partition delimiter
16:48:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966162
16:48:34 <tflink> #info Proposed Blocker, dmraid, NEW
16:48:40 <tflink> this is the dmraid issue I was talking about
16:49:02 <tflink> it prevents install on dmraid systems
16:49:45 <tflink> the caveat is whether we consider dmraid to be common enough to block over
16:49:54 <adamw> we have done in the past, and i don't see a reason to change
16:49:58 <adamw> we ought to be consistent
16:50:06 <kparal> dmraid is software raid, right?
16:50:10 <j_dulaney> Indeed
16:50:21 <kparal> i see criterion for hw raid
16:50:35 <adamw> it's firmware raid
16:50:41 <kparal> " Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions "
16:50:42 <nirik> "fakeraid" :)
16:50:42 <adamw> with any controller except intel
16:50:46 <jreznik> and it's limited to preexisting partitions only?
16:50:54 <adamw> kparal: no, not that one
16:50:58 <tflink> not sure, to be honest
16:51:07 <adamw> "The installer must be able to detect and install to hardware or firmware RAID storage devices. "
16:51:09 <tflink> I've only tried it with pre-existing partitions
16:51:28 <tflink> dmraid seems to be relatively rare anymore
16:51:35 <tflink> or do amd boards still use it
16:51:36 <adamw> i wouldn't say so.
16:51:45 <adamw> yes, amd boards won't be using intel raid controllers
16:52:02 <jreznik> tflink: from description it looks like "This bug is preventing any installation of Fedora 19 onto dmraid sets with preexisting partitions."
16:52:07 <adamw> and it's not like all the motherboards that were made a few years back when there was a wider range of controllers on intel boards have spontaneously combusted
16:52:14 <nirik> is there a workaround?
16:52:24 <nirik> (ie, wipe paritions? )
16:52:28 <tflink> ok, the only dmraid boxes I have are ~10 years old
16:52:31 <adamw> if it only affects pre-existing partitions the workaround would be 'wipe the array first'...yeah
16:52:52 <tflink> like I've said, I haven't tried that yet but can do so
16:53:10 <brunowolff> Wiping may not work so well in dual boot cases. Dual boot is one of the reasons you might prefer dmraid to md.
16:53:10 <adamw> would anyone vote -1 blocker if that works?
16:53:16 <adamw> right
16:53:39 <adamw> there are systems which come from the factory with firmware raid configured, if you have windows installed to it, you probably don't want to nuke it
16:53:45 <nirik> yeah.
16:53:53 <nirik> sadly seems blocker based on critera.
16:54:23 <jreznik> tflink: do you have more info from dlehman how does it look like and what would be needed to fix it?
16:54:29 <jreznik> adamw: sure
16:54:38 <tflink> jreznik: not anything more than what's in the bug
16:54:45 <jreznik> [18:54] <dlehman> jreznik: I think that workaround will do, yes
16:54:58 <tflink> it sounds like the fix is needed from dmraid folks
16:55:23 <adamw> hmm
16:55:29 <adamw> do we have one in our pokedex?
16:56:42 <tflink> I don't recall who works on dmraid but it's assigned to LVM and dm team
16:57:18 <adamw> * Thu Nov 01 2012 Peter Rajnoha <prajnoha@redhat.com> - 1.0.0.rc16-18
16:57:18 <adamw> - Add fedora-dmraid-activation script and dmraid-activation.service systemd unit
16:57:18 <adamw> .
16:57:26 <adamw> that was the last time a human touched the package, more or less
16:57:36 <jreznik> prajnoha
16:58:07 <jreznik> I don't see him online, it's nearly 7pm here...
16:59:12 <tflink> it sounds like we're mostly +1 blocker?
16:59:26 <tflink> not -1, anyways
17:00:09 <jreznik> well, how it's defined with using preexisting partitions for beta?
17:01:08 <tflink> jreznik: depends on if you combine the "must be able to remove stuff" criterion
17:01:43 <tflink> we could certainly do it, but it would be a fudge
17:02:16 <tflink> as I read it, this is a violation of the release criteria if dmraid is common enough to block release over
17:03:47 <adamw> yeah, i'd feel shitty if we fudge this one
17:03:52 <adamw> and we ought to be able to do something about it
17:04:02 <adamw> and at least it can't break anything but dmraid worse
17:04:14 <nirik> if dmraid isn't common enough anymore, we should adjust the critera... but for f20?
17:04:24 * j_dulaney is leaning +1 blocker, because it does hit the criteria
17:04:38 * j_dulaney is against adjusting criteria mid-release
17:04:55 <adamw> i don't think 'dmraid isn't common any more' really flies anyho.
17:05:01 <tflink> proposed #agreed 966162 - AcceptedBlocker - Violates the following F19 beta criterion for dmraid devices: "
17:05:16 <tflink> whoops
17:05:45 <tflink> proposed #agreed 966162 - AcceptedBlocker - Violates the following F19 beta criterion for dmraid devices: "The installer must be able to detect and install to hardware or firmware RAID storage devices"
17:05:56 <brunowolff> ack
17:06:21 <adamw> ack
17:06:44 <tflink> other ack/nack/patch?
17:07:02 <j_dulaney> ack
17:07:27 <tflink> #agreed 966162 - AcceptedBlocker - Violates the following F19 beta criterion for dmraid devices: "The installer must be able to detect and install to hardware or firmware RAID storage devices"
17:07:31 <nirik> ack
17:08:00 <tflink> ok, that's all of the proposed blockers that I had on my list - moving on to the proposed FE
17:08:07 <tflink> #topic (869364) Installation Destination screen is sometimes rendered not at full screen width
17:08:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869364
17:08:12 <tflink> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
17:08:34 <adamw> we don't have a fix for this, so it's kinda moot
17:08:36 <adamw> let's just move on
17:09:29 <tflink> ok
17:09:51 <tflink> same thing with the other proposed FE
17:10:05 <tflink> shall we skip?
17:10:43 <j_dulaney> +1
17:10:49 <tflink> rather, any objections to skipping?
17:10:53 <brunowolff> No need to drag things out.
17:11:21 <tflink> the only accepted blocker on my list is VERIFIED, so if there are no objections, I'll move into open floor
17:13:13 <tflink> #topic Open Floor
17:13:25 <tflink> Anything else that needs to be brought up?
17:14:17 * j_dulaney is good
17:14:30 <nirik> so, go/no-go is tomorrow?
17:14:39 <jreznik> anything else? try to sort out the dmraid blocker :)
17:14:41 <tflink> yep
17:14:41 * nirik wonders what our chances are. ;)
17:14:57 <tflink> slim without a marathon testing session
17:15:09 * tflink really wishes he had remembered to test dmraid the other day
17:15:20 * j_dulaney isn't down for marathon testing
17:15:46 <nirik> perhaps some folks will be. We can try and see.
17:15:47 <tflink> on the other hand, if we only change dmraid, we probably don't have to re-test everything else
17:15:56 * nirik doesn't have any dmraid here.
17:16:03 <j_dulaney> Nor I
17:16:08 * tflink has 2 10 year old boxes with dmraid
17:16:20 <tflink> a p4 and a dual opteron
17:16:23 <j_dulaney> Well, we do have to test to see if desktops show up :)
17:16:24 <jreznik> tflink: if you could help, it would be great
17:16:43 <tflink> jreznik: who do you think started all this?
17:16:46 <tflink> :)
17:16:48 * j_dulaney has old boxen, but not with multiple hds
17:17:18 <jreznik> I know, last minute surprise from tflink
17:18:02 <tflink> dmraid was broken in other ways until RC2
17:18:10 <tflink> this is a new/additional breakage
17:18:59 <j_dulaney> Yay, rpmbuild is writing the rpms
17:20:04 <adamw> we should be fine for go/no-go. we've done beta testing in much less time before.
17:20:19 <adamw> okay, i'll go fix dmraid.
17:20:20 <jreznik> so what would be plan - to build fixed dmraid and then trying smoke with both pre-existing and clean ones?
17:20:42 * satellit edit soas .ks to add lightdm and openbox to %packages ?
17:20:54 <jreznik> adamw: ok, seems like nobody from the lvm team is familiar with dmraid or not online now, thanks - talking to peter
17:23:00 * satellit adding those 2 makes soas spin live work...
17:24:00 <tflink> either way, it sounds like a fun day ahead
17:24:32 * tflink sets the fuse for [0,5] minutes, can continue the fun in #fedora-qa
17:24:34 <jreznik> and fun night, I'll try to follow up with you guys
17:26:50 <tflink> Thanks for coming, everyone
17:26:58 * tflink will send out minutes shortly
17:27:03 <tflink> #endmeeting