16:04:06 <tflink> #startmeeting f19alpha-blocker-review-6
16:04:06 <zodbot> Meeting started Wed Sep 18 16:04:06 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:06 <tflink> #meetingname f19alpha-blocker-review-6
16:04:06 <zodbot> The meeting name has been set to 'f19alpha-blocker-review-6'
16:04:06 <tflink> #topic Roll Call
16:04:12 <tflink> #chair kparal adamw
16:04:12 <zodbot> Current chairs: adamw kparal tflink
16:04:28 * pschindl is here
16:04:30 * mkrizek is here
16:04:35 * pwhalen is here
16:04:43 * roshi is here
16:05:04 * kparal 
16:05:20 <tflink> woah, lots of people
16:06:28 <adamw> ahoyhoy
16:06:35 <tflink> time to get started with the always exciting boilerplate
16:06:40 <tflink> Why are we here?
16:06:40 <tflink> 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:06:46 <tflink> We'll be following the process outlined at:
16:06:46 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:52 <tflink> The bugs up for review today is available at:
16:06:52 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:58 <tflink> The criteria for release blocking bugs can be found at:
16:06:59 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:07:05 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria
16:07:08 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:07:11 <tflink> hrm
16:07:13 <tflink> that would be out of date
16:07:15 <tflink> #undo
16:07:15 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d30f190>
16:07:16 <tflink> #undo
16:07:16 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d30f910>
16:07:19 <tflink> #undo
16:07:19 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d30f350>
16:07:29 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:07:49 <tflink> .moar roshi spam
16:07:49 <zodbot> here spam, have some more roshi
16:07:59 <tflink> wow, that order was backwards
16:08:03 <kparal> tflink: I do the same mistake all the time :)
16:08:05 <tflink> .moar spam roshi
16:08:05 <zodbot> here roshi, have some more spam
16:08:20 <roshi> well, now you went and made spam think I was all into them
16:08:26 <tflink> #info Up for review today, we have:
16:08:34 <tflink> #info 0 Proposed Blockers
16:08:34 <tflink> #info 8 Accepted Blockers
16:08:34 <tflink> #info 2 Proposed Freeze Exceptions
16:08:34 <tflink> #info 10 Accepted Freeze Exceptions
16:09:14 <kparal> looking good!
16:09:34 <tflink> since we have no proposed blockers today, any objections to starting with the proposed FE?
16:09:58 <kparal> go ahead
16:10:39 <tflink> #topic (1007448) Anaconda in netinst won't proceed to next screen (or is very slow)
16:10:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1007448
16:10:45 <tflink> #info Proposed Freeze Exceptions, anaconda, VERIFIED
16:11:14 <kparal> +1 fe
16:11:17 <roshi> +1
16:11:17 <tflink> +1 fe
16:11:21 <roshi> fe
16:11:36 <kparal> the title is misleading, it's just slow
16:11:52 <roshi> .moar iron 1007448
16:11:52 <zodbot> here 1007448, have some more iron
16:11:53 <kparal> but it's already pushed in anaconda I guess, so this is an academic discussion
16:12:21 <tflink> proposed #agreed 1007448 - AcceptedFreezeException - While not a release blocking issue, this bug is an annoyance and would be good to fix before f20 alpha release. A tested fix would be considered past freeze
16:12:27 <kparal> ack
16:12:28 <roshi> ack
16:12:29 <pschindl> ack
16:12:36 <kparal> who's the secretary btw?
16:12:38 <mkrizek> ack
16:12:41 <tflink> #agreed 1007448 - AcceptedFreezeException - While not a release blocking issue, this bug is an annoyance and would be good to fix before f20 alpha release. A tested fix would be considered past freeze
16:12:52 <tflink> kparal: sounds like we have a volunteer :) I forgot to ask
16:12:59 <roshi> I got it :)
16:13:05 <kparal> roshi: great
16:13:20 * roshi will actually do it today this time - since he has bz access
16:13:55 <tflink> #topic (1009132) updates-plugin-WARNING **: failed to download: The backend exited unexpectedly.
16:13:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009132
16:14:01 <tflink> #info Proposed Freeze Exceptions, gnome-settings-daemon, NEW
16:15:00 <kparal> we might also tag this with FinalBlocker perhaps?
16:15:08 <kparal> +1 FE
16:15:17 <roshi> +1 iron
16:15:33 <tflink> wouldn't it be a beta blocker?
16:15:54 <tflink> +1 FE
16:15:56 <kparal> tflink: I see only "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image. " in Beta
16:16:11 <tflink> I thought there was a beta criterion for all graphical update methods
16:16:38 <mkrizek> the criterion listed in the bug is an alpha IMHO
16:16:39 <kparal> I don't see it
16:17:02 <kparal> mkrizek: it is, but read last paragraph in comment 1
16:17:23 <kparal> the problem is that it's very unclear what is 'default'
16:17:31 <kparal> gnome has several 'default' update apps
16:17:34 <tflink> yeah, I was about to wonder what the default was for gnome
16:18:09 <kparal> I guess the last time we actually took it as a blocker, because we said that if there is no clear default, all methods must work
16:18:11 <kparal> right, adamw ?
16:18:22 <kparal> but I don't know whether it was Alpha or later milestone
16:18:36 <adamw> i think f20 is a bit 'special' now we have multiple graphical methods
16:18:40 * adamw tries to catch up
16:18:51 <tflink> I'm not finding the criterion I was thinking of
16:18:56 <kparal> I'd be OK with postponing this bug into later milestone. but I think it should be a blocker, at least Final
16:18:58 <adamw> the criterion is really written under the assumption there's exactly one 'blessed' graphical update tool (at least per-desktop)
16:19:43 <adamw> now we have two the question would be 'which is default?'
16:20:03 <tflink> I suspect that it will be "gnome software" at some point, if that isn't the case already
16:20:07 <adamw> i haven't run any recent f20 builds; which of gnome-software or PK are you more likely to run into first? which one is run when an update notification pops up?
16:20:15 <tflink> but it would be nice if they didn't keep adding update avenues
16:20:16 <kparal> adamw: three. gnome-software as well?
16:20:18 <adamw> tflink: what's the case *right now* is what maters for alpha
16:20:25 <adamw> this is gnome-software, isn't it?
16:20:28 <tflink> yep
16:20:32 <adamw> "Updates aren't installed when I try to update with gnome-software"
16:20:36 <tflink> is hughsie still around?
16:20:55 <kparal> oh, I thought this is the 'update on reboot' approach
16:21:14 <kparal> pschindl: ?
16:21:43 <hughsie> okay, hi all
16:21:45 <tflink> hughsie: what's the default graphical method for installing updates in gnome for f20?
16:21:52 <tflink> PK or gnome-software?
16:22:23 <adamw> to clarify: not 'what is the planned default for final', but 'what would be considered the default *as of right now*'
16:22:29 <hughsie> tflink, well, if we're shipping gnome-software in comps (which i think we are) then it has to be the latter really
16:22:42 * adamw grabs an f20 live
16:22:49 <kparal> hughsie: and is "reboot at install updates" in gnome-shell user menu equivalent to "restart & install" in gnome-software?
16:22:50 <hughsie> you need to use gnome-settings-daemon and gnome-softwre from f20 koji for testing tho
16:22:50 <tflink> bah, that's not the answer I wanted to hear
16:22:56 <hughsie> kparal, yup
16:23:21 <hughsie> well, the "reboot and install updates" menu item is gone in gnome-shell for f20
16:23:23 <adamw> kparal: neither of them will necessarily hit this path, though.
16:23:31 <hughsie> so we had to have something trigger the offline update
16:24:03 <hughsie> if you're talking about #1009132 it's just a bug in either PK or yum
16:24:21 <hughsie> it would be the same between either the old "reboot and install" menu item and for gnome-software
16:24:24 <hughsie> it's ust the mechanism
16:24:46 <adamw> hughsie: yes, we're talking about 1009132, question is whether it blocks alpha
16:25:04 <pschindl> I just want to mention, that the bug is filed against the version from koji. Because the g-s-d on rc3 doesn't even try to update.
16:25:36 <adamw> so as of rc3 the status is that gnome-packagekit online update works OK, gnome-software and offline updates don't work at all?
16:25:41 <hughsie> pschindl, yup, to get that far you need koji
16:25:52 <hughsie> i'm trying to reproduce now, but got hit by the dhcp bug
16:26:00 <tflink> but if it's the default, isn't that still a blocker?
16:26:14 <tflink> or is the default expected to change before f20 release?
16:26:23 <hughsie> adamw, you can still use gpk-update-viewer manually, just all the notifications open up gnome-software now
16:26:26 <pschindl> if it has to be default for alpha, then it's blocker.
16:27:12 <hughsie> fwiw, " The backend exited unexpectedly." in the context of Fedora means "yum threw a backtrace"
16:27:16 <adamw> yeah...if all the notifications open gnome-software, it's hard to argue PK is the 'default' :(
16:27:21 <tflink> gnome software appears to be on the rc2 desktop live
16:27:40 <hughsie> adamw, sure, i think instance i would probably say g-s is the default
16:27:44 * adamw notes he did have a proposal in ages ago to not require graphical updates to work at alpha
16:27:57 <hughsie> and that means that all updates have to be done offline (unless yo use yum on the command line)
16:27:59 <tflink> yeah, that sounds sensical
16:28:09 <tflink> I have a hard time believing that alpha users can't use the CLI
16:28:17 <hughsie> so https://bugzilla.redhat.com/show_bug.cgi?id=1009132 is an important bug to fix
16:28:26 <hughsie> but i don't know if it qualifies as an alpha blocker
16:28:32 <hughsie> as you can still use yum
16:28:38 <adamw> per the criteria as they stand it pretty clearly does
16:28:42 * hughsie assumes you can use yum
16:28:45 <tflink> hughsie: with the way that the criteria are currently written, it's a clear blocker
16:29:03 <hughsie> pschindl, can you reproduce #1009132 reliably?
16:29:15 <tflink> "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
16:29:27 <hughsie> tflink, then it's a blocker, although i'm not sure about the rationale of it
16:29:58 * adamw is trying to find that proposal for weakening it, but can't. maybe i never sent it.
16:29:59 <pschindl> hughsie: I think so. I've reproduced it at least three times
16:30:01 <tflink> hughsie: yeah, that's what adamw was hinting at
16:30:11 <adamw> i remember it was sitting on my todo list forever
16:30:13 <tflink> or outright saying, as am I
16:30:27 <hughsie> pschindl, if i add some reprocing instructions to the bug, can you try pls
16:30:32 <tflink> if you refuse to use the CLI, maybe you shouldn't be using alpha
16:30:39 * hughsie is fighting with a VM
16:30:41 <adamw> so at this point we either take it as a blocker or propose revising the criterion on the fly
16:30:42 <pschindl> hughsie: I can
16:31:19 <pschindl> I'm for criterion revision
16:31:37 * kparal is OK with revising it
16:31:40 <roshi> +1 for revision
16:31:41 <tflink> yeah, change criteria so that graphical is moved to beta
16:31:41 <adamw> yeah, i'm obviously in favour. i know viking-ice is as well, i think he suggested it in the first place.
16:31:43 <mkrizek> +1 for revising the criterion
16:31:54 <tflink> +1 for revision
16:32:02 <tflink> what do we want to revise?
16:32:25 <tflink> IIRC, the old proposal was to have CLI @ alpha, and default graphical @ beta
16:32:32 <adamw> knock off teh second half of the criterion for alpha:
16:32:39 <adamw> "The installed system must be able to download and install updates with yum."
16:32:42 <tflink> I'm not sure that moving graphical to final would be wise
16:32:46 <adamw> actually, while we're at it, we could genericize the text:
16:32:56 <hughsie> pschindl, https://bugzilla.redhat.com/show_bug.cgi?id=1009132#c2
16:33:00 <adamw> "The installed system must be able to download and install updates with the default console package manager."
16:33:03 <adamw> (dnf!)
16:33:14 <adamw> then we stick the old wording in at Beta, yeah, not Final.
16:33:15 <tflink> would we be proposing the graphical criterion for final, then?
16:33:19 <adamw> i'd say beta.
16:33:23 <mkrizek> tflink: both are required in alpha now
16:33:29 <tflink> yeah, I meant beta
16:33:36 <tflink> mkrizek: yep, that's what we've been discussing
16:33:42 <adamw> but we can argue beta/final on the list, for purpose of this meeting we only have to agree on 'not alpha'
16:34:01 <tflink> yep
16:34:41 <tflink> proposed #agreed change the F20 alpha updates criterion to : "The installed system must be able to download and install updates with the default console package manager."
16:35:00 <kparal> ack
16:35:02 <roshi> ack
16:35:21 <tflink> who wants the action to propose the graphical criterion for beta?
16:36:07 <tflink> moar ack/nak/patch?
16:36:24 <mkrizek> ack
16:36:47 <pschindl> ack
16:37:26 <tflink> adamw: I assume you're OK with the proposal since I copied the text from you?
16:37:36 <adamw> ack
16:37:37 <adamw> sorry
16:37:44 <tflink> #agreed change the F20 alpha updates criterion to : "The installed system must be able to download and install updates with the default console package manager."
16:37:44 <adamw> i'll take the action
16:37:58 <tflink> #action adamw to propose new graphical updates criterion for f20 beta
16:38:25 <tflink> hughsie: thanks for the info and help
16:38:38 <tflink> back to the original issue - fe or not fe?
16:38:43 <hughsie> tflink, np
16:38:43 <kparal> +1 fe
16:38:48 <mkrizek> +1 fe
16:38:54 <pschindl> +1 fe
16:38:57 <tflink> -1 FE
16:39:11 <tflink> messing with updates mechanisms after freeze should only happen with blockers
16:39:23 <tflink> other votes?
16:39:25 <roshi> do we even have to mess with it now if it's been moved to beta?
16:39:34 <kparal> tflink: can it break it when it's broken already?
16:39:35 <tflink> as an fe, maybe
16:39:43 <tflink> kparal: depends on where the fix is
16:39:48 <adamw> +1 fe, seems a bit academic
16:39:50 <jreznik> sorry for being late - meeting clash :( reading logs
16:40:04 <adamw> tflink: i'd agree with -1 if it wasn't entirely broken at present
16:40:07 <kparal> if it doesn't work already, I don't see any harm in accepting a fix
16:40:18 <adamw> if the fix touched yum path in any way i'd be -1
16:40:45 <tflink> proposed #agreed 1009132 - AcceptedFreezeException - While graphical updates are not required for alpha, fixing it would be a good move. A tested fix would be considered past freeze.
16:40:55 <hughsie> adamw, i don't know what the backtrace looks like yet, ut i'm currently thinking it's a PK bug somewhere
16:41:05 <roshi> ack
16:41:05 <adamw> ack
16:41:09 <adamw> er
16:41:14 <adamw> did we agree on rejectedblocekr yet?
16:41:15 <tflink> adamw: or pk. if it was just gnome-software, I'd be less -1
16:41:17 <adamw> if not, patch for that
16:41:18 <pschindl> ack
16:41:24 <tflink> no, it wasn't proposed as blocker
16:41:34 <hughsie> tflink, well, i can certainly work around the problem in g-s, but i'd rather find the actual bug
16:41:37 <tflink> unless someone proposed it since the start of the meeting
16:41:56 <kparal> tflink: no, but I did add BetaBlocker tag
16:41:57 <roshi> I don't think there was a proposal for it
16:42:03 <tflink> hughsie: I suspect it'll be academic, though. RC4 should be the last alpha compose and that's already started
16:42:16 <kparal> tflink: you use the "s" word?
16:42:23 <tflink> yep
16:42:28 <kparal> ack
16:42:35 <tflink> .flog tflink for using 'the s word'
16:42:58 <tflink> adamw: do you think it needs RejectedBlocker?
16:43:00 <adamw> .fire tflink
16:43:00 <zodbot> adamw fires tflink
16:43:07 <adamw> tflink: oh, right, sorry
16:43:09 <adamw> my bad
16:43:25 <tflink> wow, it's been what ...  3 weeks since I was last fired?
16:43:36 <adamw> heh
16:43:39 <tflink> #agreed 1009132 - AcceptedFreezeException - While graphical updates are not required for alpha, fixing it would be a good move. A tested fix would be considered past freeze.
16:43:59 * Viking-Ice sneaks in late...
16:44:09 <tflink> ok, that is the last of the proposed FEs
16:44:13 <tflink> on my list, anyways
16:44:25 <tflink> moving on to the accepted blockers which aren't already VERIFIED
16:44:34 <tflink> of which there are a grand total of 1
16:44:42 <tflink> #topic (1008788) text install fails - reboots after completing all spokes and hitting 'c'
16:44:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008788
16:44:48 <tflink> #info Accepted Blocker, anaconda, MODIFIED
16:44:48 <tflink> not much to say here
16:44:56 <tflink> the fix is in a new anaconda build, which is done
16:45:04 <tflink> #info a fix is in a new anaconda build, which is done
16:45:15 <jreznik> and it should also fix ks one reported by pwhalen
16:45:16 <tflink> #info waiting on RC4 for final verification
16:45:19 <adamw> rc4 build is ongoing
16:45:24 <adamw> did we actually test the fix?
16:45:41 <tflink> not even sure what the fix was but it sounds so from the comments
16:46:01 <jreznik> pschindl tried the patch
16:46:16 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1008788#c6
16:46:27 <tflink> jreznik: if that's the fix that was pushed, yes
16:46:53 <tflink> but IIRC there were mutiple options for the fix and part of the holdup was deciding which route to take
16:47:08 <tflink> I think that's why sbueno wouldn't push the fix yesterday, anyways
16:47:11 <tflink> s/the/a
16:48:01 <roshi> https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/005998.html
16:48:05 <roshi> is the thread discussing it
16:48:10 <jreznik> but as far as I know, only one patch was sent for review
16:48:29 <jreznik> pschindl: which one have you tried? the one reviewed?
16:48:51 <jreznik> otherwise - if anybody else can try it quickly, it would be nice (the actual build)
16:49:40 <tflink> it sounds like that's the patch pschindl tried
16:49:44 <tflink> or close to it, anyways
16:50:11 <tflink> I can try a quick boot.iso build after the meeting
16:50:24 <tflink> so if it is busted, we figure it out before RC4 lands
16:50:40 <jreznik> would be great, thanks but I hope it's ok
16:50:40 <pschindl> sry. My NetworkManager seems to be broken right now and I can't get to the mail :( So I can't confirm which patch was pushed
16:51:21 <jreznik> pschindl: hub to spoke, 2. option was implemented
16:51:49 <tflink> bcl tested the fix
16:51:59 <tflink> assuming I'm reading this thread correctly
16:52:16 <jreznik> so if it was long patch, you tried the pushed one, if possible one-liner, than not :)
16:52:17 <pschindl> I think I tested the first option
16:54:02 <tflink> it sounds like building a boot.iso quick post-meeting would be prudent
16:55:33 <tflink> anything else on this bug?
16:55:44 <tflink> if not, it's time for
16:55:50 <tflink> #topic Open Floor
16:56:03 <tflink> anything else to bring up now?
16:56:19 <tflink> other than preparing for a potentially long night :)
16:56:35 <jreznik> i386 ami is covered, so nothing specific now and let's wish rc4 is working and final one ;)
16:57:37 <tflink> and no more 's word' - I've jinxed us enough for one day :-D
16:57:50 <tflink> if there's nothing else
16:58:00 * tflink sets fuse for (0,5] minutes
16:59:30 <tflink> #info if needed, the next blocker review meeting will be 2013-09-25 @ 16:00 UTC
16:59:39 <tflink> Thanks for coming, everyone!
16:59:45 * tflink will send out minutes shortly
16:59:48 <tflink> #endmeeting