f18-alpha-blocker-review-7
LOGS
16:07:13 <tflink> #startmeeting f18-alpha-blocker-review-7
16:07:13 <zodbot> Meeting started Wed Sep 12 16:07:13 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:13 <tflink> #meetingname f18-alpha-blocker-review-7
16:07:13 <zodbot> The meeting name has been set to 'f18-alpha-blocker-review-7'
16:07:13 <jreznik> adamw: morning!
16:07:17 <tflink> #topic roll call
16:07:29 * jreznik is here
16:07:35 <tflink> now that I've started the meeting in the right channel
16:07:36 <adamw> present!
16:08:00 <tflink> hrm, meetbot seems to be a bit slow today
16:08:15 * satellit still listening
16:08:16 * jreznik is also a little bit slow today :)
16:08:16 <tflink> let's try this again
16:08:22 * Martix is deplying ion-canon for killing few blocker bugs
16:08:23 <tflink> #topic Roll Call
16:09:26 <tflink> did I do something wrong w/ starting the meeting?
16:09:42 <adamw> the main reason meetbot is slow is that meetbot isn't *here*
16:09:46 <adamw> we should probably have checked that. =)
16:10:10 <jreznik> it's here
16:10:11 <tflink> but the meeting started and the logs are on meetbot.fp.o
16:10:11 <Martix> zodbot: is here
16:10:16 <adamw> oh, yeah, zodbot, i forgot
16:10:47 <adamw> oh
16:10:50 <adamw> i bet zodbot doesn't have privs to change the topic
16:11:11 <tflink> it looks like there haven't been many meetings in here
16:11:28 <tflink> the last one w/ logs was more than 2 years ago
16:11:33 <dan408> morning adamw
16:11:45 * nirik can fix that.
16:11:51 <adamw> go nirik
16:11:53 <adamw> morning dan
16:12:06 <dan408> adamw: you won i think
16:13:22 <jreznik> tflink: try it again now!
16:14:03 <tflink> #topic Roll Call
16:14:29 * jreznik is here, for the third time today :)
16:14:50 * Southern_Gentlem is always here
16:14:58 <Martix> .fas Martix
16:14:58 <zodbot> Martix: martix 'Martin Holec' <martix.cz@gmail.com>
16:14:58 <adamw> allelulia
16:15:15 <adamw> man, but this is a smooth professional operation, huh
16:15:58 <tflink> ok, now that we have that figured out, I think it's time for some always fun boilerplate
16:16:03 <tflink> #topic introduction
16:16:11 <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:16:18 <tflink> #info We'll be following the process outlined at:
16:16:18 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:16:37 <tflink> #info The bugs up for review today can be found at:
16:16:37 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:16:46 <tflink> #info The criteria for release blocking bugs can be found at:
16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:17:30 <tflink> any objections to starting with the proposed blockers?
16:17:50 <adamw> i propose we start with whiskey
16:19:38 <jreznik> it's dangerous to drink alcohol here now, 15 people died in a last few days after methylalcohol poisoning, some kind of prohibition is on...
16:19:38 <adamw> hey, sounds like everyone agrees!
16:19:57 <tflink> #info 12 Proposed Blockers
16:19:57 <tflink> #info 11 Accepted Blockers
16:19:57 <tflink> #info 9 Proposed NTH
16:19:57 <tflink> #info 8 Accepted NTH
16:20:19 <tflink> #topic (855289) Dri files are missing in lorax ( /usr/lib64/dri/foo-dri.so: cannot open shared object file: No such file or directory )
16:20:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855289
16:20:25 <tflink> #info Proposed Blocker, ON_QA
16:20:56 <jreznik> seems like it wasn't the right fix :(
16:21:04 <tflink> it sounds like there's still a bug here somewhere but the dri files weren't the problem
16:21:39 <tflink> I'd say punt on this
16:21:58 <jreznik> the question is how many systems are affected by this bug? and seems it's even not always reproducible on the same hw
16:22:19 <adamw> i'm not entirely sure how much bare metal testing we have, to be fair
16:22:27 <adamw> i'm okay with reject (for now) or punt
16:22:40 <tflink> not a whole lot of testing on bare metal, I suspect
16:22:41 <adamw> well, since we have go/no-go tomorrow, it'd be cleaner to reject, i guess
16:22:50 <jreznik> adamw: +1
16:23:40 <tflink> proposed #agreed 855289 - RejectedBlocker - Since there is no clear fix and there are few reports, rejecting as blocker for F18 alpha. If this turns out to be a bigger problem, please re-propose as a blocker.
16:24:14 <adamw> ack
16:24:27 <Martix> ack
16:24:37 <jreznik> ack
16:24:43 <tflink> #agreed 855289 - RejectedBlocker - Since there is no clear fix and there are few reports, rejecting as blocker for F18 alpha. If this turns out to be a bigger problem, please re-propose as a blocker.
16:24:50 <tflink> #topic (854471) anaconda stop at the "Error checking storage configuration"
16:24:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854471
16:24:51 <tflink> #info Proposed Blocker, NEW
16:25:22 <tflink> sounds like not a blocker to me
16:26:02 <adamw> oh, we got the storage.log for this now, didn't get time to look at it yet...
16:26:06 <jreznik> same for me, just the ui needs to be polished -> so it's for beta/final maybe?
16:26:24 <adamw> ah, -1, with bcl.
16:26:48 <jreznik> -1 blocker
16:27:39 <dlehman> doesn't look the anything really stops. he just didn't finish setting up storage.
16:27:47 <adamw> yeah
16:27:52 <adamw> i should've looked at the picture sooner
16:27:56 <tflink> proposed #agreed 854471 - RejectedBlocker - Since this is more of a UI confusion issue, it was deemed not to be a blocker for F18 alpha.
16:27:58 <adamw> somehow i was reading it as a crash, when it obviously isn't
16:27:59 <adamw> ack
16:28:09 <jreznik> ack
16:28:25 <Martix> ack
16:28:27 <tflink> #agreed 854471 - RejectedBlocker - Since this is more of a UI confusion issue, it was deemed not to be a blocker for F18 alpha.
16:28:29 <tflink> #topic (852792) [Configure] button in network spoke doesn't work (nm-c-e fails to run)
16:28:32 <jreznik> dlehman: it just need some ui polishing, it could be really very confusing... but it's not alpha
16:28:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852792
16:28:35 <tflink> #info Proposed Blocker, ASSIGNED
16:30:01 <tflink> this prevents any network configuration during install
16:30:21 <tflink> so netinstall w/ any wireless that requires a PW/key won't work
16:30:47 <jreznik> it's quite serious one... it wouldn't work even for wired without dhcp
16:30:49 <tflink> are networks with proxies affected as well or is that set in the repo config
16:31:01 <tflink> oh yeah, I wasn't thinking about static IPs
16:31:22 <adamw> also note that this hits the KDE live image too
16:31:44 <adamw> we fixed the other bug which broke it in the KDE live - the fact that nm-connection-editor wasn't included at all - but now the button still doesn't work in the KDE live because of *this* bug
16:31:45 <jreznik> adamw: it's not a big issue on live - there's network configuration in desktop
16:31:50 <adamw> it does work in the desktop and Xfce lives
16:31:51 <adamw> true
16:31:58 <tflink> proposed #agreed 852792 - AcceptedBlocker - Conditional violation of the following F18 release criterion for any network setup that requires configuration (wireless w/ key, static ip etc.) - "The installer must be able to use at least one of the HTTP or FTP remote package source options"
16:32:14 <adamw> well...
16:32:25 <jreznik> adamw: I was able to get it working by installing latest nmce and applet - then it worked on kde live
16:32:37 <tflink> I built a boot.iso with the new nm-applet but it still doesn't seem to be working
16:32:46 <tflink> jreznik: nmce?
16:32:51 <adamw> i'm not totally convinced we have to block on this at alpha
16:33:06 <adamw> for beta i'd definitely be +1...for alpha, it's more borderline
16:33:19 <Martix> adamw: I see it same way
16:33:27 <dan408> i know this is a meeting, sorry to interrupt, but unrelated question: why isn't fpaste in "base" or "standard"?
16:33:37 <adamw> dan408: ask notting in #fedora-devel
16:33:41 <adamw> he's looking after that stuff
16:33:51 <dan408> i did and he said it's not supposed to be
16:33:56 <jreznik> tflink: connection editor
16:33:57 <dan408> i'll follow up with him
16:34:19 <tflink> hrm, not sure I updated that for the test boot.iso
16:34:35 <adamw> it's part of network-manager-applet .
16:35:27 <tflink> yeah, it was included - I just checked my side repo
16:36:21 <Martix> " The installer must be able to complete an installation using all supported interfaces " is in Final release criteria
16:36:22 <adamw> so...what does everyone vote on this? i didn't see any votes.
16:36:34 <tflink> would we be OK with releasing alpha - knowing that it can't be netinstalled with most wireless or static IP setups?
16:36:39 <adamw> Martix: that's interfaces as in graphical, text, vnc etc
16:36:43 <adamw> not network adapters
16:36:46 <Martix> adamw: ok, I wasnt sure
16:36:47 <tflink> graphical netinstall, I mean
16:36:51 <zodbot> Ticket notification - f18betablocker: [Bug 856728] Fallback to text mode fails too. <https://bugzilla.redhat.com/show_bug.cgi?id=856728>
16:36:55 <tflink> does ks work or are there workaround?
16:37:01 <adamw> tflink: we released final for years that couldn't be netinstalled with wireless, so i'm disinclined to care about wireless at alpha
16:37:10 <jreznik_> adamw: is it part of nm-manager-applet? it's standalone package
16:37:13 <adamw> static IP is maybe a bigger thing, but still, alpha...
16:37:19 <adamw> jreznik: it comes from that .src.rpm .
16:37:25 <jreznik_> ah, k
16:37:28 <tflink> jreznik_: it's part of the same update
16:37:47 <tflink> adamw: and static IPs?
16:37:49 <jreznik_> well, I'll try it again
16:37:56 <adamw> tflink: see above, i am prevaricating
16:38:01 <jreznik_> it's definitely NTH
16:38:17 <adamw> jreznik: installing the package in the live environment may give different results from using an image into which it was built
16:38:25 <adamw> that may be part of the problem here
16:38:35 * jreznik_ understands
16:38:56 <adamw> tflink: i want other people to vote so i can carefully tailor my position to agree with the majority =)
16:39:13 <tflink> to me, it looks like there is some config/setup file missing from the boot.iso but I don't pretend to have a deep understanding of how everything fits together
16:39:44 <tflink> if it didn't work on lives, I would wonder if anaconda needed a rebuild
16:39:52 <tflink> against the new packages
16:40:02 <jreznik_> tflink: it worked for me on lives
16:40:31 <tflink> jreznik_: yeah, that's why I'm not suggesting the rebuild
16:41:21 <jreznik_> well, let's do this as NTH for now... /me still feels it more as blocker, but default config for installation is not to touch it, use wire + dhcp
16:41:38 <Martix> +1 NTH, -1 alphablocker
16:42:24 <tflink> yeah, that fits somewhat with what we've been doing with other installer issues - block alpha for issues in the default path
16:43:07 <Varikonniemi> why does f18 installer allocate 4g to swap even if ram is 2g ?
16:43:12 <tflink> and using the DVD is a workaround
16:43:39 <tflink> Varikonniemi: I believe that the general practice is to make swap == 2x memory
16:43:44 <jreznik_> ok, so +1 NTH, -1 blocker
16:43:52 <Varikonniemi> no its 1x
16:44:01 * dan408 is away: (Auto-Away after 10 mins) [BX-MsgLog On]
16:44:14 <jreznik_> Varikonniemi: pls, after blocker review...
16:44:23 <Varikonniemi> ?
16:44:43 <adamw> i have one guess at why this is happening
16:44:52 <adamw> the package has glib-compile-schemas in %post
16:45:02 <adamw> but it doesn't Requires(post) whatever package glib-compile-schemas is in
16:45:39 <jreznik_> adamw: but it should be fixed in latest build
16:45:49 <jreznik_> let me find it - that's why it worked for me on live
16:45:50 <adamw> jreznik_: no, they didn't fix that
16:45:53 <adamw> i'm looking at git master
16:45:58 <tflink> proposed #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does cause netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups
16:46:04 <tflink> adamw: lorax issue, maybe?
16:46:34 <adamw> jreznik_: the two recent commits a) run glib-compile-schemas and b) put the file in the package, but there's no Requires(post)
16:46:50 <tflink> if it works in live, you would think that there aren't issues with the package
16:46:52 <adamw> i could see that when the environment for the DVD is built, glib2 isn't a part of it
16:46:53 <jreznik_> ok
16:46:54 <Martix> ack
16:46:57 <adamw> tflink: no, this actually explains that
16:47:22 <adamw> it would make some sense that glib2 would happen to have been installed already when the nm-connection-editor package comes up, in the desktop and xfce spins, but not kde...
16:47:23 <jreznik_> so it's missing dep
16:47:33 <adamw> possibly. i'm not gonna bet my life on it, but it could be
16:47:48 * jreznik_ is not sure what was dragged into live
16:47:55 <adamw> it would also explain why re-installing the package after booting live fixed it for jreznik, if glib2 happened to have got installed by then
16:48:15 <tflink> what would have pulled it in?
16:48:20 <tflink> oh, nvm
16:48:40 <tflink> if it wasn't installed prior to %post running, breakage would ensue
16:48:56 <jreznik_> seems like it's the case
16:49:06 <tflink> ack/nak/patch?
16:49:25 <tflink> hrm, incomplete thoughts in the proposal
16:49:49 <tflink> proposed #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does prevent netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups
16:50:02 <Martix> ack
16:51:37 <adamw> ack
16:51:41 <jreznik> ack
16:51:49 <tflink> #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does prevent netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups
16:51:58 <tflink> #topic (855976) In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first
16:52:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855976
16:52:02 <adamw> i'm doing a scratch build with requires(post) added
16:52:03 <tflink> #info Proposed Blocker, NEW
16:53:29 <adamw> so...again this is alpha, but i'm pretty uncomfortable with blowing away entire disks with no indication that that's what's about to happen.
16:53:53 <Martix> and its pretty easyfix
16:54:06 <jreznik> Martix: but https://bugzilla.redhat.com/show_bug.cgi?id=855976#c9
16:54:38 <adamw> yeah, string freeze seems ridiculous at this point.
16:54:47 <adamw> i hardly think we're not going to need to change any more strings in the installer.
16:54:56 <Martix> adamw: +1
16:54:59 <adamw> and even an untranslated warning that your disk is about to be wiped seems better than *no* warning.
16:55:57 <tflink> very true
16:56:05 <Cerlyn> Is there a translated string from the previous installer that could be cherry picked?
16:56:07 <adamw> straw poll: did anyone actually understand that their disk was going to get wiped, the first time they ran an install with newui?
16:56:15 <adamw> Cerlyn: oh, good thinking. i think there may be.
16:56:30 <Martix> breaking feature freeze milestone is more worrying for me than breaking string freeze, but first one happens often
16:56:59 <msivak> Cerlyn: maybe, but we will be definitely changing more strings before alpha is out
16:57:23 <tflink> adamw: the first time that I installed, I was expecting the installer to eat babies and laugh while eating
16:57:29 * adamw pokes the jlk, who appears to have a dog in this fight
16:57:31 <adamw> tflink: heh.
16:57:44 * jlk clears throat and reviews bug
16:58:01 <tflink> but that was early pre-alpha, not a released alpha
16:58:07 <jlk> oh right, this one.
16:58:50 <jlk> that dialog is still under development and discussion.  I don't really see a point in slapping something else slightly less unfinished in there in a rush, just to change it again after the alpha.
16:58:50 <tflink> if we're going to have a link on fp.o, I'm not so comfortable with no warning
16:58:59 <jlk> put a warning next to the link.
16:59:07 <jlk> it's pre-release software for cripes sakes.
16:59:41 <tflink> sure, it's pre-release software but I think it's reasonable to expect that it isn't going to stomp on your whole disk without warning @ alpha
16:59:52 <jlk> as I stated in the bug, you can vote it NTH if you really want to, but causing a(nother) alpha slip for this is just silly.
17:00:17 <jlk> tflink: there are any number of bugs lurking that could stomp on your disk anyway, even if you requested something completely different
17:00:21 <jlk> it's new code.
17:00:32 <jlk> we haven't tested in all the variety of configurations people are going to throw at it.
17:01:14 <tflink> true, there are probably still bugs in there but that doesn't mean that we shouldn't warn people when we _know_ that their disk is going to be wiped
17:01:41 <adamw> 'we shouldn't warn about the case where we know you're about to lose all your data because there's a high chance we'll screw up and wipe it all anyway'...can anyone tell they're in a fedora channel? :P
17:01:45 <jlk> and the final dialog may state that
17:02:17 <jlk> or the final product may actually default to using free space instead of all space.
17:02:30 <jlk> my point here is that if this was the only bug left, it's laughable that this would cause a slip in the release.
17:02:51 <adamw> i think laughable is putting it way too strongly.
17:03:18 <adamw> i could probably be argued out of it, but you're kind of hurting your own case by implying that anyone on the other side is being dumb.
17:03:49 <zodbot> Ticket notification - f18alphanicetohave: [Bug 852792] [Configure] button in network spoke doesn't work (nm-c-e fails to run) <https://bugzilla.redhat.com/show_bug.cgi?id=852792>
17:03:51 <adamw> if we fall back on process...this doesn't hit any of the criteria either current or proposed, that i can see
17:04:26 <adamw> do we want to do a show of hands to see where people stand on this one?
17:04:28 <jlk> adamw: I apologize.  I'm trying to laugh so that I don't get overly angry :)
17:04:31 <adamw> heh
17:05:10 <msivak> jlk: how hard would it be for us to display "data loss" line next to the storage spoke on the summary hub?
17:05:46 <jlk> msivak: difficulty is not the question
17:06:07 <jlk> the question is does the lack of such a line create a reason to delay the alpha release.
17:06:22 <adamw> that is indeed the question
17:06:36 <adamw> we usually don't and shouldn't decide blocker status based on how easy the fix is
17:06:40 <jreznik_> jlk: how much time do you expect it will take?
17:06:58 <adamw> i don't think that's relevant (see above)
17:07:02 <jlk> jreznik_: it could take all the time in the world, if we make more serious bugs the priority.
17:07:05 <adamw> jlk is correct that it shouldn't be a factor
17:07:24 <jreznik> ok, ok :)
17:07:35 <adamw> the other old standby we have is this:
17:07:59 <adamw> if this were the last bug in the world in f18 alpha right now, and it was the go/no-go meeting, would you want us to hold the release for it?
17:08:49 <tflink> not sure if I'm at 'yes, absolutely', but I'm definately not 'no'
17:09:06 <dlehman> if it's clearly marked that continue on the configuration hub means "now make it so" is the argument that people don't know what we've done to configure storage but they have somehow assured themselves all the same the we didn't remove any partitions to make space?
17:09:40 <dlehman> I know it's not about people who pay attention.
17:09:48 <Martix> but today is not nogo mtg, warning can be added and images can be respined overnight, right?
17:09:59 <Martix> if we push harder
17:10:17 <adamw> Martix: yes, but we shouldn't decide on that basis
17:10:26 <adamw> it's wrong to take a bug as a blocker just because we think we can fix it, if you see what i mean
17:10:31 <tflink> Martix: that isn't the point of adam's question - we use it as one test when trying to decide whether or not to take a borderline bug as a blocker
17:10:41 <adamw> if we take a bug as a blocker it should always mean that the answer to that hypothetical question is 'yes'
17:11:11 <adamw> dlehman: the way i see it is this: it's a very strong convention in software than when you (an app) are about to deliberately delete data, if the user hasn't explicitly requested that precise operation, you warn the user
17:11:16 <Martix> I'm for +1 alphablocker regardless of time needed for fixing this
17:11:20 <adamw> people are aware of this convention, consciously or unconsciously
17:11:43 <adamw> so when they go through a process that doesn't tell them they're about to lose all they're data, their expectation is that they're not about to lose all their data
17:12:03 <Martix> that was only pragmatic approach, its doable without slipping alpha, again :-/
17:12:06 <dlehman> perhaps we should have such a warning when leaving the configuration hub since installing packages could potentially also be destructive
17:12:13 <adamw> i expect that if you put 100 people down in front of the current newUI and asked them what was about to happen when they picked a disk and pressed 'continue', probably 0 of them would say 'well, that whole disk is about to get wiped'
17:12:32 <jreznik> adamw: yep
17:12:36 <adamw> that's just my reading, though
17:12:41 <dlehman> but what would they say?
17:12:49 <jlk> guys, not the point.
17:13:09 <jlk> I think we agree (to some extent) that a bug exists here, in that the user isn't properly notified of what's about to happen
17:13:12 <jlk> that's fine.
17:13:28 <jlk> I don't think we're debating that here
17:13:39 <adamw> well, dlehman asked about it.
17:13:47 <jlk> what we're debating is whether that problem is extreme enough to cause a slip.
17:13:52 <Martix> another question, do we want to angry more users or less?
17:14:11 <jreznik> Martix: it's Alpha... so...
17:14:11 <dlehman> yeah, it's not working as designed now
17:14:29 <jlk> Martix: users of an alpha release of Fedora, who've clicked through a pop up that warns them they are using alpha release software, which may eat their data, and that they have to accept their fate....
17:14:49 <adamw> so we have a strong +1 blocker from martix, a wishy-washy +1 from me, strong -1 from jlk, i'm assuming a -1 from dlehman, any other votes?
17:15:02 * dlehman just gets tired of this whole "but I was just installing an operating system -- who knew something serious could happen to my computer?" mentality we seem to cater to.
17:15:04 <tflink> jlk: since when does everyone actually read and heed warnings like that
17:15:04 <jlk> you literally cannot go through the install without clicking through a warning about how this pre-release software may eat your data.
17:15:07 <jreznik> also any other bug in alpha could wipe the data also... it should not happen in final, but in alpha
17:15:19 <adamw> jlk: the thing is, we've had that warning forever. it's a generic warning that there may be bugs. no-one's going to interpret it as 'there is code here which intentionally wipes out entire disks without any notification'.
17:15:20 <Martix> jlk: ok, but we should try to avoid catastrophic scenarios if we can
17:15:20 * nirik is a weak -1 blocker.
17:15:30 <spoore> I'd vote NTH for alpha, blocker for beta....I assumed that the whole disk was going to be wiped
17:15:33 <msivak> intentional data loss without warning is bad, but they did accepted their fate..
17:15:35 <jlk> tflink: you realize that your statement really doesn't help the argument for delaying the release for another warning dialog.
17:15:41 * jreznik is also weak -1 blocker for alpha
17:16:22 <msivak> do we have release notes and known bugs for alpha where we can document it?
17:16:24 <jlk> adamw: we may have had that warning forever, but it was in a different UI with different words and different button options
17:16:29 <jlk> adamw: it's not the same warning anymore.
17:16:36 <nirik> I'd also perhaps note it in the announcement and release notes too... "Note that this will format whatever disks you give it by default... "
17:16:38 <nanonyme> can we tag it *now* as beta blocker, btw?
17:16:40 <Viking-Ice> I assume that those that have voted on the bugs themselves are being counted as well
17:16:46 <adamw> msivak: yes, we have alpha release notes
17:16:47 <jlk> msivak: yes, we typically have release notes or known bugs. list.
17:16:53 <adamw> Viking-Ice: oop, no, i didn't count those votes, sorry
17:17:01 <nanonyme> (and remove it if it gets fixed)
17:17:07 <adamw> so we add a +1 from kamil
17:17:19 <jlk> nanonyme: yes, it can be proposed as a beta blocker now.
17:17:29 <adamw> if we reject it, i'll propose it for beta.
17:17:44 <tflink> jlk: so being pretty sure that people aren't likely to read the warnings in the way that we think we they should isn't a reason not to go that route?
17:17:51 * tflink is +1 blocker
17:18:25 <tflink> is it reasonable to expect that you can install alpha without risking your system? not so sure
17:18:37 <jlk> tflink: I'm saying that we already have a pretty dire warning that users /must/ click through.  You're telling me people don't read warnings.  Then you're telling me we must put a warning in.
17:18:41 <jlk> I'm failing to follow your logic.
17:18:45 <jreznik> tflink: alpha is always risk...
17:18:53 <msivak> tflink: alpha? not really and never was
17:18:59 <nanonyme> adamw, I'm fine with -1 if you go for beta blocker vote right after so I can vote +1 for it ;)
17:19:05 <dlehman> jlk makes a good point
17:19:07 <adamw> jlk: a specific message about a specific operation, directly tied to that operation, is more likely to be understood.
17:19:18 <jreznik> there could be any other bug that could lead to data loss - it's actually expected
17:19:21 <jlk> if you're trying to set an expectation that alpha software is without risk, you're going to have a hard battle.
17:19:40 <dlehman> for beta the behavior will be different clicking through that particular dialog will not automatically clear your disks
17:20:00 <Martix> jreznik: another bug could affect only part of users, unlike this one
17:20:06 <adamw> what i was envisaging was that the message that pops up saying 'You have enough space to continue!' should say instead 'We're going to destroy all the data on this disk. You have enough space to continue!'. more or less.
17:20:42 <adamw> jlk: no, that's not the expectation. just about everyone who's voted +1 has drawn a clear distinction between potential bugs and intentional destructive actions.
17:21:11 <adamw> well, good news everyone, the voting is exactly tied. :P
17:21:13 <adamw> +4 / -4
17:21:30 <adamw> note that all the +s are qa, and all the -s are not-qa...
17:21:35 <tflink> I'd be crazy to set the expectation that there is no risk in installing alpha regardless of what the popular understanding of alpha/beta is
17:21:40 <adamw> oh, except nanonyme, sorry nano.
17:22:27 <robatino> i'm +1
17:22:47 * adamw finds a tossing quarter
17:23:02 <Viking-Ice> on what are we voting upon now
17:23:13 <adamw> Viking-Ice: 855976 , blocker yay or nay
17:23:25 * jreznik is ok with blocker if QA thinks it's that serious...
17:23:40 <adamw> for those voting +1, what's your rationale wrt https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria ?
17:23:59 <Viking-Ice> thats not a blocker
17:24:02 <msivak> jreznik: and if better message solves that for alpha I suppose :)
17:24:06 <Viking-Ice> it's to be expected
17:24:10 <adamw> do you think it hits one of the criteria? or should it be accepted under the other basis in 'Alpha Blocker Bugs'? or should we create a new criterion?
17:24:17 <adamw> so, +5 / -5. this gets better. :P
17:24:36 <adamw> i suppose we can say with that many -, we certainly don't have a clear consensus that this is a blocker
17:24:46 <Viking-Ice> the logic ( as has been stated ) is simple if you care about your data dont install alpha
17:24:53 * jreznik is not sure where the message should go, as the ui is really not what I'd expect even for alpha
17:25:08 <adamw> i don't recall that we've ever really had a situation like this before, so we've never established whether the presumption is blocker or not-blocker, but i suppose the only sensible way is that the presumption is not-blocker
17:25:12 <Cerlyn> I don't see any notification requirements in the criteria
17:25:15 <adamw> so a very close vote should make it not-blocker
17:25:24 <spoore> adamw, did you count my vote as -1 blocker?   (with the intention also of voting +1 blocker for beta)
17:25:54 <adamw> spoore: oop, missed yours, so +5 / -6
17:26:29 <Viking-Ice> add a note to the release criteria and make it an beta blocker and or a final
17:26:48 <msivak> I agree with Viking
17:27:02 <adamw> that's +5 / -7
17:27:03 <Viking-Ice> there already is a big fat warning when the installer loads that it will eat your babies
17:27:05 <adamw> it's looked kinda rejectedblocker
17:27:13 <adamw> s/looked/looking/
17:27:21 <jwb> they've already said the behavior is going to change post-alpha, right?
17:27:28 <adamw> yes
17:27:34 <jwb> then -1 from me, if it counts
17:27:54 <tflink> yeah, with the criteria written as is, we don't have much to stand on criteria-wise without being hypocritical
17:27:58 <adamw> jwb: it counts for something
17:28:21 <tflink> +5/-8? looks like the rejected votes have it
17:28:26 <adamw> this is probably the closest/most debated vote we've had, so whatever we decide, i'll tabulate the votes in the bug comment
17:28:26 <jreznik> also if you care about data and you don't see reasonable info how the disk is going to be change, you click quick :) that's what I'd do
17:28:57 <adamw> tflink: do a proposal, we've been on this long enough..
17:30:12 * kparal looks around
17:30:21 <zodbot> Ticket notification - f18alphablocker: [Bug 855644] F18 Live (alpha RC2) Anaconda custom partition layout: no access to existing LVM/LUKS volumes <https://bugzilla.redhat.com/show_bug.cgi?id=855644>
17:30:27 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided not to accept this bug as a blocker for F18 alpha. Please re-propose for beta.
17:30:40 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta.
17:31:37 <tflink> ack/nak/patch?
17:31:48 <nirik> ack
17:31:58 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided (+5 blocker, -8 rejected) not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta.
17:32:13 <tflink> hrm, does it even make sense to put the votes in there?
17:32:36 <nirik> not really. stick them in the bug?
17:32:38 <adamw> ack to the second one
17:32:42 <adamw> yeah, i'm writing them into the bug
17:32:52 <nirik> and then later when lots of people yell, we can see who to blame. ;)
17:33:22 <jlk> Anaconda team takes full responsibility, since we'll get the blame anyway :)
17:34:29 <tflink> OK, I need more acks before finishing the vote
17:34:36 <spoore> ack
17:34:42 <Martix> nack
17:34:44 <jlk> ack
17:34:46 <tflink> Martix: patch?
17:34:50 <Viking-Ice> ack
17:35:19 <adamw> Martix: ack doesn't mean you vote -1 blocker, just that you accept the result of the vote and the text picked by tflink
17:35:32 <Martix> adamw: I know :-)
17:35:34 <jreznik> ack to stay behind my decision
17:35:48 <tflink> Martix: what's wrong with the text, then?
17:35:56 <adamw> jlk: oh, i wrote out the vote to be sure the right people get the blame ;)
17:36:10 <zodbot> Ticket notification - f18betablocker: [Bug 855976] In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first <https://bugzilla.redhat.com/show_bug.cgi?id=855976>
17:36:30 <tflink> Martix: are you writing a patch or not?
17:36:42 <Martix> tflink: pulling git
17:36:47 <adamw> er, eh?
17:36:50 <jlk> Martix: the vote is complete, you're just acking the summary of the vote.
17:36:51 <adamw> a patch for tflink's #agreed text
17:36:54 <adamw> not a patch for anaconda
17:37:02 <Martix> adamw: ok
17:37:09 <kparal> :)
17:37:13 <jlk> Martix: you don't get to vote on ignoring the vote...
17:37:23 <Martix> tflink: you know sed s/RejectedBlocker/AcceptedBlocker/"
17:37:36 <zodbot> Ticket notification - f18alphanicetohave: [Bug 855976] In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first <https://bugzilla.redhat.com/show_bug.cgi?id=855976>
17:37:52 <tflink> Martix: thanks for helping the process, much appreciated
17:37:54 <robatino> ack
17:38:00 <tflink> #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided (+5 blocker, -8 rejected) not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta.
17:38:05 <Martix> but its late, we have completed vote
17:39:01 <tflink> Martix: and you're making a long meeting longer for no good reason. I don't agree with the conclusion, either but that doesn't mean that I can ignore the results
17:39:11 <tflink> anyhow, moving on
17:39:23 <tflink> #topic (855644) F18 KDE Live (alpha TC5) Anaconda custom partition setup: no access to existing LVM/LUKS volumes
17:39:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855644
17:39:28 <Martix> tflink: ok, I misunderstand vote :-)
17:39:29 <tflink> #info Proposed Blocker, NEW
17:40:00 <adamw> having looked at this one again, i'm definitely -1
17:40:09 <adamw> it doesn't even hit the *existing* criterion, never mind the proposed revised one
17:40:23 <adamw> the existing criterion is about *creating* encrypted/luks partitions, not re-using existing ones
17:40:46 <msivak> that is definitely not an alpha blocker
17:40:48 <adamw> it obviously doesn't hit any of the proposals for revising the criterion that have been submitted so far, afaict.
17:40:58 <Viking-Ice> -1 blocker
17:41:16 <nirik> -1 blocker, possibly final ?
17:41:25 <jlk> -1 blocker, intent of existing criteria was that the available autopartitioning choices work, which in this case, do.
17:41:27 <adamw> yeah, final would likely be the place it winds up.
17:41:28 <Martix> I use LUKS, but -1 alphablocker, +1 betablocker?
17:41:51 <tflink> I thought that we covered this, though - pretty much anything non-default wasn't going to be alpha blocker?
17:41:57 <tflink> or am I mis-remembering?
17:42:06 <tflink> either way, it sounds like we're pretty solidly -1 blocker
17:42:18 <jreznik> tflink: it fits "the default"
17:42:22 <jreznik> -1 blocker
17:42:34 <adamw> tflink: i don't think we have a complete consensus on the revised criterion yet, but like i said, this doesn't hit the current criteria or *any* proposal for the revised criterion, so it's pretty solidly -1 :)
17:43:33 <tflink> proposed #agreed 855644 - RejectedBlocker - This doesn't violate any of the release criteria for F18 alpha, therefore it is rejected as a blocker for F18 alpha
17:43:37 <adamw> ack
17:43:42 <Viking-Ice> ack
17:43:48 <nirik> ack
17:43:52 <tflink> #agreed 855644 - RejectedBlocker - This doesn't violate any of the release criteria for F18 alpha, therefore it is rejected as a blocker for F18 alpha
17:44:06 <tflink> #topic (855646) F18 KDE Live (alpha TC5) Anaconda custom partition setup: missing volume/device identification
17:44:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855646
17:44:12 <tflink> #info Proposed Blocker, NEW
17:45:00 <jlk> -1 blocker
17:45:48 <msivak> yep, same thing as the last one, custom partitioning..
17:46:00 <Martix> -1 blocker
17:46:05 <adamw> yup, -1.
17:46:09 <Viking-Ice> -1 blocker
17:46:12 <jreznik> -1
17:46:53 <nirik> -1 here
17:47:29 <tflink> proposed #agreed 855646 - RejectedBlocker - While this does come close to hitting the F18 alpha release criteria as written, it doesn't apply well to the new anaconda UI and more closely hits custom partitioning which is not an alpha blocking issue
17:47:52 <Martix> ack
17:47:53 <spoore> ack
17:47:55 <Viking-Ice> ack
17:48:04 <nirik> ack
17:48:10 <adamw> ack
17:48:14 <tflink> #agreed 855646 - RejectedBlocker - While this does come close to hitting the F18 alpha release criteria as written, it doesn't apply well to the new anaconda UI and more closely hits custom partitioning which is not an alpha blocking issue
17:48:23 <tflink> #topic (856096) repoclosure failure on 18 Alpha RC2 DVDs (mongodb)
17:48:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856096
17:48:23 <tflink> #info Proposed Blocker, ON_QA
17:48:39 <tflink> sounds like a clear blocker to me
17:48:45 <adamw> obvious +1 blocker per the criteria, happily should be an easy fix
17:48:52 <jreznik> +1
17:48:53 <Viking-Ice> +1 blocker
17:49:00 <tflink> proposed #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: "
17:49:12 <jreznik> nice criterion :)
17:49:27 <tflink> proposed #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
17:49:37 <jreznik> ack
17:49:38 <spoore> ack
17:49:39 <Viking-Ice> ack
17:49:42 <nirik> acl
17:49:44 <tflink> #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
17:49:44 <nirik> ack even
17:49:55 <tflink> #topic (852841) Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet)
17:49:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852841
17:50:01 <tflink> #info Proposed Blocker, NEW
17:50:36 <adamw> this is really annoying, but probably not quite an alpha blocker
17:50:40 <Viking-Ice> -1 blocker
17:50:41 <nirik> -1 blocker, +1 nth
17:51:03 <jreznik> ajax is looking on this
17:51:03 <adamw> i think the closest chance it has to qualify is not the criteria but the "Bug hinders execution of required Alpha test plans or dramatically reduces test coverage" clause
17:51:09 <Martix> its annoying, but -1 blocker, +1 NTH
17:51:10 <adamw> but since so little of the alpha testing is desktop stuff, probably not
17:51:15 <adamw> i might be +1 for beta on that basis, though
17:51:29 <jreznik> it's beta one definitely
17:51:30 <adamw> -1/+1
17:51:46 <tflink> yeah, if we're going to see testing on this for alpha, I don't think that much of it is going to be live-only
17:53:11 <jlk> do we really have alpha criteria that you should be able to install every package from the DVD?
17:53:11 <tflink> proposed #agreed 852841 - RejectedBlocker AcceptedNTH - While annoying, this does not clearly violate any of the F18 alpha release criteria and is therefore rejected as a blocker, accepted as NTH
17:53:24 <jlk> (sorry, got a bit behind)
17:53:59 <jreznik> ack
17:53:59 <tflink> jlk: yeah, "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
17:54:06 <Martix> ack
17:54:07 <spoore> ack
17:54:14 <tflink> #agreed 852841 - RejectedBlocker AcceptedNTH - While annoying, this does not clearly violate any of the F18 alpha release criteria and is therefore rejected as a blocker, accepted as NTH
17:54:20 <jlk> huh, that seems overreaching for alpha.
17:54:25 <adamw> ack
17:54:30 <tflink> #topic (856194) firstboot has to insist the first user is admin when root account is locked
17:54:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856194
17:54:36 <tflink> #info Proposed Blocker, NEW
17:54:56 <adamw> jlk: we've read it as 'there shouldn't be any conflicting packages on the dvd' for a long time, but i'm not sure that's how we actually _meant_ it when we started
17:55:07 <adamw> jlk: but eh, in practice it's never caused a slip, it's usually easy enough to sort out dep issues
17:55:25 <tflink> or remove a package from the DVD if needed
17:55:27 <jlk> sure, but that dodges the age old question.  Would we slip the release for this :)
17:55:28 <adamw> oh goody, another controversial one
17:55:29 <Viking-Ice> lol that's a good one
17:55:41 <Viking-Ice> +1 blocker
17:55:52 <jlk> -1 blocker.
17:55:56 <msivak> text mode requires root password :)
17:55:57 <jlk> it's an easy releasenote thing
17:55:59 <adamw> basically, it's pretty stupid that if you install straight-through defaults, you get a system you can't really use.
17:56:04 <msivak> and gui says root is disabled
17:56:23 <jlk> adamw: stupid yes, blocker worthy, no.
17:56:29 <adamw> i'd see flipping the default of the checkbox in firstboot as a sufficient fix for alpha
17:56:36 <adamw> and that really is bloody easy. i was kinda hoping it'd be done yesterday.
17:56:39 <tflink> -1 blocker, +1 nth - you can workaround this through recovery mode
17:57:04 * kparal agrees with adamw
17:57:05 <Martix> -1 alphablocker, +1 nth, +1 betablocker
17:57:05 <nirik> -1 blocker, +1 nth - another one for release notes.
17:57:19 <msivak> adamw: I was playing with passwords in anaconda.. sorry :)
17:57:50 <msivak> adamw: because I intended to solve the default in anaconda
17:57:52 <Viking-Ice> persuaded since alpha reporters really should know how to rescue their system -1 blocker +1 nth
17:57:57 <jreznik> I'm actually +1 blocker as the default path is broken...
17:58:10 <tflink> proposed #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - This doesn't clearly violate any of the F18 alpha release criteria and can be fixed/worked around with rescue mode
17:58:11 <jreznik> but if someone is running alpha, should be able to fix it :)
17:58:24 <Viking-Ice> ack
17:58:44 <spoore> -1 blocker / +1 nth
17:58:45 <Martix> its poweruser fixable instead of data loss :-)
17:58:54 <Martix> ack
17:58:54 <adamw> i'm okay with -1/+1
17:59:00 <adamw> but i'd really like it if we could fix this for rc3
17:59:03 <adamw> it's such an easy damn fix
17:59:11 * adamw hints to msivak :P
17:59:41 <Martix> adamw: +1
17:59:43 <jreznik> adamw: you should not use "it's simple" here :)
17:59:45 <msivak> adamw: yeah well.. I have it on my list and will do it tommorow :)
17:59:58 <adamw> tflink: well, it's a conditional breakage of all sorts of criteria. like installing updates. we're just agreeing the condition isn't severe enough to accept it.
18:00:03 <adamw> so, patch...lemme see
18:00:09 <adamw> msivak: tomorrow's too late
18:00:15 <adamw> rc3 needs to be spun, er, right after the meeting
18:00:21 <adamw> jreznik: i meant that in relation to nth
18:00:40 <adamw> i guess i'll have to roll up my sleeves and figure out how to change the default state of a checkbox, then =)
18:00:54 <jreznik> adamw: but same could aply to the wipe data one
18:00:56 <msivak> adamw: then it is not going to be there.. I am loosing the DNS in 30 secons.. office migration
18:01:18 <jreznik> msivak: DNS is not a problem if you have IP address :)
18:01:30 <adamw> proposed #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - this is a conditional breakage of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the case the user accepts the defaults during install, but we agreed Alpha users should be capable of recovering or reading instructions to create a root password or an admin user
18:01:36 <Martix> msivak: ?
18:01:43 <jreznik> msivak: you can use for example google one
18:01:50 <tflink> #chair adamw
18:01:50 <zodbot> Current chairs: adamw tflink
18:01:53 <jreznik> ack
18:01:58 <Viking-Ice> ack
18:01:58 <tflink> ack
18:01:59 <adamw> tflink: i don't need to be chair to propose it :)
18:02:01 <msivak> also dhcp and all other network services
18:02:10 <tflink> no, but I'm not reformatting that to #agree it
18:02:14 <Martix> msivak: damn
18:02:16 <tflink> :)
18:02:26 <adamw> tflink: heh
18:02:27 <jreznik> msivak: yep, but you have IP address right now...
18:02:30 <adamw> #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - this is a conditional breakage of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the case the user accepts the defaults during install, but we agreed Alpha users should be capable of recovering or reading instructions to create a root password or an admin user
18:02:32 <Martix> pause mtg, /me is biking home :-D
18:02:41 <tflink> #topic (856225) PackageKit can't import Fedora GPG key
18:02:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856225
18:02:42 <tflink> #info Proposed Blocker, NEW
18:02:51 <msivak> I am moving home and I might try from there, but no promises
18:03:10 <Martix> msivak: its announced: 21:00 (Region's local time)
18:03:14 <adamw> this is clear +1 per current criteria, though worth noting viking-ice and I were discussing whether it _really_ makes sense to require graphical updating at alpha
18:03:41 <Martix> oh thats something else, nevermind
18:03:41 <adamw> has anyone seen hughsie, anyway?
18:03:49 <jreznik> for current criteria - it's +1
18:03:56 <jreznik> adamw: I talked to him, he's working on it
18:03:59 <adamw> cool
18:04:07 <adamw> that output you gave looks pretty useful
18:04:26 <adamw> looks like more yum 'api' breakage...
18:04:27 <jreznik> adamw: but I don't have current status from him :(
18:05:04 <jreznik> adamw: yum guy (zpavlas) told me it's probably rpm issue... but then it's strange why it hits only pkgkit and not yum
18:05:10 <tflink> proposed #agreed 856225 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
18:05:14 <adamw> anyone interested in amending the criteria to reject this, or are we happy with it?
18:05:30 <jreznik> this comes from yum: Key import failed (code 2)
18:05:50 <tflink> I could go either way
18:05:56 <adamw> to elaborate on the criterion thing
18:06:09 <jreznik> adamw: if we are happy with it, it means slip... there's workaround by using yum to import key and then you have working graphical ui
18:06:09 * nirik is +1 blocker. I don't think we should change critera in the middle, because it's not a clear case where something changed
18:06:26 <nirik> no fix on the horizon?
18:06:31 <adamw> the basis for requiring graphical update to work is a bit thin, really...as i recall it, the idea is that we're supposed to be building an OS that's usable completely graphically, and so if we require update to be working at alpha, we must require graphical update as well as yum
18:07:04 <adamw> i'm not really sure anyone expects to be able to use a fedora alpha without ever touching a console
18:07:12 <jreznik> nirik: hughsie promised to inform me but he's not online right now :(
18:07:14 * nirik recalls seeing 'can't import keys' from pk about once a cycle at least. ;(
18:07:37 <adamw> and if we're happy with an alpha that blows away hard disks at the drop of a hat and defaults to installing without any access to root account at all, it seems a bit inconsistent to block on a graphical package manager...
18:07:38 <Viking-Ice> we can move that discussion to later time ( the either/or ) and proceed with the meeting
18:07:51 <tflink> yeah, I'd be OK with requiring just CLI for alpha
18:07:54 <nirik> adamw: true...
18:07:57 <adamw> Viking-Ice: well, if we move it to a later time, we accept this as a blocker. i'm okay with that if it's what we want to do.
18:08:07 <nirik> this doesn't affect live installs? only dvd/net?
18:08:11 <jlk> guys
18:08:13 <jreznik> nirik: only dvd
18:08:14 <tflink> if we're going with one, it should be yum/pk cli - whichever is in minimal
18:08:21 <jlk> please don't make Anaconda import this thing again like last time.
18:08:25 <adamw> tflink: our idea was to make it either/or.
18:08:37 <tflink> adamw: what about minimal installs w/ non-working CLI
18:08:39 <adamw> jlk: you know, i'm sure we have some kind of bug report for that. <ducks>
18:08:59 <adamw> tflink: hum, true. if we go with one, i guess it should be yum.
18:09:00 * nirik feels less +1 now...
18:09:15 <adamw> jlk: but no, that's not the plan here, the plan is 'fix PK'.
18:09:20 <jreznik> has to be yum, as console pkkit does not work either
18:09:31 <jlk> that was the plan last time, and yet anaconda had to import the goddamn thing, because PK couldn't be arsed to fix it in time
18:10:47 <adamw> i guess i'm pretty unhappy with the inconsistency between 'oh, the root password bug is rejectedblocker, alpha users should be able to use rescue mode' and 'this is a blocker because we can't expect people to use a console'
18:10:48 * tflink never saw any acks or naks
18:11:07 <jlk> I'm -1 blocker too
18:11:13 <jlk> easy work around with yum from the console
18:11:40 <Martix> -1 blocker, +1 NTH
18:11:54 <tflink> +1 blocker w/ criteria written as is
18:12:03 <Viking-Ice> I was forced to be +1 per criteria
18:12:08 <jreznik> adamw: yep, we are inconsistent... :( /me can feel everyone is pushing on "make the release possible now"...
18:12:16 <adamw> for those voting -1, can you say whether you are also voting to revise the criterion, or that you want to keep the criterion but consider using yum to import the key a sufficient workaround?
18:12:46 <tflink> that's an interesting way to put it
18:12:58 <adamw> jreznik: it's a bit different for me - it's more that i'm re-evaluating the criteria in the light of viking's thought that we just require too much for an alpha
18:12:59 <jlk> I'm voting on -1 to blocker for this particular bug, leaving criteria changes to a later discussion
18:13:01 <Martix> +1 for workaround, it could be in release notes and its nondestructive bug
18:13:03 <adamw> i think he's correct on that to an extent
18:13:13 <adamw> thinking about it again, i'm not happy with the original rationale for this criterion
18:14:10 <nirik> the main reason to avoid changing critera in process is that it moves the bar for developers. They don't know what they have to make sure works. In this case though it's relaxing that critera, not making it more strict...
18:14:12 <adamw> we should stand firmly by the criteria where they make _sense_, but...
18:14:16 <tflink> I'd be OK with saying that it is a conditional violation (only fails the first time) - using yum as a workaround
18:14:16 <jreznik> adamw: we req. too much for alpha, but the benefit is - it could help beta/final...
18:14:33 <adamw> tflink: i can go with that, and we can talk about modifying the criterion on the ml
18:14:40 <jreznik> also this time it was hard for desktop developers to even try it
18:15:05 <jreznik> we have not covered desktop in alpha yet...
18:15:09 <adamw> tflink: run a proposed up the flagpole and we'll see who salutes =)
18:15:28 <adamw> jreznik: the desktop tests for alpha are pretty minimal, in practice i think we've actually pretty much covered them
18:15:42 <adamw> obviously we've tested updates as we have this bug, and i know i've launched a browser and a terminal =)
18:15:43 <nirik> tflink: I'm ok with that too.
18:16:09 <jreznik> adamw: as I said - it was hard to actually do anything on top of alpha as we were strugling three weeks to get a system that could boot to gui
18:16:18 <tflink> proposed #agreed 856225 - RejectedBlocker AcceptedNTH - While this is a conditional violation of the following F18 alpha release criteria for the first update attempt: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", it was decided that using yum from the CLI for the first update is an acceptable workaround
18:16:25 <adamw> ack
18:16:28 <nirik> ack
18:16:39 <spoore> ack
18:16:41 <tflink> #agreed 856225 - RejectedBlocker AcceptedNTH - While this is a conditional violation of the following F18 alpha release criteria for the first update attempt: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", it was decided that using yum from the CLI for the first update is an acceptable workaround
18:16:43 <jlk> ack ack ack-ack </mars-attacks>
18:16:52 <tflink> #topic (856256) Crash when unlocking screensaver
18:16:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856256
18:16:52 <tflink> #info Proposed Blocker, NEW
18:16:53 <Martix> ack
18:18:00 <tflink> not so sure this is an alpha blocker
18:18:37 <jreznik> -1 blocker, I saw it with cirrus too and sometimes it freezes during login (ui works, just no possibility to login)
18:18:52 <tflink> -1 blocker, +1 nth
18:18:54 <Martix> AFAIR I can reproduce this bug on baremetal with Intel
18:19:14 <adamw> jreznik: ajax says the cirrus case is likely a different bug
18:19:16 * nirik hasn't seen this with xscreensaver. ;)
18:19:21 <adamw> and an intel case likely would be too
18:19:21 <jreznik> adamw: ok
18:19:26 <nirik> anyhow, -1 blocker, +1 nth
18:19:38 <adamw> possibly similar code problems in different drivers, but still technically different bugs
18:19:38 <jreznik> +1 nth
18:19:41 <zodbot> Ticket notification - f18alphanicetohave: [Bug 856225] PackageKit can't import Fedora GPG key <https://bugzilla.redhat.com/show_bug.cgi?id=856225>
18:19:48 <jreznik> adamw: seems reasonable
18:19:54 <Martix> nirik: its not xscreensaver but this is part of Gnome Shell
18:19:54 <adamw> there's obviously a workaround to this - disable screen locking
18:19:57 <adamw> so that's another -1
18:20:28 <nirik> yes, I'm aware, was making a joke. ;)
18:20:36 <Martix> nirik: ok
18:21:03 <Martix> adamw: possibly physical security issue?
18:21:09 <tflink> proposed #agreed 856256 - RejectedBlocker, AcceptedNTH - This does not clearly violate any of the F18 alpha release requirements and can be worked around by disabling the screen saver. However, a tested fix would be accepted.
18:21:15 <jreznik> btw. cirrus/vnc combo makes g-s totaly unusable... while testing it
18:21:46 <Viking-Ice> ack
18:21:48 <nirik> ack
18:21:55 <Martix> I had switched to KDE as a workaround
18:22:11 <Martix> ack
18:22:23 <adamw> ack
18:22:31 <tflink> #agreed 856256 - RejectedBlocker, AcceptedNTH - This does not clearly violate any of the F18 alpha release requirements and can be worked around by disabling the screen saver. However, a tested fix would be accepted.
18:22:35 <tflink> #topic (856399) RC2 DVD is missing grub2-efi and shim packages
18:22:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856399
18:22:40 <tflink> #info Proposed Blocker, MODIFIED
18:22:49 <adamw> +1 blocker, this breaks efi installs
18:22:56 <nirik> +1 blocker
18:23:00 <jreznik> as we already voted several times that we want sb, +1
18:23:12 <jreznik> +1 blocker :)
18:23:15 <jlk> +1
18:23:36 <Martix> +1 blocker
18:23:52 <adamw> jreznik: it's not SB related
18:24:00 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violated the following F18 alpha release criterion for (u)EFI systems: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
18:24:07 <adamw> jreznik: never confuse UEFI and SB: this breaks *any* UEFI install, SB doesn't have to be involved at all
18:24:08 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
18:24:18 <Viking-Ice> ack
18:24:23 <jreznik> adamw: I saw shim...
18:24:29 <Martix> ack
18:24:30 <nirik> ack
18:24:35 <adamw> ack (well, you have to combine it with one of the 'installed system must work' criteria, but eh)
18:24:35 <tflink> #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
18:24:48 <adamw> jreznik: grub2-efi is missing too, not just shim
18:24:55 <jreznik> it was like a red flag for bull :)
18:25:04 <tflink> point, this affects the post-install not the install env.
18:25:08 <adamw> brb, call of nature
18:25:10 * jreznik understands the problem now
18:25:33 <tflink> #undo
18:25:33 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x7f58058b5050>
18:25:59 <Martix> ?
18:27:05 <zodbot> Ticket notification - f18betablocker: [Bug 852841] Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet) <https://bugzilla.redhat.com/show_bug.cgi?id=852841>
18:27:10 <jreznik> Martix: maybe 'installed system must work' criteria?
18:27:12 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
18:27:35 <jreznik> ack, /me is ok with both
18:27:41 <Viking-Ice> ack
18:27:52 <Martix> ack
18:28:04 <adamw> ack
18:28:05 <zodbot> Ticket notification - f18alphanicetohave: [Bug 852841] Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet) <https://bugzilla.redhat.com/show_bug.cgi?id=852841> || [Bug 856256] Crash when unlocking screensaver <https://bugzilla.redhat.com/show_bug.cgi?id=856256>
18:28:08 <tflink> eh, the first one isn't true - the installer does boot and run on (u)EFI systems - the resulting install doesn't boot because the grub2-efi package isn't present on the DVD
18:28:17 <tflink> #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
18:28:23 <adamw> btw, i pushed the fix for this yesterday, so it should have mashed overnight and we shouldn't have to wait to do a compose
18:28:24 <Martix> tflink: ok
18:28:29 <jreznik> tflink: ok, this one is really tough for me :D
18:28:55 <tflink> alrighty, that's all of the proposed blockers on my list
18:29:27 <tflink> any objections to moving on to the proposed NTH?
18:29:52 <Martix> lets move on
18:30:03 <jreznik> go on
18:30:18 <tflink> #topic (855510) Alpha RC2: Cannot get past "Booting in ...... in 0 seconds" screen on iMac 2011 (booting from USB)
18:30:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855510
18:30:23 <tflink> #info Proposed NTH, NEW
18:31:30 <Viking-Ice> imac he's probably just missing some added kernel command line foo
18:32:00 <adamw> he actually seems to be doing a tour of all the worst ways to create a usb stick
18:32:08 <adamw> "I just copied the files on a bootable USB stick, should that not be enough?"...no.
18:32:16 <adamw> "Tried with liveusb-creator"...no.
18:32:19 <tflink> do we have any tests on other macs?
18:32:26 <adamw> mjg59 might have tried it, i dunno.
18:32:27 <jreznik> isn't it related to uefi on macs?
18:32:41 * kparal doesn't know whether jskladan tested Mac Mini
18:32:49 <tflink> I didn't think that liveusb-creator worked w/ EFI w/o extra command line args
18:32:54 <adamw> jreznik: quite possibly, but the uefi bug we just accepted is for post-install, the installer ought to boot via uefi. and this bug says it's not booting at all. but yeah, it's pretty vague.
18:32:55 <Viking-Ice> it takes ages using the livecd-to-using method ( compared to dd )
18:33:04 <kparal> I can make sure I test Mac Mini tomorrow, if you want
18:33:04 <adamw> tflink: i don't know that liveusb-creator works with efi full stop
18:33:16 <adamw> the methods that definitely work are livecd-iso-to-disk --efi and dd
18:33:25 <adamw> but you have to pass --efi to litd, it doesn't create EFI stuff by default
18:33:31 <tflink> adamw: yeah, I can't remember if it was fixed or not
18:33:47 <tflink> either way, I'd say either punt or reject
18:33:53 <adamw> so even though he says he tried 'livecd updates from update-testing', and that means livecd-iso-to-disk, we don't know if he passed --efi.
18:33:59 <Viking-Ice> in anycase -1 nth we need more info and exact command line used to create that bootable stick
18:34:01 <adamw> punt, i'd like more data
18:34:03 <tflink> it sounds like the boot media wasn't created correctly
18:34:17 <jreznik> kparal could provide more data
18:34:30 <adamw> well, this guy has an iMac, not a Mac Mini
18:34:33 <jreznik> and macs are probably not going to be top consumers of f18alpha
18:34:52 <tflink> proposed #agreed 855510 - We don't have enough information to decide on NTH status for this - needs re-testing with a USB media creation method which we know works for EFI and hopfully other tests using apple hardware
18:35:02 <jreznik> ack
18:35:41 <adamw> ack
18:35:48 <nirik> ack
18:35:51 <tflink> #agreed 855510 - We don't have enough information to decide on NTH status for this - needs re-testing with a USB media creation method which we know works for EFI and hopfully other tests using apple hardware
18:35:54 <nanonyme> adamw, what was the vote result, btw?
18:35:55 <tflink> #topic (855991) jack needs rebuild for removal of libfreebob
18:35:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855991
18:35:56 <tflink> #info Proposed NTH, ON_QA
18:36:29 <nanonyme> (oops, postponing question)
18:36:30 <tflink> +1 NTH since this is a blocker for non-primary DEs
18:36:48 <Martix> someone turned lights off, moving home...
18:36:48 <Viking-Ice> agreed +1 nth
18:36:54 <jreznik> +1 nth
18:36:55 <adamw> nanonyme: on that 'warn about destroying disks' bug from earlier? it was rejected
18:37:03 <adamw> nanonyme: details in the ticket
18:37:17 <adamw> +1 nth
18:37:25 <adamw> i assumed this was going to get +1ed and we pulled it for RC1/RC2, btw.
18:37:33 <adamw> which is why we have an lxde spin. :P
18:37:45 <tflink> proposed #agreed 855991 - AcceptedNTH - Violates the following F18 alpha release criterion for non-primary DEs (LXDE, SoaS), making it an NTH bug - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
18:37:51 <nirik> ack
18:38:03 <jreznik> ack
18:38:13 <adamw> ack
18:38:21 <tflink> #agreed 855991 - AcceptedNTH - Violates the following F18 alpha release criterion for non-primary DEs (LXDE, SoaS), making it an NTH bug - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
18:38:26 <tflink> #topic (848305) When kernel modsetting is enabled, laptop screen remians off until Xorg starts (ironlake)
18:38:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=848305
18:38:32 <tflink> #info Proposed NTH, ON_QA
18:38:56 * tflink goes afk for a minute
18:40:50 <Viking-Ice> +1 nth
18:42:10 * Viking-Ice goes grabbing a coffee in the meantime
18:42:25 <adamw> so this bug is kinda 'representative'
18:42:41 <adamw> the underlying problem could actually cause many symptoms
18:43:07 <adamw> another thing it causes, for instance, is the 'cirrus' modesetting kernel module not to load properly, and so cirrus KVMs use xorg-x11-drv-vesa not xorg-x11-drv-modesetting as intended
18:43:24 <tflink> +1 NTH
18:43:28 <adamw> i suspect it might also be the cause of the weirdness people see from time to time where X and a tty seem to be present on vt1 simultaneously
18:43:48 <adamw> halfline and airlied were both of the opinion we ought to pull the new plymouth into alpha and make sure this doesn't cause any major problems we didn't catch yet
18:44:08 <adamw> so, +1 from me.
18:45:09 <tflink> proposed #agreed 848305 - AcceptedNTH - While the most obvious symptom of this bug is cosmetic, it is suspected that there could be other, major problems lurking behind it. A tested fix would be accepted for F18 alpha
18:45:12 <nanonyme> +1 as well
18:45:23 <adamw> ack
18:45:25 <nanonyme> heh, seems didn't matter ;)
18:45:52 <adamw> nanonyme: we usually get a bit slack at the NTH review stage of the meeting, because by this point lots of attendees have usually passed out through sheer despair :P
18:46:27 <nanonyme> well, I'm in a bus on my way home so I have nothing better to do than be here and vote :)
18:46:36 <Viking-Ice> I'm still at work
18:46:38 <tflink> and it's just proposed - I'd change it if we got enough -1 votes
18:46:45 <Viking-Ice> 18:45 here
18:46:58 <tflink> any other ack/nak/patch?
18:47:27 * adamw puts on a fake moustache and says 'ack' in a bogus accent
18:47:48 <adamw> the man from del monte, he say 'ack'
18:48:05 <tflink> #agreed 848305 - AcceptedNTH - While the most obvious symptom of this bug is cosmetic, it is suspected that there could be other, major problems lurking behind it. A tested fix would be accepted for F18 alpha
18:48:09 <tflink> #topic (856090) ntpd not installed, causes firstboot to hang when user selects "Sync date and time over network"
18:48:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856090
18:48:15 <tflink> #info Proposed NTH, NEW
18:48:34 <adamw> hanging firstboot is pretty crappy, so +1.
18:48:37 <tflink> +1
18:48:43 <nanonyme> +1
18:48:48 <Viking-Ice> +1
18:49:19 <tflink> proposed #agreed 856090 - AcceptedNTH - While not a blocker, firstboot hanging is a problem and a tested fix would be accepted for F18 alpha
18:49:26 <adamw> ack
18:49:30 <Viking-Ice> ack
18:50:01 <tflink> #agreed 856090 - AcceptedNTH - While not a blocker, firstboot hanging is a problem and a tested fix would be accepted for F18 alpha
18:50:11 <tflink> #topic (855784) packagekit waits for authentication forever is user is not in wheel group
18:50:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855784
18:50:17 <tflink> #info Proposed NTH, NEW
18:50:35 <adamw> +1, i guess
18:51:36 <tflink> under the assumption that a non-wheel user is supposed to be able to install updates, +1
18:52:02 <adamw> note that if you have an admin user, it works
18:52:08 <adamw> the non-admin user is prompted for the admin user's password
18:52:22 <adamw> but if there's no admin user, non-admin users should be prompted for root's password, i think, and they aren't...
18:52:46 <tflink> but that's not the bug here
18:52:56 <tflink> at least, not how I'm reading it
18:52:57 * jreznik is having connection issues...
18:53:07 <Viking-Ice> -1 to me this is just an regular bug
18:53:46 <tflink> but either way, PK shouldn't just sit there - either error out or ask for pw
18:54:03 <nanonyme> haven't yet read the bug this is claimed to be duplicate of
18:54:04 <tflink> so we're +2/-1
18:54:29 <Viking-Ice> from my point of view non admin users should not receive update notification in the first place
18:54:34 <adamw> i don't mind a -1, really
18:55:20 <adamw> since we're apparently not caring too much about broken PK anyway, it kinda could be argued that that supports +1 (because who cares if the fix breaks it worse?) or -1 (why try and fix it)?
18:57:05 <tflink> proposed #agreed 855784 - RejectedNTH - While PK shouldn't hang when run by a non-admin user, admin users are able to apply updates without issue. This was not deemed severe enough to accept as NTH for F18 alpha
18:57:09 <tflink> ack/nak/patch?
18:57:15 <Viking-Ice> ack
18:57:19 <jreznik> on live it makes difference, we have running pkgkit there... and one could argue live is that default and we should not care about DVD too much :)
18:57:28 * adamw will ack anything at this point...
18:58:36 <nanonyme> ack though uncertain enough not to vote
18:58:40 <nanonyme> ;)
18:58:47 <tflink> #agreed 855784 - RejectedNTH - While PK shouldn't hang when run by a non-admin user, admin users are able to apply updates without issue. This was not deemed severe enough to accept as NTH for F18 alpha
18:58:57 <tflink> #topic (850783) Font used in F18 grub2 configuration is too large for low resolution displays, makes it effectively impossible to edit entries in VMs
18:59:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=850783
18:59:03 <tflink> #info Proposed NTH, NEW
18:59:25 <tflink> so this is why I can't edit the boot options on a VM
18:59:27 <tflink> +1 nth
18:59:36 <nirik> +1 nth
18:59:41 <Viking-Ice> yup bloddy  nuance +1 nth
18:59:42 <nirik> this bug is anoying :)
18:59:43 <nanonyme> +1
19:00:34 <tflink> proposed #agreed 850783 - AcceptedNTH - This bug prevents changing the boot options post-install and can interfere with debugging.
19:00:41 <adamw> ah, sounds like mads has a fix, that's good
19:00:42 <adamw> ack
19:00:48 <Viking-Ice> ack
19:00:49 <adamw> i was kinda struggling with it
19:00:56 <tflink> #agreed 850783 - AcceptedNTH - This bug prevents changing the boot options post-install and can interfere with debugging.
19:01:06 <tflink> #topic (856372) Package selection spoke is not respecting 'optionlist' from comps in F18 Alpha RC2
19:01:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856372
19:01:11 <tflink> #info Proposed NTH, MODIFIED
19:01:36 <jreznik> +1 nth, /me already hit this
19:02:15 <jlk> I submitted a fix upstream for this
19:02:16 * tflink hesitates to take another yum fix considering the fun we've had thus far
19:02:28 <jlk> but I'd only want to see this come in /if/ it's the only change made
19:02:30 <tflink> what else would we be getting with this fix
19:02:42 <jlk> and it only really effects writing /out/ of repodata
19:02:59 <jlk> the yum folks could jsut add this patch to the f18 branch build
19:03:06 <tflink> which means that we wouldn't get the fix unless we slip
19:03:08 <jlk> so this patch and nothing else.
19:03:26 <jlk> tflink: we're re-spinning anyway aren't we?  could have a yum build in minutes
19:03:35 <adamw> yes, we need to re-spin
19:03:42 <tflink> yeah but if the problem is in the repo metadata, we'd have to wait for a new mash
19:03:46 <adamw> i'm with jlk: +1 so long as we can get a yum build that *only* changes this
19:03:52 <Viking-Ice> agreed accepted NTH with this patch and nothing else
19:04:13 <tflink> yeah, I'm OK with that - my hesitation was due to not being sure if that's all we'd get
19:04:37 <jlk> of course, there is risk that having /working/ comps data could expose an as of yet unseen anaconda bug in the software selection screen, but....
19:04:40 <adamw> the procedure for NTH bugs is that accepting them doesn't mean we *have* to take the fix
19:04:47 <adamw> accepting them means we have the option of taking the fix
19:04:58 <adamw> so we can accept this with an explicit note that we intend to pull it only if it's the only change to yum
19:05:17 * nirik nods. sounds good.
19:05:51 <tflink> proposed #agreed 856372 - AcceptedNTH - This causes problems when selecting optional elements to package groups and can't be fixed with an update. A tested yum build with ONLY the fix for this bug would be accepted for F18 alpha
19:05:54 * Martix is back
19:06:05 <Viking-Ice> ack
19:06:13 <jreznik> jlk: then we can have a new anaconda for wipe bug if it's only about build in one minute :)
19:06:29 <jlk> jreznik: no, the solution would be to back out the yum update :)
19:06:30 <adamw> ack
19:06:35 <adamw> right
19:06:46 <adamw> it should be simple enough to smoke test this fast, and yank yum and re-spin if it breaks something
19:07:22 <tflink> I suppose that I could pull it in quick and change the boot.iso I'm waiting on to a full DVD build
19:07:36 <tflink> but a full RC would be a better test
19:07:45 <tflink> #agreed 856372 - AcceptedNTH - This causes problems when selecting optional elements to package groups and can't be fixed with an update. A tested yum build with ONLY the fix for this bug would be accepted for F18 alpha
19:08:27 <tflink> #topic (856086) Anaconda on LiveCD should use window decorations
19:08:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856086
19:08:27 <tflink> #info Proposed NTH, NEW
19:08:33 <tflink> I'd be OK with NTH on this
19:08:42 <tflink> definitely not blocker, but +1 NTH
19:09:34 <Viking-Ice> -1 nth
19:09:52 <Viking-Ice> this is just a regular bug
19:09:58 <adamw> yeah, i'm with viking.
19:10:15 <adamw> the windows of newui don't look particularly like they expect or need to be resized, to me.
19:10:28 <adamw> i don't see the benefit in fiddling with anaconda to fix this at this point.
19:10:28 <tflink> ok
19:10:37 <adamw> jlk: wdyt?
19:10:49 <jlk> you're not going to see a fix for this in alpha
19:10:50 <Viking-Ice> safer to hand them sun glass ;)
19:10:56 <Viking-Ice> mean sun glasses
19:11:19 <tflink> I didn't say that I was expecting a fix, just that I couldn't see a reason to reject a tested fix if it happened
19:12:05 <tflink> proposed #agreed 856086 - RejectedNTH - This is mostly a cosmetic issue and not severe enough to justify taking a fix past freeze for alpha
19:12:09 <msivak> adamw: so firstboot will have the admin checkbox checked in 18.3 which I am building now :)
19:12:14 <Viking-Ice> ack
19:12:15 <jreznik> ack
19:12:28 <adamw> msivak: oh great - i actually just this second did a git pull to try and figure it out myself :)
19:12:28 <jreznik> msivak: hero :)
19:12:40 <adamw> msivak: any fix for the ntp thing? or is that not actually a bug in firstboot?
19:12:45 <adamw> ack
19:12:47 <tflink> #agreed 856086 - RejectedNTH - This is mostly a cosmetic issue and not severe enough to justify taking a fix past freeze for alpha
19:13:00 <tflink> #topic (840160) specifying bootloader --password results in system that won' t boot without the password
19:13:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=840160
19:13:06 <tflink> #info Proposed NTH, NEW
19:14:51 <Viking-Ice> hm wondering if this might be a blocker?
19:15:01 <tflink> not for alpha, I don't think
19:15:09 <tflink> at least not with the current criteria
19:15:46 <jlk> it's a change in behavior between grub and grub2 IIRC
19:16:21 <adamw> it would help to get input from grub devs, yeah...
19:16:25 <adamw> we should probably CC pjones/mads
19:16:27 <tflink> I'm hesitant to take a grub fix this late for something that doesn't violate alpha criteria
19:16:29 <Viking-Ice> -1 nth let's not remotely risk messing with that stuff at this point
19:16:55 <adamw> yeah, that's a good point
19:17:06 <adamw> we learned last release not to take NTH stuff for critical packages lightly
19:17:08 <Viking-Ice> the workaround seems to be dont set "--password" in ks file
19:17:30 <jreznik> -1 nth
19:17:38 <adamw> i guess there's no easy way to achieve the desired result - a password for modifying config, but not just for booting - but that doesn't seem a significant concern for an alpha.
19:17:44 <adamw> you shouldn't need to lock down an alpha install with a password.
19:18:04 <adamw> -1
19:18:43 <jlk> also it's fairly easy to work around, put in hte password :)
19:18:56 <Viking-Ice> if you for some weird reason you do then you just have to run grubpass --> setpassword
19:18:57 <tflink> proposed #agreed 840160 - RejectedNTH - This doesn't even partially violate any of the F18 alpha release criteria, can be worked around by removing the --password option on the bootloader command and would require changes to grub if it was fixed. Deemed too risky for the benefit at this point in the release cycle and rejected as NTH for F18 alpha
19:19:16 <tflink> ack/nak/patch?
19:19:51 <Viking-Ice> ack ( could mention also grubpass --> setpassword )
19:19:57 <msivak> adamw: what is the bugnumber for the ntp issue?
19:20:38 <nanonyme> ack though I'm still not convinced at this point whether this is a bug at all or not :)
19:21:22 <nanonyme> (as above, checking with upstream imo really necessary)
19:21:34 <tflink> #agreed 840160 - RejectedNTH - This doesn't even partially violate any of the F18 alpha release criteria, can be worked around by removing the --password option on the bootloader command and would require changes to grub if it was fixed. Deemed too risky for the benefit at this point in the release cycle and rejected as NTH for F18 alpha
19:21:44 <tflink> wheee! Done with the proposed NTH
19:21:57 <tflink> anyone still have the energy to go through the accepted blockers?
19:22:38 <Viking-Ice> nah I need to clock out before the alarm system goes on thanks for chairing
19:23:03 <tflink> np, thanks for helping out
19:23:06 <Viking-Ice> later
19:23:07 <nanonyme> chairing is caring, obviously :)
19:23:28 <adamw> msivak: er just a sec
19:23:58 <msivak> adamw: nevermind I found it
19:24:25 <tflink> actually, we only have one non-verified accepted blocker to do
19:24:55 <tflink> let's get 'er done
19:24:57 <adamw> several nth's, though
19:24:59 <tflink> #topic (852403) PolicyKit authentication in Fedora 18 Alpha TC3 results in selinux denial
19:25:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852403
19:25:05 <tflink> #info Accepted Blocker, MODIFIED
19:26:01 <adamw> i'm okay with pulling latest selinux-policy for this.
19:26:03 <tflink> looks like a new build is available - needs testing and verification
19:26:15 <adamw> after alpha they only ever relax restrictions in selinux-policy, never tighten them, so it's usually safe and a good idea to pull the latest.
19:26:33 <tflink> #info selinux-policy-3.11.1-18 is now available and should fix this bug
19:26:49 <tflink> #undo
19:26:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x180ad550>
19:27:12 <tflink> #info selinux-policy-3.11.1-18 is now available and should fix this bug. It needs to be pulled into the next spin and tested
19:27:27 * jreznik confirms the fix
19:27:53 <msivak> adamw: it is system-config-date's fault, firstboot only includes that screen
19:28:00 <tflink> ok, that would be all of the accepted blockers for now
19:28:01 <jreznik> dan was probably right we should always take the latest one
19:28:11 <adamw> msivak: ok.
19:28:39 <tflink> adamw: did you want to review the accepted nth?
19:28:49 <adamw> no, sorry, i was misunderstanding your comment
19:28:59 <adamw> thought you were talking about what was needed for rc3
19:29:29 <tflink> ok, I misunderstood
19:29:35 <tflink> #topic Open Floor
19:29:55 <tflink> only 3.5 hours ...
19:30:03 <adamw> hey, not bad.
19:30:04 <tflink> any other topics to bring up?
19:30:41 <msivak> adamw: firstboot-18.3 built for f18-candidate so it is in QA's hands now
19:31:03 <jreznik> msivak: thx
19:31:06 <tflink> #info blocker tracking app update work is going on - feedback on changes would be appreciated
19:31:12 <tflink> #link http://lists.fedoraproject.org/pipermail/test/2012-September/109995.html
19:31:54 <adamw> msivak: can you submit it as an update too?
19:32:00 <adamw> msivak: i could do that, but then i couldn't give it karma
19:32:08 <adamw> mark it as fixing 856194
19:32:14 <Martix> msivak: nice
19:32:25 <tflink> #info if F18 alpha slips again, the next blocker review meeting will be 2012-09-19 @ 16:00 UTC
19:33:49 <Martix> I hope not slip again
19:33:57 <adamw> me too...
19:34:17 <Martix> many test days starts next week
19:34:19 <tflink> if there's nothing else ...
19:34:28 * tflink sets fuse for [0,5] minutes
19:34:37 <Martix> *bang*
19:35:03 <jreznik> btw. what everything we need to make it tmrw? rc3, testing - kparal, are you still here? we will need heroes tmrw, anything else?
19:35:16 <adamw> Martix: actually a lot of test days want to re-schedule for later, i need to sort that out once rc3 is done
19:35:31 <adamw> jreznik: we should be able to spin rc3 more or less now, i'll work on that next
19:35:34 <zodbot> Ticket notification - f18alphanicetohave: [Bug 856194] firstboot has to insist the first user is admin when root account is locked <https://bugzilla.redhat.com/show_bug.cgi?id=856194>
19:35:35 <adamw> then we just need to do the testing by tomorrow
19:35:54 <adamw> doing all the alpha testing in 24 hours isn't actually too hard since we have good timezone coverage and the alpha test set is a lot smaller than beta/final
19:36:00 <adamw> doing it for final is much tougher, though we can.
19:36:02 <jlk> I can probably pitch in on some of the testing
19:36:04 <tflink> the boot.iso build with the new nm is done
19:36:34 <Martix> jreznik: unfortunatelly I'll unavailable tomorrow
19:36:56 <jreznik> adamw: ok, please take care of our "night shift", I'll take care of the day :)
19:37:06 <adamw> =) thanks
19:37:34 <msivak> adamw: sure, as soon as I reset my fedora password..
19:37:44 <adamw> msivak: thanks
19:38:48 <tflink> OK, thanks for coming everyone!
19:38:55 * tflink will send out minutes shortly
19:38:57 <tflink> #endmeeting