16:01:56 #startmeeting f18-alpha-blocker-review-4 16:01:56 Meeting started Wed Aug 22 16:01:56 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:56 fireworks! 16:01:58 #meetingname f18-alpha-blocker-review-4 16:01:58 The meeting name has been set to 'f18-alpha-blocker-review-4' 16:02:03 #topic Roll Call 16:02:11 * kparal needs to go in 10 minutes 16:02:12 who all's here for some blocker review fun? 16:02:25 * elad_laptop is here 16:02:37 kparal: not acceptable 16:02:39 * nirik is lurking around. 16:02:44 :) 16:02:56 I'll read the log, I promise 16:02:59 kparal: are there any bugs in particular that you'd like to see covered first? 16:03:29 tflink: I don't think so 16:03:50 nothing stands out in the proposed list 16:04:18 ok, just making sure 16:04:30 yo 16:04:50 elad_laptop: welcome 16:06:10 * tflink waits another minute or two to see if we get 1 or 2 more people 16:06:18 * mkrizek joins 16:06:20 mkrizek is my press manager today 16:06:45 so all emails to you should be routed through him? 16:07:11 oh god no 16:07:13 :) 16:07:24 he would be stating all my decisions and we can then blame him if they prove to be wrong 16:07:45 * rbergeron is here though god only knows how my internets will be 16:07:55 * rbergeron is coming to you LIVE from fudcon valencia hotel 16:08:05 that sounds like a pretty sweet setup there - if it goes right, you can take credit. if it goes wrong, he can be blamed 16:08:22 tflink: exactly 16:08:23 * maxamillion is here-ish 16:08:30 I'm starting to like it 16:08:32 * tflink read internets as internals at first - glad that it was misread 16:09:02 cool, I think we have a quorum, lets get started with some always awesome boilerplate 16:09:07 #topic Introduction 16:09:18 #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:09:29 We'll be following the process outlined at: 16:09:29 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:09:29 The bugs up for review today are available at: 16:09:30 #link http://qa.fedoraproject.org/blockerbugs/current 16:09:44 The criteria for release blocking bugs can be found at: 16:09:45 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 16:09:58 * tflink remembered to update the link this time :) 16:10:03 * adamw loves boilerplate 16:10:03 tflink: holy jeebus, that webpage is *amazing* ... who made http://qa.fedoraproject.org/blockerbugs/current ? 16:10:11 maxam: tflink did, take a bow tim 16:10:26 tflink: that's absolutely *awesome* 16:10:29 * tflink bows but it's not all that special 16:10:39 it needs a facelift :) 16:10:39 <--- webdev noob 16:10:39 oh, hell yes 16:10:43 when did that happen? 16:10:48 * rbergeron lifts up the rock 16:10:59 rbergeron: +1 16:11:01 that's awesome. 16:11:06 rbergeron: the first version was released into the wild right before the first blocker review meeting 16:11:06 * kparal needs to go. mkrizek, don't forget being a good press manager 16:11:21 I noticed it on a different domain not long ago, glad it made it out to be official 16:11:23 rbergeron: it just got put onto fp.o last week. before that it was even more awesome because it was hosted on tim's own domain, which is supermegawaffle.com =) 16:11:41 tflink: you own supermegawaffle.com? 16:11:53 rbergeron: yep, that's one of my domains 16:12:01 that's ... well, that just rocks my waffle, that's all i have to say about it. especiaially since i don't ant to detract from the epic fun of a blocker meeting 16:12:13 which go on for some time during this part of the cycle :) 16:12:44 elad_laptop: yeah, it took me a while to get everything set up in the fedora infra. actually, I'm still working on that (packaging issues left to iron out) 16:13:00 but it works and we digress 16:13:28 if anyone has ideas for what else we could do with the app (different views, an API etc.), feel free to propose them 16:13:46 any objections to starting with the proposed blockers? 16:13:57 nope 16:14:13 #topic (841451) polkitd doesn't start in rawhide 16:14:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=841451 16:14:14 #info Proposed Blockers, NEW 16:14:15 Bug 841451: unspecified, unspecified, ---, davidz, NEW , polkitd doesn't start in rawhide 16:14:29 so sigh, i really need to get around to re-checking this. 16:14:45 I was just wondering if we got around to that, I haven't done it either 16:14:56 if anyone has a clean tc3 install sitting around... 16:15:11 * maxamillion is working on installing one now 16:15:13 i'm kinda convinced myself it's 844167, but really ought to confirm. 16:15:51 * nirik has one... 16:15:55 what am I checking? 16:16:12 nirik: did polkitd start correctly? 16:16:19 * nirik fires up the machine. 16:16:32 polkit is running on my almost-tc3 VM 16:16:47 interestingly enough, polkitd.service does not exist. only polkit.service 16:17:14 tflink: I can confirm that, checked that earlier today 16:17:27 * nirik waits for virt-manager to connect 16:17:57 tflink: yeah, that's normal. 16:18:10 ok, I thought it was supposed to be polkitd.service 16:18:25 no, it's definitely polkit.service. 16:18:56 either way, polkit.service is running on my VM 16:19:28 basically it failed cause it needed its own user, which was not created for updates 16:19:28 does the 'polkitd' user and group exist? 16:19:36 s/user/group/ 16:19:49 when you do a clean install or a reinstall, the group will be there 16:20:20 yes, polkit user and group both exist, gid 999, uid 999 16:20:23 * nirik will have to rescue his virt instance. It's trying to start lightdm, but due to cirrus breakage it's not starting X right. 16:20:41 nirik: set the video card to 'vga' or add 'nomodeset'. 16:20:58 tflink: ok. i think we can probably just make the call that it's 844167 then, and hence not a blocker as it relates to yum upgrade. 16:20:58 Therefore I think this should not be an alpha blocker but rather a beta blocker 16:21:01 yeah, grub is also hosed... but will fix. 16:21:05 i expect it wouldn't hit an anaconda upgrade as anaconda runs in permissive mode. 16:21:27 we will have to check that. 16:21:30 just yum upgrade, then? 16:21:38 elad_laptop: we can't until the upgrade code exists =) 16:21:41 * tflink isn't sure that's as blocker worthy 16:21:44 tflink: that's my current understanding, yeah. 16:21:45 adamw: exactly. 16:21:58 either way, lets move to beta proposed 16:22:45 proposed #agreed 841451 - RejectedBlocker (Alpha) - This appears to be an upgrade issue which is not alpha blocker material. Change to a proposed beta blocker. 16:22:50 ack/nak/patch 16:22:54 ack 16:23:07 ack 16:23:09 ack 16:23:18 ack 16:23:21 #agreed 841451 - RejectedBlocker (Alpha) - This appears to be an upgrade issue which is not alpha blocker material. Change to a proposed beta blocker. 16:23:28 * nirik confirms polkit is running in my tc3 install too. 16:23:31 #topic (850550) TypeError: verifyLocalPkg() takes exactly 1 argument (2 given) 16:23:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=850550 16:23:36 Bug 850550: urgent, unspecified, ---, packaging-team, ON_QA , TypeError: verifyLocalPkg() takes exactly 1 argument (2 given) 16:23:36 #info Proposed Blockers, ON_QA 16:24:13 sounds like a pretty clear blocker to me 16:24:21 I think so too 16:24:22 * tflink looks for criterion 16:25:06 "The installer must be able to use at least one of the HTTP or FTP remote package source options" ? 16:25:15 which isn't quite right 16:25:43 " The installer must be able to complete an installation using the text, graphical and VNC installation interfaces " 16:25:58 with this bug it can't even start an installation 16:26:08 therefor, this criterion fits 16:26:13 true but the emphasis there is the interfaces 16:26:22 but it's closer than the one I listed 16:26:26 any other thoughts? 16:26:36 i'm, er, not sure on this one. 16:26:53 bcl said they'd actually worked around this bug in anaconda, i thought? 16:27:23 oh, well, we need to take the fix anyway, so meh. +1 16:27:38 "The installer must be able to complete package installation with the default package set for each supported installation method" 16:27:53 but this is semantics after a point 16:28:31 proposed #agreed 850550 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:28:45 ack/nak/patch? I can switch the criterion if that works better 16:28:49 ack 16:29:13 acl 16:29:14 ack 16:29:59 ack 16:30:06 #agreed 850550 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:30:16 #topic (849998) KDE artwork in Spherical Cow still contains content from the previous release 16:30:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=849998 16:30:21 Bug 849998: unspecified, unspecified, ---, rdieter, ON_QA , KDE artwork in Spherical Cow still contains content from the previous release 16:30:21 #info Proposed Blockers, ON_QA 16:30:55 pretty clear blocker 16:31:06 +1 blocker 16:31:21 note: this one's fixed 16:31:33 proposed #agreed 849998 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the install 16:31:48 ack 16:31:49 I bet that's too long, isn't it? 16:31:49 ack 16:31:56 ack 16:32:50 #agreed 849998 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development." 16:33:06 #topic (849982) The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3 16:33:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=849982 16:33:10 Bug 849982: unspecified, unspecified, ---, tcallawa, NEW , The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3 16:33:11 #info Proposed Blockers, NEW 16:33:39 the background is packaged now (I should know cause I have it installed) 16:33:52 but I wonder about "GRUB Boot Menu has also what appears to be Fedora 17 theme." (comment 5) 16:34:03 didn't we disable the grub theme cause it caused slowness? 16:34:09 it does match the F17 background 16:34:27 I thought we disabled the grub theme, to make it themeless like before f17ga 16:34:28 elad_laptop: that was for F17 and I think that we also didn't have a complete theme in time 16:34:34 elad_laptop: I installed it earlier today and the grub theme was enabled 16:34:54 and yes, it's F17 background 16:35:09 netinst 16:35:10 sounds like a blocker to me, other thoughts? 16:35:15 +1 16:35:30 +1 16:35:38 for alpha, let's make this a blocker and disable the theme (unless the design team can get one ready without slowing alpha), the design team will attempt the finalize a theme for beta 16:35:47 so yeah, +1 16:36:18 sorry for being late, another meeting conflict 16:36:30 proposed #agreed 849982 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development" 16:36:42 jreznik: no worries, we're still reviewing bugs :) 16:36:50 ack 16:36:54 ack 16:36:57 * tflink wonders if the grub theme is blocking, though 16:37:07 It's artwork 16:37:12 ack 16:37:16 my understanding of the criterion is that we wanted to reduce confusion between the releases 16:37:17 so wait, what are we accepting here exactly? the grub background? 16:37:27 the grub theme doesn't say F17 and it's different from F17 16:37:57 * jreznik prefers consistent alpha theming 16:37:57 it somehow resemble F17 though 16:38:09 It is the f17 background 16:38:17 and it was made for 17 16:38:39 true but it still looks different and doesn't say F17 - fewer chances for confusion 16:39:00 mkrizek: the question is - do we want to theme grub or not? that's the question for design team (we do not theme for each release plymouth...) 16:39:12 if gnome isn't installable, we might need to punt until we can get a working gnome install 16:39:33 We did want to theme grub... 16:39:36 the criterion probably isn't the best we ever came up with... 16:39:43 yes 16:39:53 anyway, I say let's not make this a blocker, logic. 16:40:19 yeah, I think of alpha blocker artwork issues as stuff like the installer using the wrong version's graphics during install or something like that 16:40:31 maybe punt on it for now and try to clarify with the design team exactly what the plan is for what bits of artwork should change per release... 16:40:33 I remember the theme being ready for f17 and then disabled because people reported it caused so much slowness grub was unusable 16:40:45 yeah, it landed way late in f17 16:41:05 * jreznik can work with artwork team on it 16:41:46 sounds good to me 16:41:47 adamw: as a member of the design team (I don't speak for the team, only myself) , I think we should make grub theme generic 16:41:52 elad_laptop: that's why it's alpha stuff... theming is artwork, yes, but implementation could be broken... 16:42:05 jreznik: no, the intent of this criterion is as tflink said, to prevent confusion 16:42:07 elad_laptop: I agree 16:42:17 elad_laptop: +1, once plymouth is generic one, grup should be too 16:42:21 we had a release a while back where the Alpha had graphics all the way through that identified it as the previous release 16:42:31 the grub theme is not generic as of now 16:42:33 so people were posting and saying 'this isn't Fedora N+1 at all, it's Fedora N!' 16:42:35 proposed #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker. 16:42:44 really, we should word the criterion a bit better so that entirely generic art is okay 16:42:53 tflink: that kinda works for me 16:43:01 adamw: suggestions for improvement? 16:43:01 jreznik: it being slow is a bug in grub, it is not really good in rendering high resolution graphics 16:43:08 and it shouldn't be, cause it's a bootloader 16:43:15 but that's a different issue 16:43:22 ack 16:43:27 tflink: just state clearly that we're punting, i guess 16:43:43 proposed #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker. Will re-evaluate at the next blocker review meeting. 16:43:53 ack 16:43:54 acl 16:43:55 * nirik shrugs. ack 16:43:55 ack 16:43:58 *ack 16:44:02 #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker. Will re-evaluate at the next blocker review meeting. 16:44:03 ack 16:44:04 * jreznik is not sure 16:44:39 jreznik: I can #undo if you have a suggestion 16:44:58 some of the design team prefers grub un-themed anyway, but that should not block alpha 16:45:26 tflink: go on 16:45:34 ok, moving on 16:45:36 designwise, we shouldn't make grub attract too much attention, and we should also have 0s timeout by default unless other OSs are installed 16:46:07 elad_laptop: perhaps but I'm not sure that's an issue for QA 16:46:16 It's not 16:46:20 #topic (849967) firstboot fails to run partly due to /etc/sysconfig/i18n not being written by anaconda 16:46:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=849967 16:46:25 Bug 849967: unspecified, unspecified, ---, vpodzime, POST , firstboot fails to run partly due to /etc/sysconfig/i18n not being written by anaconda 16:46:26 #info Proposed Blockers, POST 16:46:30 just throwing bits of information around 16:46:58 ok, not trying to shut down discussion - just trying to keep the meeting moving. these take long enough as it is :) 16:47:40 Sure, I understand 16:47:47 seems POST means Patch for this issue has been posted to anaconda-patches-list. 16:47:52 I assume that this affects more than just LXDE and XFCE? 16:48:03 tflink: yep 16:48:18 and not sure what everything relies on i18n correctly written 16:48:48 definitely firstboot 16:48:59 I got no firstboot here with tc3 and an Xfce install. 16:49:03 what is the effect of this and what all does it affect? 16:49:13 is it firstboot or anaconda crashing? 16:49:34 nirik: this one of the issues - missing i18n (traceback) - anaconda one and another is python-meh and gtk3 16:49:59 tflink: this issue is cause by anaconda now writing i18n correctly 16:50:01 isn't firtboot obsolete due to the anaconda redesign? (I'm not sure if configure-during-install was implemented yet) 16:50:09 there's another firsboot bug 16:50:11 elad_laptop: only for gnome desktop... 16:50:24 and it's no anaconda redesign but initial experience 16:50:27 jreznik: yeah, but I'm trying to figure out how the effect manifests 16:50:34 nirik: I'm not talking about the initial experience thing 16:50:36 (not sure about state, I asked mclasen to get status) 16:50:53 http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/03-progress_hub2.svg 16:50:54 elad_laptop: i don't believe anaconda is aiming to replace firstboot, no. 16:50:55 in terms of release blocking DEs, it would have to affect KDE since gnome wouldn't be affected 16:51:03 elad_laptop: ok. My understanding was that it was not obsolete, but I could be wrong. 16:51:07 elad_laptop: I talked to Anaconda guys and they don't know... even the IE cooperation is somehow unclear 16:51:16 elad_laptop: that's a design mockup from a long time back. i don't think it's in the current newui design. 16:51:20 it should be affecting kde as well I would think, but cannot directly confirm 16:51:36 yea, it affects kde 16:51:39 if it's crashing firstboot, it'll affect KDE 16:51:42 tflink: i don't think initial experience actually exists yet. this bug would certainly affect kde. 16:52:01 adamw: not sure about IE state, I asked mclasen on Monday... 16:52:04 ah, I thought that it was already in alpha 16:52:05 ok 16:52:06 but he was on PTO... 16:52:19 tflink: i might be wrong, of course =) 16:52:20 I don't know what anaconda implements at the moment, I only remember what the design was... 16:52:22 so he has to ask team what's the progress 16:52:39 elad_laptop: it's not there and definitely not for f18 16:52:43 either way, it sounds like we can take this as a blocker due to crashing firstboot on a KDE install 16:52:45 okay 16:52:49 yep 16:52:55 yeah, +1 blocker. 16:53:05 +1 blocker 16:53:05 +1 (to be formal) 16:53:17 +1 blocker yes 16:53:23 ahhh, there's a separate anaconda-patches ML now. that clears things up. 16:53:36 :) 16:53:55 proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explic 16:54:04 gah, I need to work on the length of those 16:54:25 you can cut out the parentheses i guess 16:54:40 proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "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. This includes correctly accessing any encrypted partitions when the co 16:54:42 Release Criteria (Simplified Edition) :) 16:54:47 that's still too long 16:54:49 and the second sentence. 16:55:10 proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "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" 16:55:16 is that short enough? 16:55:19 I think you should just give ID numbers to release criteria and use them instead :P 16:55:56 I think that would get confusing to people unfamiliar with the process, to be honest 16:56:02 and to me :) 16:56:05 and me 16:56:14 hence the :P 16:56:20 ah, a bit slow 16:56:21 I was joking. 16:56:29 ack 16:56:32 ack 16:56:37 * jreznik is not computer to translate ID to text description... no blockerno function here 16:56:39 ack 16:56:47 however, the idea of having entire discussions around f18a#7 vs f18a#9 is somewhat amusing 16:57:02 #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "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" 16:57:17 #topic (850775) display managers aren't enabled after installation 16:57:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=850775 16:57:17 #info Proposed Blockers, NEW 16:57:19 Bug 850775: unspecified, unspecified, ---, anaconda-maint-list, NEW , display managers aren't enabled after installation 16:58:01 * nirik was going to file something like this one. ;) 16:58:31 there's a related spins-kickstarts bug 16:58:33 the whole presets thing is going to be crazy this release (not only dms) 16:58:46 https://bugzilla.redhat.com/show_bug.cgi?id=850465 16:58:47 Bug 850465: unspecified, unspecified, ---, kanarip, NEW , KDE Spin should be shipped with KDM as the default login manager 16:59:10 holy moley, i need a vacation. 16:59:28 yeah, lets all go. ;) 16:59:38 right, this is an obvious blocker for me 16:59:41 it sounds like a blocker to me, unless I'm missing something 17:00:10 yep. blocker, but I don't know enough details to say how best to fix it. ;) 17:00:31 yeah, me either 17:00:38 850465 has this: 17:00:42 anyhow, +1 blocker, we should fix it. 17:00:43 "Halfline pointed out too that the old default ordering still takes place, so if only kdm is installed, it will get used." 17:00:53 but that doesn't seem to be the case/ 17:00:53 which doesn't sound like what's actually happening... 17:00:54 ? 17:00:55 yeah 17:00:59 maybe this is a systemd bug? 17:01:06 definitely not anaconda, anyhow, 17:01:27 we moved from the prefdm logic to have a service file for each display manager 17:01:54 proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "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" 17:01:57 therefor we need to make our postinstall scripts aware of it and enable the installed display manager 17:02:01 yeah, i get that. it's the involvement of this 'presets' thing that's confusing the issue for me. 17:02:23 where are the presets currently being set? no where I guess? 17:02:29 tflink: wrong criterion 17:02:34 tflink: this should be the next one 17:02:40 adamw: and as I said - there's going more fun with presets as I heard 17:02:53 firstboot startup doesn't rely on a login manager, but post-firstboot startup does. 17:03:06 point, I was thinking it did for some reason 17:03:18 * nirik guesses it should just go in ks files at least for now... 17:03:44 nirik: we were talking about usin ks on #fedora-kde mtg 17:03:55 proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is s 17:04:01 jreznik: yeah, seems easiest. 17:04:06 what about DVD installs? 17:04:15 nirik: ks for now unless someone manages to understand the presets thing 17:04:18 proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "After firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" 17:04:27 ack 17:04:30 * tflink assumed that it was too long 17:04:31 adamw: I have to ask lennart (that's my action item from kde-sig mtg) 17:04:34 adamw: details details. ;) Yeah, that would be a flaw in that plan. 17:04:42 ack 17:04:49 ack 17:04:55 #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "After firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" 17:04:56 i'm tempted to mark 850465 as a dupe of 850775 and adjust it to systemd so lennart tells us what to do 17:05:07 sound like a plan? or do we want 850465 to be separate? 17:05:08 adamw: sounds reasonable to me. 17:05:27 adamw: sounds good, lennart is only person who can answer it right now 17:05:42 we (as kde sig) are quite lost in this waters... 17:06:12 before I forget ... 17:06:17 I guess now thinking about it we need a package for each spin that uses presets. ;( 17:06:17 #chair adamw 17:06:17 Current chairs: adamw tflink 17:06:29 but that could be bad if multiple ones are installed... 17:06:42 nirik: but hey, anaconda doesn't let you install multiple desktops any more ;) 17:06:53 you can still do it post install... 17:07:02 nirik: that's probably true, and it's idea of presets... but how to solve DVD install? 17:07:06 I have at least one machine with multiple DEs installed 17:07:21 if they are using different numbers/names, one of them will 'win' 17:07:49 anyhow, drifting out of scope. 17:07:53 we will figure it out. 17:08:06 yeah 17:08:12 yep, sounds like it'll be tons of fun 17:08:21 #topic (849395) UnicodeDecodeError: 'utf8' codec can't decode byte 0xb8 in position 0: invalid start byte 17:08:21 so close as dupe and get lennart involvement? 17:08:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=849395 17:08:25 Bug 849395: unspecified, unspecified, ---, rvykydal, MODIFIED , UnicodeDecodeError: 'utf8' codec can't decode byte 0xb8 in position 0: invalid start byte 17:08:26 #info Proposed Blockers, MODIFIED 17:08:50 jreznik: I think they were talking about closing the KDE live as adupe of 850775 since it's more generic 17:09:23 ran into this, it's fixed. 17:09:37 I think anyone with a ipv6 enabled radvd network would hit it. 17:10:40 proposed #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" 17:11:09 this is an installer error, isn't it? 17:11:18 so it'd have to be one of the anaconda criteria 17:11:22 http/ftp package source, maybe 17:11:27 it bombs out right as it starts the main hub thing... 17:11:41 when it's activating network I guess. 17:12:11 ah, I misunderstood 17:12:26 proposed #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installer must be able to use at least one of the HTTP or FTP remote package source options" 17:12:41 sure. ack 17:13:28 ack 17:14:16 ack 17:14:23 #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installer must be able to use at least one of the HTTP or FTP remote package source options" 17:14:33 #topic (849990) Apper: Authentization failed when trying to install updates 17:14:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=849990 17:14:37 Bug 849990: unspecified, unspecified, ---, rdieter, ASSIGNED , Apper: Authentization failed when trying to install updates 17:14:38 #info Proposed Blockers, ASSIGNED 17:15:22 * tflink wonders if this will affect pk in gnome as well 17:15:54 * jreznik has to recheck this one... but maybe releated to that polkitd bug? 17:16:33 proposed #agreed 849990 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following criteria for KDE systems: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" 17:16:46 * nirik could try in Xfce real quick. ;) 17:16:54 ack 17:17:00 ack 17:17:10 ack 17:17:12 #agreed 849990 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following criteria for KDE systems: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" 17:17:17 ack 17:17:26 OK, that's all of the proposed blockers 17:17:29 mkrizek: just to verify, this is from a clean install, not an upgrade? 17:17:39 adamw: yes 17:17:41 ok. 17:17:57 jreznik: it's not related to the polkit-not-running bug, then - see comment #7, polkit is running and the user exists. 17:18:27 any objection to doing the single proposed NTH? 17:18:36 adamw: ah, I'll take a look on this one 17:19:18 * tflink takes that as a 'no' 17:19:22 #topic (847548) kernel BUG at include/linux/scatterlist.h:67 (vp_set / virtscsi_init / virtscsi_complete_free) kernel panics when virtio-scsi module is loaded 17:19:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=847548 17:19:26 Bug 847548: unspecified, unspecified, ---, kernel-maint, MODIFIED , kernel BUG at include/linux/scatterlist.h:67 (vp_set / virtscsi_init / virtscsi_complete_free) kernel panics when virtio-scsi module is loaded 17:19:27 #info Proposed NTH, MODIFIED 17:21:04 there's a rationale in comment #11... 17:21:27 * tflink is a little hesitant to take a new kernel build 17:21:54 if this only hits virtio-scsi, couldn't you switch the virtio driver to something else to work around this or am I misunderstanding the bug? 17:22:21 tflink: we already accepted 849244 as nth so we're getting a new kernel anyhow 17:22:48 aiui, this bug exists in that new kernel and the nth proposal was made so we could avoid that regression... 17:23:28 * adamw pinged jwb to see if he can help 17:24:00 hi 17:24:03 hi jwb 17:24:16 so we're just trying to get our heads around the current status wrt kernel... 17:24:44 do you want to do a one-by-one bug recount, or just have me summarize? 17:24:52 summarize is probably good 17:24:52 um 17:25:11 ok here goes 17:25:35 it is the case that you've just been finding regressions in the build that we were going to pull in to add secureboot support, and fixing those, more or less? 17:25:48 yes, essentially 17:26:03 so if we take this as NTH and pull the latest build, we'll get something *more reliable* than we'd get if we just pulled the earliest build that has the SB support? 17:26:05 i've edited the update with the latest build. it fixes the bugs listed, plus a CVE in the network stack 17:26:25 i'm fine with accepting this as NTH and taking the most recent build, if all the changes have been stabilization/bugfix, i think 17:26:26 yes, that is what I believe 17:26:28 ok 17:26:35 so our options are to not take the SB capable kernel as NTH or take the regression fixes as NTH? 17:26:48 wait, the SB-capable kernel is already in stable, isn't it? 17:26:53 tflink, no 17:27:02 https://admin.fedoraproject.org/updates/kernel-3.6.0-0.rc2.git2.1.fc18,grub2-2.00-5.fc18,pesign-0.10-4.fc18 is the update 17:27:14 it never got pushed stable yet; it's had updated builds edited in several times 17:27:20 adamw, correct. i edited it this morning to include the newer kernel 17:27:37 now 17:27:39 tflink: we *could* choose to ask jwb to cancel the update and re-submit it with an older build, that only has the SB stuff. but i don't see much value in that 17:27:49 we aren't pushing anything to stable except karmaed /accepted blockers. ;) 17:28:05 we're definitely going to be slipping, so effectively we're a week from go/no-go, so i think it's okay to take at this point... 17:28:53 OK, I can follow the logic but I think that my counter argument still holds somewhat 17:28:57 to take, you mean? 17:29:01 IIRC, this is a non-default virt setup. 17:29:22 so let's see, right now the kernel we have in 'stable' is kernel-3.6.0-0.rc1.git6.1.fc18.x86_64.rpm 17:29:31 I'm not sure that this particular bug is well qualified to be NTH and it also sounds like there are more fixes being included beyond the SB stuff 17:30:00 if I'm being overly pedantic, I'll back down though 17:30:08 the kernel currently in the update is kernel-3.6.0-0.rc2.git2.1.fc18 . which bumps to a new upstream rc, adds SB support, and fixes several specific regressions that were found in testing. 17:30:48 i don't think we have really solid testing of any point between those two kernels, so i can't see an argument for taking one of the midpoints 17:31:00 i think we either go with the current 'stable' kernel or we take the latest update 17:31:03 as I already said - I'd like to see SB as soon as possible in fedora... to avoid surprises... 17:31:48 I just don't like taking what I see as a non-NTH bug as NTH so that we can get other features 17:31:50 we usually ask for minimal possible changes for NTH stuff, but it seems silly to intentionally refuse to take tested fixes for identified regressions. 17:31:53 but I'm not going to fight it 17:31:54 tflink: yeah, the process kinda sucks. 17:32:04 let's see if any of the other bugs referenced in the update make better candidates. 17:32:38 https://bugzilla.redhat.com/show_bug.cgi?id=850003 ? 17:32:42 that's a bare metal crash on boot. 17:33:27 the other thing we can do is simply reject this as NTH, but take the latest build as the fix for 849244, which is already accepted NTH. so long as no-one complains. =) 17:34:27 either way, I'm not sure it's worth arguing about for too much longer 17:34:36 * tflink is tempted to say just take it based on the already NTH bug 17:34:43 * nirik is fine with taking the latest, given we are likely not go... but meh 17:34:50 okay. i guess the proper thing to do is just to evaluate this bug on its merits, really 17:35:14 * tflink is still -1 NTH on this particular bug unless I'm missing something 17:35:28 virtio-scsi isn't the default IO bus, is it? 17:35:31 yeah...i guess if we just go by the proper process and look at the merits of this bug, i'm -1 17:35:43 it seems like fixing it with an update would be adequate 17:36:20 unless you install w/ the affected kernel, in which case the VM install is hosed 17:36:55 sure, it's easy enough to avoid that if you document it though. why are you arguing against me now? =) 17:37:23 my rationale behind arguing against NTH is that it's a non-default VM setup 17:37:34 I just wanted to make sure that I was right about the non-default part 17:39:04 proposed #agreed 847548 - RejectedNTH - This bug requires a non-default VM setup in order to manifest and thus not qualified as alpha NTH. 17:39:08 ack/nak/patch? 17:39:15 tflink: ack 17:39:22 ARGH... 17:39:27 there was a netsplit or something here 17:39:33 i missed a bunch of stuff i think 17:39:35 jwb: yep, netsplit 17:39:44 jwb: you missed a bunch of process wankery. 17:39:54 :) 17:39:55 yeah, that sums it up pretty well 17:39:55 what was the last thing you saw from me? 17:39:59 ack 17:40:10 jwb: "now" 17:40:16 jwb: [19:37] <-- jwb has left this server (*.net *.split). 17:40:33 http://www.fpaste.org/ZUtO/ 17:40:40 that's what i was mumbling to myself then 17:40:50 jwb: we decided the proper thing to do is just to evaluate this specific bug on its nth merits, and we're -1 on that, but we will still likely pull in the latest build and just say we're doing it for 849244, or 850003 (which i just nominated) 17:41:07 adamw, ok, works for me 17:41:27 tflink: i just nominated 850003, so add that to the list =) 17:42:49 #agreed 847548 - RejectedNTH - This bug requires a non-default VM setup in order to manifest and thus not qualified as alpha NTH. 17:43:00 #topic (850003) One machine is crashing when running kernel-PAE-3.6.0-0.rc2.git0.1.fc18.i686 but not kernel-PAE-3.6.0-0.rc1.git0.2.fc18.i686 17:43:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=850003 17:43:05 Bug 850003: unspecified, unspecified, ---, kernel-maint, MODIFIED , One machine is crashing when running kernel-PAE-3.6.0-0.rc2.git0.1.fc18.i686 but not kernel-PAE-3.6.0-0.rc1.git0.2.fc18.i686 17:43:06 #info Proposed NTH, MODIFIED 17:43:37 * tflink just noticed buggbot's name change 17:45:00 +1 NTH 17:45:21 +1 nth here too 17:45:21 +1 nth, bare metal crashing on boot is bad. 17:45:30 those cards aren't hideously obscure either, there are quite a few knocking around. 17:47:31 proposed #agreed 850003 - AcceptedBlocker - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't too obscure, accepted as NTH 17:47:48 if the fix for that is what i think it is, it has little to do with the card 17:47:50 adamw: it sounds like there are other cards than the rv280, no? 17:48:05 jwb: ah, okay. 17:48:12 the oops is in the network stack 17:48:43 so what is the trigger for the crash? 17:48:47 something to do with ipv6? 17:49:48 believe so 17:52:31 common enough to be a blocker? 17:52:42 or are we OK with NTH? 17:52:51 eh, nth is fine in practice. 17:53:12 proposed #agreed 850003 - AcceptedBlocker - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected. 17:53:16 ack/nak/patch? 17:53:35 what does patch mean? 17:53:58 if you have a suggested change for the #agreed statement 17:54:16 in practice nak and patch tend to go hand in hand, though 17:54:46 oh. i would have said NTH. bruno is the only report of this, but that's probably related to it only in koji 17:55:11 oh, my mistake 17:55:12 thanks 17:55:22 ack 17:55:23 proposed #agreed 850003 - AcceptedNTH - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected. 17:55:27 er, ack for nth 17:55:44 I was about to say "we are voting on NTH" until I read what I actually typed :) 17:56:41 any other votes? 17:57:29 ack 17:57:47 * tflink thinks we scared almost everyone away with process 17:58:34 well, 2 acks is going to have to be enough I suppose. can always undo later 17:58:44 #agreed 850003 - AcceptedNTH - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected. 17:58:55 long process :) 17:58:58 time for some accepted blockers 17:59:09 * jreznik is getting hungry :) 17:59:27 jreznik: yeah but some of it is protection against "well, you took that one as NTH/blocker, why not this one?" 17:59:43 and wanting to avoid "because we said so" responses 17:59:58 #topic (847693) repoclosure failure on 18 Alpha TC2 DVDs (pion-net) 17:59:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=847693 17:59:59 #info Accepted Blockers, ON_QA 18:00:00 Bug 847693: unspecified, unspecified, ---, jvcelak, ON_QA , repoclosure failure on 18 Alpha TC3 DVDs (pion-net) 18:00:35 there's an update for this, just needs karma and pulling into tc4. 18:01:04 #info an update is available that should fix this bug, it needs karma and to be pulled in to tc4 18:01:53 #topic (847694) repoclosure failure on 18 Alpha TC2 DVDs (shotwell) 18:01:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=847694 18:01:53 #info Accepted Blockers, NEW 18:01:55 Bug 847694: unspecified, unspecified, ---, mclasen, NEW , repoclosure failure on 18 Alpha TC2 DVDs (shotwell) 18:02:05 ditto for this one, now. (yay) 18:02:17 I think we can remove this as a blocker since shotwell isn't in >=TC3, right? 18:02:44 or do we have a new update that's not referenced in the bug? 18:03:46 https://admin.fedoraproject.org/updates/FEDORA-2012-12406/shotwell-0.12.3-5.fc18 18:03:46 we do have a new update that claims to fix the issue 18:03:56 #link https://admin.fedoraproject.org/updates/FEDORA-2012-12406/shotwell-0.12.3-5.fc18 18:04:07 yeah, we basically have two bugs on shotwell, forgot about that 18:04:24 this one got mass-approved with all the other repoclosure bugs andre filed, but we could really just close it as a dupe of 844510 18:04:26 not sure I follow you here 18:04:28 shall we do that for clarity? 18:04:37 yeah, that makes sense to me 18:04:38 847694 really doesn't tell us anything that 844510 didn't. 18:04:53 #undo 18:04:53 Removing item from minutes: 18:05:52 #info This bug doesn't tell us anything that #844510 doesn't already say and there is an update available to fix that bug. Closing as dupe of #844510 18:06:33 #topic (847683) repoclosure failure on 18 Alpha TC3 DVDs (fatrat) 18:06:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=847683 18:06:34 #info Accepted Blockers, ON_QA 18:06:35 Bug 847683: unspecified, unspecified, ---, jvcelak, ON_QA , repoclosure failure on 18 Alpha TC3 DVDs (fatrat) 18:07:12 #info an update is available which claims to fix this issue - it needs testing and karma before being pulled into F18 alpha TC4 18:07:30 it's busted 18:07:32 see my comment on the update 18:07:40 so we can't pull it for now. but jvcelak is aware. 18:07:55 ot 18:08:02 it's been unpushed 18:08:19 brb call of nature 18:08:25 #undo 18:08:25 Removing item from minutes: 18:08:52 #info update was submitted to fix this bug but didn't actually fix it. Update has been unpushed, still waiting for fix. 18:09:05 #topic (848641) Fedora 18 Alpha TC2 fails to boot from USB stick (written by livecd-iso-to-disk) 18:09:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=848641 18:09:10 Bug 848641: high, unspecified, ---, anaconda-maint-list, NEW , Fedora 18 Alpha TC2 fails to boot from USB stick (written by livecd-iso-to-disk) 18:09:11 #info Accepted Blockers, NEW 18:10:28 #info Some progress has been made, anaconda-dracut is currently suspected as being the problem. Waiting for more analysis and hopefully a fix since none of the supported USB media creation methods are currently working. 18:12:09 * tflink waits for adam to come back to make sure I didn't miss anything 18:13:30 nothing new from me 18:14:38 ok, moving on 18:14:50 #topic (848803) Root password is not set due to missing authconfig 18:14:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=848803 18:14:50 #info Accepted Blockers, MODIFIED 18:14:53 Bug 848803: urgent, unspecified, ---, anaconda-maint-list, MODIFIED , Root password is not set due to missing authconfig 18:15:30 it sounds like this should be ON_QA and needs verification 18:15:47 it actually got closed, then re-opened by dan, probably incorrectly 18:16:05 to be certain we should test a kickstart install that specifies a root password and see what happens, then re-close if it works 18:16:30 #info This should be fixed, kickstart install needs verification that root password is set correctly before closing 18:17:12 #topic (844510) FTBFS in Rawhide with gphoto 2.5.0 18:17:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=844510 18:17:12 #info Accepted Blockers, ON_QA 18:17:35 so yeah, there's an update, needs karma. worked fine for me. 18:17:46 Bug 844510: urgent, unspecified, ---, mclasen, ON_QA , FTBFS in Rawhide with gphoto 2.5.0 18:17:47 #info FTBFS issue has been fixed and an update is available. Needs karma before it's pulled in to TC4 18:18:07 #topic (849118) firstboot doesn't show up in LXDE 18:18:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=849118 18:18:07 #info Accepted Blockers, POST 18:18:09 Bug 849118: unspecified, unspecified, ---, vpodzime, POST , firstboot doesn't run, partly due to use of python-meh which has been ported to GTK+ 3 18:18:58 so there's a patch posted for this too, waiting for review. not much we can do. 18:19:42 #info patch for anaconda has been posted, waiting for review. 18:19:57 #topic (840179) Latest grub2 update broke "system" theme 18:19:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=840179 18:19:58 #info Accepted Blockers, ON_QA 18:20:02 Bug 840179: medium, unspecified, ---, pjones, ON_QA , Latest grub2 update broke "system" theme 18:20:35 #info Fix is available, update needs karma before being pulled in to TC4 18:20:46 #topic (849012) IOError: [Errno 2] No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-p2p1' 18:20:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=849012 18:20:51 #info Accepted Blockers, MODIFIED 18:21:17 Bug 849012: unspecified, unspecified, ---, rvykydal, MODIFIED , IOError: [Errno 2] No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-p2p1' 18:21:19 #info Still waiting for patch to fix this issue 18:21:51 why's it 'modified' then? 18:21:57 looks like a partial patch 18:22:01 #undo 18:22:01 Removing item from minutes: 18:22:11 it's marked as fixed in 18.7, so i was assuming next build would get this 18:22:24 #info partial patch has been written but still waiting for more code to complete the fix 18:22:33 not entirely sure if comment #10 means the fix is incomplete or just a further improvement or what... 18:23:20 checking history 18:24:10 anyhow, not sure there's much to discuss here, anaconda team is on the case. 18:24:10 #undo 18:24:10 Removing item from minutes: 18:24:57 #info It's unclear whether or not this issue will be fully fixed with anaconda-18.7-1, will need testing when new build is available or clarification from anaconda devs 18:25:09 #topic (849152) anaconda doesn't use DVD repo 18:25:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=849152 18:25:10 #info Accepted Blockers, MODIFIED 18:25:11 Bug 849152: unspecified, unspecified, ---, clumens, MODIFIED , anaconda doesn't use DVD repo 18:25:40 #info should be fixed with anaconda-18.7-1. Will need testing and karma once a new build is available 18:26:10 #topic (849250) Not setting up a root password makes non-desktop installs impossible to access 18:26:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=849250 18:26:15 Bug 849250: urgent, unspecified, ---, anaconda-maint-list, NEW , Not setting up a root password makes non-desktop installs impossible to access 18:26:16 #info Accepted Blockers, NEW 18:26:56 doesn't sounds like there has been much movement on this 18:27:11 * tflink assumes that the anaconda devs are still discussing potential solutions 18:27:19 yeah, might be a good idea to poke them though 18:27:25 #action adamw to poke anaconda team about 849250 18:27:44 +1 18:27:52 #info There hasn't been much movement on this yet, anaconda devs may still be discussing potential solutions, will ask for update 18:28:07 #topic (849667) Bugreporting from anaconda doesn't work as expected 18:28:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=849667 18:28:07 #info Accepted Blockers, ON_QA 18:28:08 Bug 849667: unspecified, unspecified, ---, vpodzime, ON_QA , Bugreporting from anaconda doesn't work as expected 18:28:41 #info an update to python-meh should fix this, needs testing and karma before pulling into TC4 18:29:02 eh, that's not quite right 18:29:14 not sure it _can_ be verified w/o TC4 18:29:22 #undo 18:29:22 Removing item from minutes: 18:29:35 #info an update to python-meh should fix this, needs testing and karma so that it can be pushed to stable 18:29:51 #topic (849070) Anaconda's bug reporter doesn't work 18:29:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=849070 18:29:51 #info Accepted Blockers, MODIFIED 18:29:53 Bug 849070: unspecified, unspecified, ---, anaconda-maint-list, MODIFIED , Anaconda's bug reporter doesn't work 18:30:35 #info patch has been submitted to fix this issue, waiting for it to be pulled into anaconda before it can be re-tested and karma-ed 18:30:45 I think that's all of them 18:30:50 anything I missed? 18:30:55 sounds good to me 18:31:02 #topic Open Floor 18:31:05 not sure exactly how to karma python-meh, but i'll figure something out... 18:31:26 Is there anything else to bring up before ending the meeting? 18:31:40 escape plans? 18:31:57 RUN! 18:32:35 * jreznik is running 18:32:43 * tflink plans to hide out somewhere in the caribbean for the next month or so :) 18:32:53 wait, did I say that out loud? 18:33:05 ok, for go/no-go meeting? what's the process now? 18:33:17 QA is no-go 18:33:23 there are open, unaddressed blockers 18:33:53 so it'll be a short go/no-go 18:34:24 :((( sad face :((( 18:34:40 yeah, utterly no-go. 18:35:44 well in two and half hour 18:36:24 release readiness is tomorrow, no? or do I have my dates mixed up? 18:36:40 * jreznik is new 18:37:10 so how's the process? as I announced the go/no-go meeting for today (or we could skip it) and then readiness? 18:37:23 pls educate me :) firt time, shy... 18:37:35 IIRC, release readiness is held after the first go/no-go regardless of the state of the release 18:37:54 to see where everyone is regarding the relese (docs etc.) 18:38:13 but its only held once, not before every go/no-go 18:38:20 s/before/after 18:39:01 so today go/no-go and if no-go, readiness is postponed? 18:39:24 nope, readiness is held regardless of the results of go/no-go 18:39:31 as far as I remember, anyways 18:39:34 sorry, too late here 18:39:38 no worries 18:40:28 but for go/no-go we will meet today? is it true? 18:40:32 yes 18:40:40 ok :) 18:41:05 thanks (I wanted to talk to rbergeron before Board mtg but seems she's not available) 18:41:27 yeah, she knows the process better than I do :) 18:41:50 she was here at first, said something about having a unreliable internet connection 18:42:04 tflink: I have the same problem today... 18:42:22 fun times :) 18:42:42 well, so see qa with the verdict in two hours 18:42:54 yep 18:43:09 anyhow, I think that we're done here 18:43:18 * tflink sets the fuse for [0,5] minutes 18:46:44 #info f18 alpha blocker review meeting #5 will be on 2012-08-29 @ 16:00 UTC if alpha slips 18:46:58 * tflink will send out minutes shortly 18:47:03 Thanks for coming, everyone 18:47:06 #endmeeting