17:01:20 <jreznik> #startmeeting F18 Final Go/No-Go meeting
17:01:20 <zodbot> Meeting started Thu Jan  3 17:01:20 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:31 * nirik waves.
17:01:34 <jreznik> #meetingname F18 Final Go/No-Go meeting
17:01:34 <zodbot> The meeting name has been set to 'f18_final_go/no-go_meeting'
17:01:48 <Martix> .fas Martix
17:01:48 <jreznik> #topic Roll Call
17:01:49 <zodbot> Martix: martix 'Martin Holec' <martix.cz@gmail.com>
17:01:58 <jreznik> now it's time to wave!
17:02:23 * nirik does the wave
17:02:25 <tuanta> .fas tuanta
17:02:25 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
17:02:37 <drago01_> .
17:02:58 * Martix is blocking
17:03:15 * satellit listening
17:04:16 <jreznik> let's wait a moment for more people to come
17:05:54 <nirik> sure
17:07:00 <jreznik> #topic Purpose of this meeting
17:07:16 <jreznik> #info Purpose of this meeting is to see whether or not F18 Final is ready for shipment, according to the release criteria.
17:07:23 <jreznik> #info This is determined in a few ways:
17:07:30 <jreznik> #info No remaining blocker bugs
17:07:33 * rbergeron pops in
17:07:37 <jreznik> #info Test matrices for Final are fully completed
17:07:44 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist
17:07:49 <jreznik> #link http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:07:55 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Current_Base_Test
17:08:00 <jreznik> #link http://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
17:08:05 * nirik runs to get more coffee.
17:08:05 <jreznik> #link http://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
17:08:59 <jreznik> #topic agenda
17:09:11 * satellit dd usb x86_64 and EFI are OK TC4
17:10:29 <jreznik> for agenda - as we are very unlikely to say Go today, I'd say quick status update + review of currently accepted blocker bugs (with keymaps mess) is something we should do today
17:10:35 <jreznik> any objections or ideas?
17:11:27 <adamw> fine by me
17:12:04 * rbergeron thinks that works
17:12:24 * jreznik wanted to hear - NOOO, WE WANT A RELEASE :)
17:12:28 <jreznik> but let's start
17:12:40 <jreznik> #topic current status
17:13:44 <jreznik> #info Fedora 18 Final Test Compose (TC4) is available, no release candidate (RC) yet
17:14:56 <jreznik> #info currently 7 blocker bugs are unresolved (not in ON_QA/VERIFIED/CLOSED state) based on accepted blocker bug list
17:15:37 <jreznik> #info 3 proposed blockers (minus the KDE tracking one)
17:16:21 <jreznik> anyone else to add something to the status?
17:17:22 <adamw> not really. some of the blockers are very low-hanging fruit at this point, but still need a re-spin at minimum
17:17:41 <jreznik> adamw: yep
17:17:56 <jreznik> #topic "mini" review of accepted/proposed blocker bugs
17:18:21 <jreznik> adamw: do you want to take care of QA part as tflink is not here, or I can do it
17:19:15 <adamw> sure
17:19:19 <adamw> did you throw a chair at me?
17:19:26 <jreznik> sure
17:19:30 <jreznik> #chair adamw
17:19:30 <zodbot> Current chairs: adamw jreznik
17:20:18 <adamw> diving right in...
17:20:20 <adamw> #topic (891443) crash when reusing existing Btrfs volume
17:20:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=891443
17:20:20 <adamw> #info Proposed Blocker, anaconda, NEW
17:21:21 <adamw> uf, more btrfs subvol stuff. on the face of it, i'd have to vote +1
17:21:56 <nirik> yeah, sadly so I guess.
17:22:03 <jreznik> do we have enough people here to vote or we want to do more the status update?
17:22:15 <jreznik> anyone tried to reproduce it?
17:22:31 <adamw> not yet, it's fairly new, but the methodology seems reasonably sound
17:22:39 <adamw> sure, if we don't have many people we could just give an indication.
17:22:41 <jreznik> but reuse is really bad one
17:23:11 <adamw> note it's reusing a _volume_ not a subvol
17:23:26 <adamw> kinda like creating new LVs within an existing VG i guess
17:23:51 <nirik> right, and folks could well want to reuse their old /home subvolume...
17:24:29 <jreznik> and for that recreating is not an option without the need to backup it
17:26:07 <jreznik> based on release criteria, seems like +1 for me
17:26:22 <adamw> ok
17:26:28 <adamw> since we don't have great representation:
17:26:28 <rbergeron> are we considering btrfs to be "most commonly-used" - i assume so at this point, but wasn't sure if we actually have a list
17:26:42 <adamw> rbergeron: yeah, btrfs is supposed to be pretty well-supported at this point.
17:26:53 <nirik> well, I think we are considering it well supported... yeah.
17:26:55 <adamw> hell, we've been going to make it the default for every one of the last few releases...:)
17:27:06 <rbergeron> adamw: and then we keep not doing so ;) lol
17:27:24 <rbergeron> okay, just checking. supported/used are slightly different meanings
17:27:47 <adamw> well, we have me for QA, jreznik for devel, nirik for releng and rberge for Management, so we have a 'quorum' for blocker decisions
17:27:49 <adamw> can always be reversed later
17:27:50 <adamw> so:
17:28:20 <rbergeron> but it seems that it gets more than enough use to be a +1 IMO
17:28:44 <adamw> propose #agreed 891443 is accepted as a blocker per criterion "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
17:28:53 <rbergeron> ack
17:28:55 <nirik> ack
17:29:24 <jreznik> rbergeron: as far as I know, brtfs is quite common/supported - on the other hand sometimes I'm not sure we can support such huge scope of technologies that makes me worry...
17:29:25 <jreznik> ack
17:30:01 <adamw> #agreed 891443 is accepted as a blocker per criterion "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
17:30:12 <adamw> #topic (881624) U.S. keyboard layout used for encryption passphrase entry during fedup second phase
17:30:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
17:30:12 <adamw> #info Proposed Blocker, fedup, NEW
17:30:24 <adamw> so here's one of our mess o' keymap bugs
17:30:29 <rbergeron> HOORAY LANGUAGES
17:30:31 * nirik nods sadly.
17:30:47 <adamw> i haven't actually confirmed this one because i can't get upgrades of encrypted installs to really work _at all_, but i'm not at all surprised if it's broken
17:31:35 <jreznik> it's more generic keymap mess we should somehow solve... and the question is - what we are able to fix in timely manner for F18?
17:31:35 <adamw> so the alleged issue here is that, if you have a non-US keymap set in your F17 install, then you try and upgrade to F18 with fedup, the keymap used during the second stage of upgrade - where the system reboots and performs the upgrade in dracut - is US
17:31:45 <adamw> this one isn't very generic really
17:32:30 <adamw> if you have encrypted partitions, you might well be expecting to enter the passphrase in your native keymap, not US, and not be able to unlock them and not know what's going on. at least theoretically the passphrase might contain a character you can't enter on a US keymap, in which case you're kind of boned (though there's probably a cmdline parameter you can use or something)
17:32:53 <adamw> this is definitely documentable, and given the general consensus in favour of Just Get The Damn Thing Done in the ML thread, maybe we want to go -1
17:33:25 <nirik> so, as a workaround you could edit the upgrade kernel boot line and add a vconsole=therightthing?
17:34:21 <adamw> nirik: yeah, i'm thinking.
17:35:00 <nirik> and possibly fedup could fix this in a update?
17:35:01 <adamw> like i said, i need to do more of my own testing to confirm this one (every time I tried before, I couldn't get an upgrade to complete or get a clear indication of whether my unlock had actually succeeded when i typed the passphrase with either US or native layout)
17:35:06 <adamw> also possible.
17:35:13 * nirik is a tenative -1 then.
17:35:58 * jreznik is with nirik, -1 - document it and try to fix it by update
17:36:12 <rbergeron> how would fedup fix it in an update if they ... can't ... install?
17:36:16 <drago01_> +1 block and fix properly
17:36:38 <rbergeron> or is this a "update it because you download it befor eyou upgrade" thing
17:36:39 <nirik> rbergeron: it's on upgrades...
17:36:43 <nirik> yeah.
17:36:45 <rbergeron> yeah, i just thought through that
17:36:48 <rbergeron> never mind
17:36:53 * rbergeron drinks more caffeine
17:36:59 <nirik> so at the time you run fedup, you get the newest f17 fedup and the newest f18 fedup-dracut...
17:37:06 <drago01_> scenario: user has encrypted disk ... upgrades can no longer access his/her data
17:37:10 <drago01_> an update that fixes it
17:37:13 <drago01_> is useless
17:37:24 <jreznik> drago01_: +documented workaround
17:37:33 <drago01_> I can't see how this can even be considered to be not a blocker
17:37:53 <drago01_> jreznik: not everyone reads docs
17:37:56 <rbergeron> I guess the thing that bugs me here about it is the number of languages this actually affects
17:38:27 <rbergeron> between this and 899562
17:38:29 <rbergeron> le sigh
17:38:35 <nirik> drago01_: how would the " upgrades can no longer access his/her data" scenerio work?
17:38:56 <nirik> wouldn't it be 'tries to upgrade, can't unlock, reboots to old kernel/install and pokes around' ?
17:39:10 <adamw> right. at the point it fails, nothing irreversible has happened, i don't believe.
17:39:20 * nirik nods. thats my understanding
17:39:28 <drago01_> nirik: non ascii encryption phrase (or one with a z) + ends up with US layout
17:39:51 * nirik doesn't follow drago01_
17:39:56 <rbergeron> on the other side of the coin - i don't necessarily see "people who use encryption passphrases" as people who aren't going to have any idea how to read about solving their problem
17:40:25 <drago01_> nirik: which part exactly?
17:40:26 * rbergeron nods at the "nothing irreversible" - that's the important part
17:40:55 <drago01_> rbergeron: well in the sense of "fuck this broke lets reinstall because I can no longer unlock and/or login" it is
17:41:13 <adamw> drago01: we're talking about _during upgrade_ in this bug
17:41:15 <drago01_> rbergeron: think of users that are not on fedora-devel-list
17:41:17 <adamw> not _after a successful upgrade_
17:41:19 <drago01_> (yes those do exist)
17:41:34 <nirik> drago01_: say you have a chinese f17. You install fedup, you run it, you reboot in the upgrader. You cannot enter your passphrase. You scratch your head and reboot to f17 and seach the net...
17:41:45 <adamw> after a successful upgrade, console keymap config does in fact appear to work, fwiw.
17:42:02 <drago01_> adamw: huh?
17:42:20 <jreznik> ah, well - then I'm really -1 if it works after successful update
17:42:21 <adamw> drago01: we're talking about the second stage of fedup, the bit that actually does the upgrade.
17:42:33 <rbergeron> adamw: is NTH on the table here?
17:42:37 <adamw> obviously it needs you to enter your encryption passphrase if your system partitions are encrypted.
17:42:46 <adamw> otherwise it can't access the stuff it's supposed to upgrade.
17:42:59 <nirik> rbergeron: I suppose so, but really at this poitn I would think we should be very carefull with NTHs
17:43:43 <drago01_> adamw: https://bugzilla.redhat.com/show_bug.cgi?id=881624#c12 ok
17:43:43 <nirik> anyhow, do we have enough votes?
17:43:44 <adamw> if you have an encrypted partition, once the first stage of fedup is done downloading RPMs and configuring grub, the system reboots, and a special-case 'upgrade' boot starts. this is the boot that will perform the upgrade. it pops up a box in which you have to enter your passphrase, for the actual upgrade process to proceed. *this is the point we are talking about*
17:43:48 <drago01_> adamw: but "The login shell and gnome desktop uses US Keyboard" is broken too
17:44:02 <adamw> drago01: that's https://bugzilla.redhat.com/show_bug.cgi?id=889699
17:44:10 <adamw> (sorry, i confused that a bit last night, but i tried to straighten it out)
17:44:33 <adamw> this bug is concerned only with the specific point i mentioned above
17:44:34 <drago01_> adamw: ok
17:44:48 <adamw> rbergeron: i'm not sure NTH makes a huge pile of sense if the fix would be in fedup
17:44:54 <drago01_> ok +0 then on this one
17:44:56 <adamw> we could consider NTH later, anyways
17:44:59 <rbergeron> adamw: yeah
17:45:10 <adamw> given the general tenor of the devel@ thread i'm gonna vote -1 blocker, though it does kinda suck.
17:45:12 <jreznik> ok, so how many votes do we have?
17:45:14 * rbergeron may have been confused as well
17:45:19 <jreznik> -1 blocker
17:45:36 <rbergeron> but I just read through all those language/keyboardy tickets :)
17:45:40 <Martix> I hit LUKS keymap not before, but after upgrade...weird
17:45:48 * jreznik was definitely confused, thanks for great explanation for dumbme :)
17:46:03 <Martix> and .vconsole= magic didn't worked
17:46:45 <adamw> rbergeron: it's a thicket, i know :/
17:47:25 <adamw> propose #agreed taking into consideration the general tenor of the wider devel@ discussion, the fact that this is likely documentable and workaroundable and that it could well be fixed with an update to f17's fedup, 881624 is rejected as a blocker
17:47:30 * jreznik read all bugs several times...
17:47:34 <nirik> ack
17:47:36 <jreznik> ack
17:48:14 <adamw> \#agreed taking into consideration the general tenor of the wider devel@ discussion, the fact that this is likely documentable and workaroundable and that it could well be fixed with an update to f17's fedup, 881624 is rejected as a blocker
17:48:16 <adamw> #agreed taking into consideration the general tenor of the wider devel@ discussion, the fact that this is likely documentable and workaroundable and that it could well be fixed with an update to f17's fedup, 881624 is rejected as a blocker
17:48:35 <adamw> the whole area of keyboard configuration is just wonderfully, incredibly, impressively messy and over-complex in all sorts of ways.
17:48:43 <adamw> (and genuinely complex even if you prune the over-complexity).
17:48:47 <adamw> we didn't even get into keysyms yet!
17:49:00 <adamw> skipping the kde tracker...
17:49:01 <adamw> #topic (889699) systemd drops X11 keyboard layout settings during upgrade
17:49:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=889699
17:49:01 <adamw> #info Proposed Blocker, systemd, ASSIGNED
17:49:20 <adamw> okay, so here's the one for 'after upgrade, you go back to U.S. keyboard for gdm and GNOME'
17:49:21 * jreznik does not understand how adamw survived all that investigation without commiting suicide
17:49:35 <adamw> i used McAfee's revovler
17:49:49 <rbergeron> s/revolver/crackpipe?
17:50:02 <rbergeron> ;)
17:50:05 <adamw> heh
17:50:24 <adamw> so i think actually in gdm, your real keyboard is still available in the list, it's just not the default any more
17:50:30 <adamw> there is a layout chooser at top-right in gdm
17:50:38 <adamw> I _think_. I may be misremembering. I did a lot of testing last night. and crack.
17:50:55 <adamw> in GNOME you get this insane 'Bambara' bug, but it's easy enough to just go into the control center and add back whatever layout you want.
17:51:01 <nirik> so, how sure are we this is a systemd bug? and whats the chances of a fix in 2013? ;)
17:51:35 <adamw> well, it's systemd's %post that tries to manage the current migration, so seems logical.
17:51:51 <drago01_> adamw: when I upgraded a few days ago to test the new fedup build my german layout got ignored and I ended up with US
17:52:00 <drago01_> no selector iirc
17:52:30 <adamw> i didn't look closely at how the pre-upgrade config actually *works* - it seems like there was an expectation there'd be a /etc/X11/xorg.conf.d/00-blah.conf file after an F17 install, defining the default X11 keymap, just as there is after a default F18 install, but I don't think there actually is. didn't look into it beyond that.
17:52:43 <adamw> drago01: i always test with French, so it could vary between languages somehow...
17:53:52 <rbergeron> does this affect *everyone* ?
17:53:54 * nirik looks at systemd --scripts. man, thats pretty long.
17:54:08 <rbergeron> by everyone i mean "non-us-folks, because the us folks magically get hte right choice by default"
17:54:11 <rbergeron> ;)
17:54:17 <rbergeron> non-us-keyboards
17:54:46 <adamw> rbergeron: not like we've tested every layout, but i'm pretty sure it does
17:55:16 <adamw> i don't think it's some kind of layout-specific bug, i think there's just not whatever needs to be in place to actually transfer the X and GNOME configs
17:55:24 * jreznik uses us-keyboard as default one, so he's not a good sample
17:56:03 <nirik> so, if this happens, what is the workaround? you have to go into control center and find your right keyboard and set it? or gdm and set it there?
17:56:20 <adamw> yes and yes...
17:56:21 <jreznik> it depends if selector is available or not
17:56:39 <jreznik> drago01_ says there's no selector, adamw says there is
17:56:43 <adamw> i probably should re-test this really as it sounds like my memory is foggy
17:56:49 <nirik> right, it could vary
17:56:56 <adamw> but for sure, gdm and GNOME are really different cases
17:56:57 * rbergeron sighs - it feels like we're going to have people having to manually fix things to go back to their languages/switch keyboards/hope that their crap is even translated a lot
17:56:59 <adamw> they do not use the same configuration
17:57:13 <adamw> rbergeron: yes, that's pretty much the big picture.
17:57:27 * nirik is on the fence on this one. I guess I am a weak +1, and hope it can quickly be fixed
17:58:54 * drago01_ is no longer in charge of dealing with this stuff ... systemd took over ;)
17:58:55 * jreznik is pinging lennart if it's systemd issue or not
17:59:59 <nirik> jreznik: he was replying to the devel list, so in theory he's on line. We could ask him to come here?
18:00:02 <drago01_> adamw: ot but can we get the criteria about this one in to stop having this kind of discussions every time (for each release)
18:00:15 <dingtav> can just fedup be delayed and F18 released without it, users who aren't upgrading can use F18 immediately, upgraders wait a little?
18:00:23 <adamw> drago01: we'd have to kick that around after f18. it's a *really* complex thing to quantify.
18:00:42 <adamw> dingtav: in theory yeah, in practice it'd be difficult. for one thing, it's already in the f17 repos.
18:00:46 <adamw> we can always massage the message.
18:01:20 <adamw> i don't see lennart on irc (under any of his nicks here or on gimpnet)
18:01:29 * nirik thinks overall fedup is an improvement over preupgrade, it's just new and has corner issues. ;)
18:01:36 <rbergeron> okay, do we have a proposal on this one, in light of no-lennart-for-the-momento
18:01:45 <jreznik> adamw: poettering in #systemd
18:01:46 <drago01_> nirik: this isn't fedup's fault
18:01:58 <adamw> kmacleod: y'know, I always want to know if you're _the_ Ken MacLeod...
18:02:06 <nirik> drago01_: that was for dingtav. I know this isn't.
18:02:11 <kmacleod> well yes, of course I am ;)
18:02:27 <kmacleod> adamw, but not the one you're thinking of ;)
18:02:28 <drago01_> adamw: he is on gimpnet
18:02:38 <adamw> drago01: oh, missed him. if you could get him in here it'd be great
18:02:48 <adamw> kmacleod: aw, well, you should know you've disappointed me terribly. :P
18:03:24 <kmacleod> now, if you've ever done XML in Perl, you might have seen my work ;)
18:03:45 <adamw> perl! *hisssssssss*
18:03:46 * drago01_ pinged him
18:04:23 <kmacleod> I've long since moved to Python, natch
18:05:24 <jreznik> [19:00] * poettering has a look (from #systemd channel)
18:05:25 <dingtav> nirik: no objections that fedup > preupgrade; just questioning the release criterion that upgrades must work :)
18:05:55 <adamw> hi poettering
18:06:06 <poettering> hi
18:06:16 <poettering> just commented on https://bugzilla.redhat.com/show_bug.cgi?id=889699
18:06:20 * nirik waves.
18:06:21 <adamw> thanks, reading
18:07:15 <adamw> poettering: so the bug is this: if you do a clean F17 French install (with French layout) and upgrade to F18 with fedup, gdm and GNOME both use a U.S. layout by default.
18:07:32 <adamw> console layout config is correctly migrated, X and GNOME layout config are not.
18:07:56 <poettering> hmm, let me read the code
18:08:02 <poettering> (note that the conversion code is kay's realm
18:08:11 <poettering> need to figure out what is goin on first
18:08:12 <poettering> one moment)
18:08:16 <drago01_> that code does not seem to touch x at all?
18:08:18 <adamw> GNOME manifests that weird bug where it offers just English and 'Bambara' layouts, which no-one seems to have figured out at all.
18:08:45 <poettering> drago01_: true
18:08:53 <adamw> drago01: i _think_ the idea is either that systemd-localed should handle it - try and make the X11 layout match the console layout - or that an X config file would exist from the f17 install. neither seems to happen
18:09:05 <poettering> adamw: is the old xorg.conf.d dropin removed on upgrade?
18:09:07 <poettering> adamw: how come?
18:09:22 <adamw> poettering: i don't believe there is an xorg.conf.d file after a clean f17 install
18:09:36 <adamw> s-c-k creates one if you run it, apparently, but that doesn't seem to be what anaconda did in f17.
18:09:46 <poettering> system-setup-keyboard used to convert it from /etc/sysconfig/keyboard
18:09:49 <adamw> i'd have to re-run the f17 install to check, unfortunately, i didn't think to look at the pre-upgrade config very closely.
18:09:51 <poettering> but s-s-k is obsolete now
18:09:58 <poettering> but the file should still be there
18:10:09 <poettering> s-s-k was continouswly running to do the conversion
18:10:29 <poettering> my guess is that this is what happens:
18:10:34 <adamw> all i can tell you right now is that after upgrade there is no file at all in /etc/X11/xorg.conf.d
18:10:43 <poettering> removing s-s-k removes the old snippet and hence the config is lost
18:10:50 <adamw> oh, and gdm has no layout selector. bah.
18:11:04 <adamw> that's possible, though we don't generally nerf config files on package removal like that. but it could be.
18:11:17 <poettering> and a possible solution would be to take possession of the old file as ghost in the systemd rpm spec (so that it is owned jointly and remains installed9
18:11:29 <poettering> and then just rename it to the new name in %post
18:11:46 <adamw> i'll fire off a fresh f17 install to see what the pre-upgrade config is.
18:11:54 <drago01_> yeah that should work
18:12:07 <adamw> if that's the bug then i agree, yeah.
18:12:19 * adamw starts up new f17 install
18:13:07 <nirik> so, given all this, do we want to +1 blocker it?
18:13:33 <adamw> it's a bit more of a roadblock than i thought it was, given there's no layout selector in gdm
18:13:46 <jreznik> without selector, I'm more +1
18:13:48 <adamw> that tips me a bit more to the blocker side
18:14:26 <jreznik> as then it's worst than the previous one
18:14:42 <poettering> the fix would be really easy, just two lines in the spec file
18:14:46 * nirik is still a weak +1
18:14:48 <poettering> so i don't mind making it a blocker
18:14:51 <adamw> poettering: again, assuming the bug is as you think :)
18:14:54 <nirik> thats good news.
18:14:56 * adamw has the french install running
18:15:04 <poettering> given how iseasy given how easy the fix would be
18:15:06 <rbergeron> bonjour!
18:15:07 <poettering> (of course, only if this is actually really the problem...)
18:16:07 <rbergeron> without a selector i'm more +1ish as well
18:16:22 <adamw> propose #agreed 889699 is accepted as a blocker per criterion "...it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria." in the case of non-U.S. keymaps
18:16:30 <nirik> ack
18:16:39 <rtcm> adamw: is the "french issue", the "bambara issue" ?
18:16:59 <adamw> rtcm: kinda, but the GNOME part is less bad than the X/GDM part here
18:17:09 <poettering> adamw: oh, wait
18:17:14 <poettering> adamw: the bug is about two issues
18:17:19 <adamw> once in GNOME you can always fix up the keymap choice pretty easily, the really bad thing here is the use of U.S. layout for login via GDM
18:17:20 <poettering> adamw: i'd like to have that split
18:17:23 <adamw> poettering: ok
18:17:34 <poettering> adamw: i.e. the upgrade issue would be easy to fix in the system spec file
18:17:39 <adamw> though it may well be that GNOME derives its list of keymaps from the X config anyway
18:17:40 <poettering> adamw: no clue about the other one
18:17:45 <adamw> so once we have the X config fixed, GNOME's list would work
18:18:18 <adamw> s/list/default list/ - you can always modify it, but i'm guessing if you haven't done any manual config within GNOME, it just gives you the system-wide X keymaps to pick from
18:18:51 <rtcm> adamw: GDM in f18 does display a selector for all the layouts that the X server is configured with
18:19:19 <adamw> rtcm: it'd be great if we could pin down this weird Bambara bug, but let's chat about that separately in #gnome later or something, it's not a blocker on its own i don't think
18:19:25 <adamw> any more acks?
18:19:26 <rtcm> (it's actually not GDM, but gnome-settings-daemon that takes care of that)
18:19:26 <poettering> adamw: btw, if you test the upgrade, please write down the precise name of the old file
18:19:34 <drago01> +1 blocker
18:19:36 <poettering> adamw: as i already forgot how precisely it was called
18:19:37 <jreznik> ack
18:19:46 <adamw> poettering: will do
18:19:59 <poettering> adamw: must have been something like "00-system-setup-something.conf" or so
18:20:06 <poettering> adamw: but don't remember the precise name
18:20:07 <adamw> rtcm: ah, okay. but the problem here is that the X config is getting lost on upgrade, so the gdm selector isn't shown.
18:20:19 <poettering> drago01: you wrote s-s-k, right? so you know the old name anyway?
18:20:20 * rbergeron acks, but wasn't sure if we were acking or splitting to two issues before acking
18:20:21 <adamw> #agreed 889699 is accepted as a blocker per criterion "...it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria." in the case of non-U.S. keymaps
18:20:31 <adamw> rbergeron: i can do the doctoring later
18:20:43 <rbergeron> dr. williamson, i presume
18:20:48 <adamw> heh
18:20:58 <jreznik> rbergeron: I was waiting for spliting too but as adamw asked for ack, I could not resist
18:21:18 <adamw> okay, that's all the proposed blockers
18:21:18 <drago01> poettering: 00-system-setup-keyboard.conf iirc
18:21:28 <adamw> so we've added several to accepted blockers, and we did have some un-addressed accepted blockers before
18:21:43 <adamw> we also have no actual labelled RC build, and not 100% test coverage, so the go/no-go decision is unfortunately pretty clear...
18:22:11 <jreznik> still let's go through the rest of accepted blocker - a quick status update/summary
18:22:23 <drago01> poettering: and it just does %ghost %{_sysconfdir}/X11/xorg.conf.d/00-system-setup-keyboard.conf
18:22:27 <drago01> poettering: in the spec file
18:23:26 <drago01> adamw: question is can we take advantage of the new "must not release on tuesday" thing?
18:23:31 <drago01> adamw: i.e < week slip
18:24:02 <adamw> drago01: okay.
18:24:03 <nirik> right, thats the next question after we decide nogo
18:24:20 <adamw> oh, there's a new < week slip thing? okay.
18:24:24 <jreznik> yep, but first - let's do a quick status review of the rest of unresolved accepted blockers
18:24:28 <adamw> #topic (888089) ValueError: A RAID0 set requires at least 2 members
18:24:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=888089
18:24:28 <adamw> #info Accepted Blocker, anaconda, POST
18:24:29 * j_dulaney would have assumed no go already would have been decided ...
18:25:25 <jreznik> the patch was "lost"
18:25:50 <adamw> per IRC discussion yesterday this just needs cherrypicking from master for a new anaconda build, iirc
18:25:52 <jreznik> and it's now MODIFIED
18:25:57 <poettering> drago01: ah, cool, that's the line we should add to systemd too then
18:26:13 <jreznik> dlehman already did it
18:26:18 <adamw> cool.
18:26:20 <nirik> great
18:26:29 <adamw> so then we're just waiting o na new anaconda build compose and re-test cycle, no action required
18:26:36 <nirik> next!
18:26:48 <jreznik> yep, next
18:26:51 <adamw> #info this is now committed and awaiting a new anaconda build / compose / test cycle
18:26:56 <adamw> #topic (832510) vnc server starts before the network
18:26:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=832510
18:26:57 <adamw> #info Accepted Blocker, anaconda, NEW
18:27:29 <adamw> so looks like david woodhouse added some useful info here
18:27:35 <adamw> and we need to get a new dev
18:27:39 <jreznik> radek is on pto
18:27:40 <adamw> how's that going, jaro?
18:27:48 <jreznik> bcl promised to take a look
18:28:37 <jreznik> today, just asking for an update
18:29:22 <jreznik> #info developer (rvykydal) is on PTO this week, bcl is trying to take a look on the issue
18:29:30 <adamw> ok
18:29:38 <adamw> #topic (877658) [i18n] some storage-related error messages not marked for translation: "Not enough free space on disks for automatic partitioning"
18:29:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=877658
18:29:38 <adamw> #info Accepted Blocker, anaconda, ASSIGNED
18:29:45 <adamw> looks like this one just needs an anaconda rebuild
18:30:01 <nirik> or a lorax used in compose?
18:30:27 <nirik> sorry, wrong bug. ;)
18:30:38 <adamw> :)
18:30:53 <jreznik> nirik: yep, it's the next one :)
18:31:04 * nirik lives in the future!
18:31:29 <poettering> adamw: i have the patch ready now. If you can verify that the s-s-k conversion issue is the source of the problem i can commit this and build it in koji
18:31:41 <adamw> poettering: good timing ;) refresh the bug
18:31:51 * jreznik lived in the past - vnc one is now POST
18:31:55 <jreznik> lives
18:32:16 <adamw> #info this just needs an anaconda rebuild, should be fixed with a new build
18:32:26 <adamw> #topic (890577) drop to dracut shell if /usr is on a btrfs subvol
18:32:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=890577
18:32:27 <adamw> #info Accepted Blocker, dracut, ON_QA
18:33:03 <nirik> we did this one already?
18:33:08 <nirik> or is this different?
18:33:30 <nirik> oh right.
18:33:43 <jreznik> so needs testing right now
18:33:44 <nirik> just needs new dracut testing
18:33:45 <adamw> different.
18:33:58 <adamw> i don't think new dracut is in tc4 is it? I think this showed up after i did the request
18:34:45 <nirik> yeah, it's not
18:35:19 <jreznik> I see 024-17, not -18
18:35:25 <jreznik> so it is not
18:37:07 <nirik> I see that dracut also has a fix for 873220 in it.
18:37:15 <nirik> .bug 873220
18:37:17 <zodbot> nirik: Bug 873220 dracut ignores /etc/modprobe.d blacklist - https://bugzilla.redhat.com/show_bug.cgi?id=873220
18:38:28 <jreznik> so we need -18 in next compose and test it? right?
18:38:34 <nirik> yep
18:38:41 <nirik> that bug is a NTH accepted already
18:38:47 <jreznik> yes, it is
18:39:06 <adamw> #info we need to do a TC5/RC1 with the updated dracut to fix and test this
18:39:16 <jreznik> adamw: you were faster :) thanks
18:39:37 <adamw> #topic (883075) fedup upgrading is too quiet
18:39:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=883075
18:39:37 <adamw> #info Accepted Blocker, fedup-dracut, MODIFIED
18:39:50 <nirik> this just needs a new compose right?
18:40:16 <adamw> i think so. fedup always confuses me.
18:40:25 <adamw> it may even be 'done' in some sense with tc4.
18:40:51 <nirik> right
18:41:24 <adamw> best check with tflink when he's around
18:41:47 <adamw> #info this either needs some kind of action to build a new upgrade.img or can be considered done with tc4, need to clarify with tflink
18:41:57 <adamw> #topic (875846) [i18n] "ON" and "OFF" not translated in switches on DVD (gtk30.mo not on DVD)
18:41:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=875846
18:41:57 <adamw> #info Accepted Blocker, lorax, ASSIGNED
18:42:12 <adamw> this is the one which just needs re-spin with new lorax. it wasn't set to MODIFIED or ON_QA so I missed it for the tc4 request.
18:42:23 * nirik nods.
18:42:25 <jreznik> nirik: it's here! :)
18:42:46 <jreznik> next compose
18:43:21 <adamw> #info this just needs a re-spin with new lorax
18:43:27 <adamw> #topic (889562) Console keymap set to "us" if you install with a keymap not provided by systemd-localed
18:43:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=889562
18:43:28 <adamw> #info Accepted Blocker, systemd, NEW
18:43:39 <adamw> so this one we may want to re-vote down to not-a-blocker status, it looks like
18:43:54 <adamw> it is a bad bug, as I established, but it looks like there's no plausible way to really 'fix' it for f18
18:44:08 <adamw> the alternative might be to pull out the worst cases and fix them in kbd-model-map - wdyt lennart?
18:44:18 <adamw> poettering: ^
18:44:54 * jreznik likes the alternative - fix the worst ones we know about
18:45:38 <poettering> adamw: happy to add any missing entries to the map you need
18:45:53 <jreznik> adamw: do we have such list?
18:46:05 <jreznik> or could we have is better question
18:46:06 <poettering> adamw: the translation table is stored as-is on disk, we can totally update that at any time, ebfore and after the release
18:46:08 <adamw> well, i have a list of the most 'obvious' (i.e. associated with offered translations) broken layouts in the bug
18:46:10 <poettering> adamw: as you see fit
18:46:13 <poettering> just send a patch
18:46:32 <adamw> what we're missing is the correct console layout names for those, i assume?
18:46:41 <adamw> where's the 'master list' of console layouts, poettering?
18:47:11 * jreznik will be ok with letting this one blocker one and trying to fix the most obvious for release and maybe more later (as will come)
18:47:13 <adamw> i know kbd-model-map is the actual mapping database, but i don't know where i can find a comprehensive list of actual available console keymaps
18:47:58 <poettering> adamw: localectl list-keymaps
18:48:19 <adamw> that lists every actual available console keymap there is? okay.
18:49:11 <poettering> adamw: yeah, it's basically the collapsed list of files in /lib/kbd/keymaps
18:49:15 <poettering> with the suffixes dropped
18:49:28 <poettering> it's nicely sorted and complete
18:49:31 <adamw> #info plan here is to try and fix up the most prominent missing conversions in systemd's kbd-model-map where corresponding console keymaps are actually available
18:49:39 <poettering> note that some of those maps have stupid names
18:49:47 <jreznik> poettering: if you could help adamw, it would be cool :)
18:49:59 <jreznik> and we can move now
18:50:07 <poettering> i.e. while most of the maps have ISO names some do not
18:50:11 <poettering> and it gets really confusing
18:50:18 <jreznik> uf
18:50:19 <adamw> poettering: is there an idiot's guide to what they actually are anywhere? or am i just going to have to slog through google results etc?
18:50:57 <adamw> i suspect for quite a few cases there just won't _be_ a console map, but eh.
18:51:12 <poettering> adamw: the kbd/kbd-misc packages include all information there is
18:51:14 <poettering> i.e. not much
18:51:15 <jreznik> we should move on - readiness meeting in ten minutes...
18:51:28 <adamw> poettering: okay.
18:51:35 <adamw> last one
18:51:36 <adamw> #topic (876218) pxeboot/netinst + nfsiso repo = hang on reboot
18:51:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=876218
18:51:36 <adamw> #info Accepted Blocker, systemd, ASSIGNED
18:51:37 <nirik> jreznik: is that in here? or ?
18:51:42 <jreznik> nirik: here
18:51:53 <jreznik> so it could be delayed a little bit I'd say :)
18:51:59 <nirik> ok
18:52:30 <jreznik> kparal provided info requested by steved
18:52:37 <jreznik> but I have not seen him online...
18:52:44 <jreznik> (steve)
18:52:53 <adamw> uf.
18:53:00 <adamw> so seems like we're in a 'developer wrangling' situation here.
18:53:14 <jreznik> yep, do we insist on this one as a blocker one?
18:53:31 * nirik looks at scope
18:53:31 <jreznik> it's probably far away from resolution :(
18:53:37 <poettering> adamw: btw, you want to fix the "worst cases", which ones are those in your eyes? do you have a list?
18:53:54 <jreznik> poettering: do you have any more insights on the current one?
18:54:27 <adamw> poettering: i'll have to go back through the list, but basically, i'd consider the keymaps associated with languages and the keymaps offered in f17 as the priorities
18:54:38 <adamw> highest priority, keymaps associated with languages with complete translations
18:55:20 <poettering> jreznik: this really sounds like something anaconda should fix
18:55:35 <poettering> jreznik: i.e. it should unmount what it mounted
18:55:45 <poettering> jreznik: it's probably the easiest
18:55:49 <nirik> huh, it works with systemd debug enabled?
18:56:00 <poettering> jreznik: they could also tell systemd the deps between their networking code and their mounts
18:56:05 <adamw> that was the stuff i got into in the later comments on the bug
18:56:15 <poettering> jreznik: but i'd guess it would be much easier if they just unmounted what they mounted first
18:56:47 <adamw> #info we still seem to be playing hot potato between anaconda, systemd and nfs developers here. poettering believes it is an anaconda bug
18:57:08 <adamw> btw can we quickly rubber-stamp a few NTHs after this one? input related
18:57:14 <poettering> adamw: ok, if you have a list of the x11 keymaps it's just a matter of finding good counterparts in "localectl list-keymaps"
18:58:03 <adamw> poettering: yeah, I've got the plan now.
18:58:26 <jreznik> well, what would be a plan for this one in case we would not have a solution soon?
18:58:27 <adamw> jreznik: do you have a plan for kicking developer tail for 876218?
18:58:56 <adamw> jreznik: *my* plan is to say it's *your* job ;)
18:59:07 <jreznik> adamw: plan? no, but kicking - yes
18:59:10 <rbergeron> do we just need to get ahold of steved?
18:59:13 * rbergeron can just go ask ric
18:59:27 <nirik> or get input from anaconda folks that they can workaround it...
18:59:33 <poettering> rbergeron: i really think the folks mounting the nfsiso should unmount it too
18:59:42 <jreznik> rbergeron: ah, steved seems to be online now
18:59:47 <poettering> rbergeron: which means anaconda should fix this, not systemd and not the nfs guys
18:59:56 * nirik wonders if we could ask anaconda folks in for input.
19:00:05 <poettering> i also commented on the bug now
19:00:26 <adamw> welcome readiness meeting folks, sorry but go/no-go is overrunning a bit, will be done soon
19:00:38 <adamw> sneak preview: the decision will be no-go
19:00:41 * nirik isn't so sure we will be done soon, but yeah
19:00:52 <rbergeron> adamw: man, you just ruined all their popcorn
19:01:00 <adamw> SPOILER ALERT
19:01:02 <rbergeron> poettering: yeah, i just don't want to see it perpetually skating around from person to person
19:01:26 <rbergeron> if that's where it goes then that's fine by me of course but actually having people talk to each other is helpful too ;)
19:02:12 <poettering> talk? intreresting concept!
19:02:13 <jreznik> rbergeron: this one has a lot of people involved in talking :)
19:02:37 <poettering> adamw: http://koji.fedoraproject.org/koji/taskinfo?taskID=4836808 ← please try that for the upgrade issue
19:02:57 <poettering> adamw: of course you need to upgrade from f17 directly to this rpm, rather than uprgading via the older RPM in f18
19:03:04 <adamw> poettering: will do, though i'll have to remember how to fiddle the repos.
19:03:09 <jreznik> but for now - how much do we generally feel about blockery status of this one?
19:03:23 <adamw> i'd be reluctant to lose it as a blocker, really
19:03:25 <jreznik> bcl updated bug, poettering: they can't
19:03:25 <nirik> I think it's a blocker.
19:03:30 <bcl> I don't think it should block.
19:03:30 <nirik> it's in our critera.
19:03:33 <rbergeron> jreznik: yeah, but we were looking at this before christmas break and it seems like no movement, and now we're sending it elsewhere
19:03:52 <rbergeron> we marked it as a blocker, i don't see how w'ed magically think it's not a blocker when not much has changed except potential bug ownership
19:03:53 <nirik> hey bcl. welcome.
19:03:54 <jreznik> rbergeron: that's why I'm probing the blockery status
19:03:57 <adamw> the use case is fairly clear cut: remote install. when your machine 200 miles away hangs as part of an install, that kinda sucks.
19:04:20 <jreznik> rbergeron: you know - it went through the all possible people we were able to get into the bug
19:04:33 <rbergeron> i know :)
19:05:04 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=876218#c17 is relevant here. we *did* waive a similar bug for f17 final. qa in general thought that was a fudge too far.
19:05:47 * jreznik is pinging steved right now to take a look on kamil's log
19:06:17 <jreznik> adamw: you know - compared to all input stuff we try to workaround, this one is...
19:06:45 <poettering> jreznik: commented on the nfsiso bug again
19:06:52 <poettering> jreznik: didn't know this is nfs root
19:07:19 <adamw> jreznik: ...a significant problem in a reasonably common use case for the kind of people who deploy fedora releases? :)
19:07:32 <adamw> i mean, sure, you're a guy who runs on a desktop, so'm i, to us, this bug looks kind of obscure.
19:07:49 <adamw> but to the sysadmin who routinely installs to remote systems and is very likely to use NFS repos to do so...
19:08:11 <jreznik> adamw: I understand the impact, just I'm not sure how much Fedora is used in such environments...
19:08:27 <jreznik> poettering: thanks
19:09:35 <adamw> well, i mean, there isn't much to talk about, just a judgement call to make, i guess.
19:09:55 <jreznik> yep
19:10:04 <rbergeron> and we already made it? did something change?
19:10:19 <jreznik> rbergeron: no, not yet
19:11:05 <jreznik> so what is general feel on this one?
19:11:18 <rbergeron> there shouldn't be a question mark afer "we already made it", fyi
19:11:23 <rbergeron> ;)
19:11:26 <bcl> poettering: sorry that wasn't clear. we're using dracut to bring up the network, so that code path should be normal.
19:12:15 <jreznik> ok, seems like everyone seems to be on blocker status, /me is ok and will be kicking :)
19:13:06 <jreznik> spin the bug to nm?
19:13:45 <adamw> for now i think it stays as a blocker and we bash the developers with a rock.
19:13:49 <adamw> it doesn't seem like it should be unfixable.
19:14:03 <adamw> bcl: poettering: can you and steved just come up with a plan and fix the damn thing somehow? :)
19:14:23 <bcl> hell if I know :)
19:14:33 <jreznik> it's definitely fixable :) the question is what to fix and in what century :)))
19:14:47 <adamw> okay, anyway, i think we should move on
19:15:18 <adamw> #info ball is in development team's court, we need anaconda, systemd and nfs folks to agree on a plan and just fix the damn thing, jreznik and rbergeron please supervise
19:15:46 <adamw> ok, if i can be allowed to cherrypick some important NTH for rubber-stamping...
19:15:47 <adamw> proposed NTH
19:15:48 <adamw> #topic (891489) anaconda cannot find matching keyboard layouts for several languages, sets them to U.S. English
19:15:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=891489
19:15:48 <adamw> #info Proposed NTH, anaconda, POST
19:16:09 <adamw> this is another of the input bugs i found yesterday, anaconda team came up with a fix quickly so we should get it in there, it improves things a bit
19:16:34 <adamw> it's just tweaking the anaconda language->keymap mapping code a bit, should be safe enough
19:16:39 <nirik> sure.
19:16:43 <nirik> +1 NTH
19:17:22 <jreznik> +1 NTH
19:17:24 <drago01> +1
19:17:25 <rbergeron> +1 NTH
19:17:57 <jreznik> adamw: how many nth are you going to discuss?
19:18:02 <adamw> propose #agreed 891489 is accepted as NTH: it's a safe improvement to language->keymap mapping in anaconda which is desirable for non-english installs
19:18:04 <adamw> jreznik: about 4
19:18:07 <adamw> should be quick
19:18:41 <adamw> acks?
19:18:46 <jreznik> ack
19:18:54 <nirik> ack
19:18:56 <adamw> #agreed 891489 is accepted as NTH: it's a safe improvement to language->keymap mapping in anaconda which is desirable for non-english installs
19:19:03 <adamw> #topic (891487) Anaconda keyboard layout list is missing many offered by GNOME, including some associated with languages for which we offer a translation
19:19:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=891487
19:19:03 <adamw> #info Proposed NTH, anaconda, NEW
19:19:22 <adamw> this is the other new one i found last night, we don't have a fix for it yet but it seems pretty slam-dunky that we should fix it if we can
19:19:38 <adamw> well, if it involves major twiddling maybe not, but if it's a simple change i'd like to have it
19:19:45 <jreznik> +1 nth as I already said in the ml thread - I'd like to see it better
19:20:02 <jreznik> adamw: yep, tentative +1 and decide on patch once ready
19:20:06 <adamw> right
19:20:21 <adamw> if it involves hauling lots of stuff into anaconda then we can choose not to pull it
19:21:00 <adamw> nirik?
19:21:19 <nirik> sure, +1 NTH
19:22:03 <adamw> #agreed 891487 is accepted as NTH as a potential improvement in keymap availability, we may choose not to take the change if it is too big
19:22:09 <adamw> (in the interests of time, skipping proposal)
19:22:19 <jreznik> thanks :)
19:23:00 <adamw> #topic (855250) Change the default filtering for Quick and Cangjie
19:23:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=855250
19:23:00 <adamw> #info Proposed NTH, ibus-table-chinese, ASSIGNED
19:23:04 <adamw> this should be ON_QA not ASSIGNED btw
19:23:34 <adamw> this would give us non-sucky default input config for HK users
19:23:40 <adamw> rationale is in comment #26
19:23:46 <adamw> update is all done and ready to go, we just missed pulling it in earlier
19:23:49 <nirik> +1 NTH
19:23:51 <adamw> i'm +1
19:23:54 <jreznik> that's so long, I believe adamw, +1
19:24:14 <rbergeron> +1 NTH
19:24:17 <adamw> #agreed 855250 accepted as NTH, improves default input config for Hong Kong users, safe change that does not affect anything else
19:24:19 * rbergeron just read through it
19:24:27 <adamw> okay, and one final proposed NTH input:
19:24:27 <adamw> #topic (854557) Keyboard layout testing doesn't work as expected and lacks indication of the active layout
19:24:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=854557
19:24:27 <adamw> #info Proposed NTH, anaconda, MODIFIED
19:24:52 <jreznik> there's strings issue...
19:25:14 <adamw> hum, actually
19:25:47 <adamw> i thought the 'fix' for this might be better. if the fix is just to change the text above the input box, i'm not sure it's worht taking.
19:25:48 <jreznik> but that's one string - could be manageable?
19:26:01 <jreznik> adamw: my thoughts
19:26:09 <adamw> it does make the situation a bit clearer, i guess.
19:26:33 <jreznik> -1 nth
19:26:51 <jreznik> not sure the effort is worth of this one
19:27:24 <adamw> yeah, i'm -1.
19:27:34 <adamw> should document it, probably.
19:27:50 <rbergeron> indeedly
19:28:17 <adamw> #agreed 854557 is rejected as NTH as the fix just clarifies the input dialog a bit, it doesn't improve the interface, and would necessitate new translations
19:28:22 <adamw> okay, that's my cherrypick list, i think.
19:28:34 <jreznik> ok, thanks adamw
19:28:38 <adamw> so i guess we should put a rubber stamp on it
19:28:57 <jreznik> #topic go/no-go
19:29:30 <jreznik> situation is quite clear
19:29:35 <adamw> we do not have an RC build, there are outstanding accepted blockers, and test coverage is incomplete. so in accordance with policies, QA votes no-go.
19:30:05 <jreznik> #info there's no RC build, there are outstanding accepted blockers, and test coverage is incomplete. so in accordance with policies, QA votes no-go
19:30:29 * jreznik expects everyone agrees...
19:30:33 <nirik> yeah, no go.
19:30:36 * rbergeron concurs
19:31:03 <drago01> one more thing
19:31:04 * nirik is ready for the 'what now?' discussion tho... we don't absolutely need to slip a week if we don't want to.
19:31:11 <drago01> what about bug 873144 ?
19:31:16 <adamw> for the record: we are not slipping for keymap issues, please no-one shoot me. :) we are slipping for significant blockers which were known and listed prior to holiday break, we just did not get fixes done in time for schedule.
19:31:19 <jreznik> #agreed to no-go
19:31:52 * rbergeron nods
19:31:58 <adamw> drago01: it's not nominated as blocker or NTH. if you feel it should be, nominate it.
19:32:09 <jreznik> adamw: you're too valuable to be shot!
19:32:37 <drago01> adamw: because we agreed to use https://bugzilla.redhat.com/show_bug.cgi?id=883075 as general blocker for this issue
19:33:12 <drago01> adamw: and apperently there is a fix
19:33:17 <drago01> adamw: we just need to use it
19:33:20 <adamw> QA generally is entirely flexible as regards schedule, we don't have any significant work between go/no-go decision and release, so as far as we're concerned, the gap could be nothing. we can work to whatever meets the requirements of others.
19:33:34 <adamw> drago01: 873144 is being used to track something different now, i think.
19:33:52 <adamw> we already discussed 883075 as it's on the blocker list.
19:34:31 <BobLfoot> 883074 & 873144 - just completed testing of fedup-0.7.2.-1 with 18-TC4 and problem of pressing escape producing a blank screen still persists, but a working system does result if you're patient staring at the blanks screen
19:34:43 <nirik> infra would prefer enough time to widely mirror staged release content. Typically thats included a weekend and 2 days... we could look at smaller, but should be carefull.
19:35:04 <drago01> adamw: ok proposed as blocker ...
19:35:10 <jreznik> nirik: what about Go/No-Go on Friday + release on Wednesday?
19:35:26 <jreznik> not sure less time would be enough, so better +1 day
19:35:56 <nirik> jreznik: I would be ok with that.
19:36:06 <nirik> we do think all blockers can be solved in the next 24 hours?
19:36:31 <dingtav> 21.5 :)
19:36:32 <jreznik> nirik: you mean next week?
19:36:39 <jreznik> sorry, this?
19:36:49 <jreznik> or what we are talking about right now:)
19:37:09 * rbergeron needs to have time to ensure that appropriate PR stuff and etc. is lined up as well - all that stuff is normally set for tuesdays
19:37:14 <nirik> well, if we think we can have a rc today, test hard overnight, do another go-no go tomorrow? or were you talking about next friday?
19:37:26 <adamw> that seems pretty optimistic.
19:37:31 <nirik> it does
19:37:39 <nirik> but hey, it's happened before. ;)
19:38:14 <jreznik> seems like pxeboot/netinst is now the only real blocker
19:38:17 <drago01> we can try ..
19:38:36 <rbergeron> and i'd prefer to not have to play the "can we totally drain poeple's ability to sleep and have them test over and over again" on a day to day rolling basis if it gets to that point - i just don't want it to be continuing to be a try every day thing through next week, that just becomes permanent habit
19:38:37 <nirik> I don't want to commit others to marathons... but if they are willing. ;)
19:38:43 <jreznik> +fix for most obvious bad keymaps issues
19:38:48 <nirik> rbergeron: agreed.
19:38:56 <rbergeron> it's a slippery slope
19:39:02 <jreznik> rbergeron: +1
19:39:25 <jreznik> but one thing - we can't expect many brno folks working on Thursday afternoon/evening
19:39:37 <jreznik> so I'd like to ask avoiding Thursday for Go/No-Go
19:39:48 <k0Do> hi, is the go/nogo meeting already done?
19:40:04 <jreznik> k0Do: not yet, sorry
19:40:12 <k0Do> why?
19:40:13 <jreznik> will be soon
19:40:18 <k0Do> UTC 17 o'clock
19:40:22 <adamw> nirik: i don't think we've ever managed to fix up a big list of blockers *and* do a compose and full round of validation in 24 hours before.
19:40:38 <jreznik> adamw: yep, it's non sense - especially with that nfs one
19:40:44 <adamw> nirik: we can do a compose and round of final validation testing in that time frame, but that in itself is a stretch. co-ordinating fixing like 8 blockers too...hmm.
19:40:52 <nirik> perhaps not. So, when is the next window that makes sense?
19:40:57 <adamw> k0Do: we overran
19:41:13 <nirik> k0Do: because we discussed blockers and are discussing how to handle the no go. sorry if it's stepping on another meeting.
19:41:27 * rbergeron would say tuesdays and thursdays would be optimal - we could try again next monday for a thursday release?
19:41:28 <jreznik> nirik: go/no-go next week, but I'd like to avoid Thursday as mentioned above
19:41:42 <jreznik> rbergeron: you mean not a whole week slip?
19:41:56 <rbergeron> we were just talking about a 1-day slip and releasing one day later
19:41:58 <nirik> rbergeron: I guess I would be ok with that.
19:42:03 <rbergeron> i'm talking about 3 days
19:42:08 <rbergeron> or we could do the whole week like normal
19:42:27 <rbergeron> i don't like the ringer we put people through - it's just crappy :\
19:43:10 <k0Do> okay, thanks for the info and sorry for the noise
19:43:11 <jreznik> but it means we would need RC this week - if we want Go/No-Go on Monday
19:43:25 * rbergeron thinks we need to move on to the readiness meeting though - do we have to decide this second
19:43:38 <rbergeron> jreznik: oh,were you just saying that you wanted to do friday for *next* week's meeting?
19:43:46 <drago01> go/no-go on monday should be doable
19:43:49 <rbergeron> not another no/go tomorrow?
19:44:08 <drago01> if we don't think doing it tomorrow makes sense
19:44:10 <jreznik> rbergeron: nirik was talking about another tmrw, I was talking about the next one next week
19:44:34 <jreznik> rbergeron: tmrw is nonsense - we still don't have a clue how to fix nfs one
19:44:54 <jreznik> otherwise it does not look bad
19:44:58 <rbergeron> yeah, i was sort of clueless as to why you were suggesting that :) lol
19:45:02 <nirik> how about: go-no go tomorrow if we have a tested rc, monday if we have a tested rc then, etc?
19:45:23 <adamw> yeah, i think we just need to say, look, we'll do go/no-go as soon as we get the fixes
19:45:35 <nirik> right.
19:45:57 <drago01> nirik: that makes sense
19:46:18 <jreznik> as I said - the only problem I see now is NFS one?
19:46:43 <jreznik> how much time are we willing to wait for it? or fudge :)))
19:47:13 <adamw> well, let's just work through the list and see where we get.
19:47:22 <nirik> lets end this meeting and do the next go/no-go after we have an rc thats had enough time to get testing coverage and no blockers? either tomorrow if by some miracle, or monday, or following friday.
19:47:32 <jreznik> nirik: ok
19:48:11 <jwb> question
19:48:26 <jwb> are you doing that without slipping for now?
19:48:45 <jreznik> jwb: we're trying to avoid 1 week slip
19:49:14 <jreznik> nirik: tmrw->wed release, mon->thu release, fri->+1 week tue?
19:49:25 <jwb> ok
19:49:34 <nirik> yep.
19:49:35 <nirik> that
19:49:43 <jreznik> it's just going to be more difficult to announce it...
19:49:48 <rbergeron> yeah.
19:49:50 <jreznik> but doable
19:50:04 <jreznik> rbergeron: yeah to schedule or announcement?
19:50:30 <rbergeron> i was just saying yeah to "it's going to be more difficult to announce it"
19:50:52 <jreznik> rbergeron: it wasn't clear as you replied quite fast :)
19:51:05 <rbergeron> i would rather just not even try to push people to have something fully tested by tomorrow
19:51:26 <jreznik> so try mon/fri?
19:51:41 <jreznik> mon is earliest one, friday gives us some buffer
19:51:57 <jreznik> (in case we hit more issues)
19:52:04 <rbergeron> that would be my vote. i think we'd be lucky to get fixes in and rc's built by tomorrow.
19:52:20 <rbergeron> the only advantage of tomorrow is closing the door ;)
19:52:24 <dgilmore> jreznik: we cant avoid a week slip
19:52:41 <jreznik> dgilmore: ?
19:52:48 <dgilmore> jreznik: if we dont slip a week we dont have time to get things on the mirrors and staged and out
19:53:11 <jreznik> dgilmore: mon go/no-go would lead to thu release, is it too short?
19:53:14 <dgilmore> jreznik: we need the weekend to make sure things get out to the mirrors
19:53:19 <jreznik> it's based on what nirik proposed
19:53:21 <dgilmore> jreznik: yes it is
19:53:36 <nirik> dgilmore: shouldn't mon->thursday enough time?
19:53:50 <dgilmore> nirik: it wont be mon-thurs
19:54:02 <nirik> oh?
19:54:09 <dgilmore> it would be late monday but  likely tuesday before staging happens
19:54:22 <dgilmore> we would have tuesday and wednesday
19:54:26 <dgilmore> thats not enough time
19:54:32 <nirik> if go/no go is at 17UTC and we have a go, it could be staged right then? why not?
19:54:58 <dgilmore> nirik: thats maybe 60 hours to get it out to the mirrors, its not enough
19:55:27 <jreznik> well, we delayed readiness meeting by one hour - try it or slip one week?
19:55:53 <rbergeron> okay, so it sounds like we just need to stick to the regular schedule because all that stuff lines up for a reason
19:56:02 <dgilmore> rbergeron: exactly
19:56:04 <rbergeron> jreznik: we can see hwo's here but at this point we probably already made them strangle themselves :)
19:56:07 <nirik> hum, well, when I have watched in the past, we pick up a ton of core mirrors really fast, then it's really slow to add more... I usually see them in the first 2 days, then slowly leaf mirrors add
19:56:29 <nirik> so IMHO it could work, but if you really don't think so, we could punt.
19:56:40 <dgilmore> nirik: some of that may be due to the mirrors not using tiering propperly
19:56:59 <nirik> possibly, but I think they have been getting better at it... slowly
19:57:10 <dgilmore> slowly yes
19:57:21 <nirik> also it seems like we have more capacity ourselves than we used to.
19:57:31 <dgilmore> right now i usually stage thursday eevening or friday morning
19:57:32 <jreznik> let's do week slip, does not make sense to argue and a few days - it does not fix that 2 month
19:58:06 <nirik> jreznik: ok, but you want to not do next thursday? how about wed?
19:58:16 <dgilmore> the mirrors have  then friday, saturday, sunday and monday  to pick up the content via there tiering scheme
19:58:26 <jreznik> go/no-go on wed, in case of problems fri?
19:58:28 <dgilmore> the proposal basically cuts that in half
19:58:42 <jreznik> wed->tue, fri->thu
19:59:01 <nirik> dgilmore: well, cuts it by a day, IMHO, but ok.
19:59:21 <nirik> jreznik: lets just do wed and hope for the best. ;)
19:59:39 <jreznik> nirik: and in the worst case we will have fri + weekend for staging
20:00:13 <jreznik> dgilmore, rbergeron, adamw: are you ok with that?
20:00:21 <dgilmore> nirik: if we take it to the mirrors and they say sure thing then im ok with it, but i want to talk to them first
20:00:23 <nirik> there's possibly advantages to doing monday too.
20:00:39 <adamw> i'm fine with anything. i'm just going to work the blocker list.
20:00:42 <adamw> it gets done when it gets done.
20:00:43 <nirik> dgilmore: ok, we can. It might be good to know for down the road.
20:00:50 <dgilmore> nirik: right
20:01:14 * nirik says just slip a week, do wed I guess, if we slip again, discuss at that meeting.
20:01:37 <rbergeron> jreznik: yes, that's okay
20:01:41 <nirik> it's somewhat appealing to slip a week and do monday tho. oh well, no biggie and I'll just shut up now.
20:01:42 <jreznik> nirik: yep
20:02:59 <jreznik> so agreement is one week, regular Tuesday release, with Go/No-Go wed 2013-01-09
20:03:10 <jreznik> and discuss other possibilities on wed in case of issues
20:03:14 <nirik> sure, why not.
20:03:28 <rbergeron> yes
20:03:47 <jreznik> does not make sense to suck all our resources even we are not sure it's feasible
20:04:42 <jreznik> #agreed to slip one week with release date on Tue 2012-01-15 and Go/No-Go meeting on Wed 2012-01-09
20:05:29 <jreznik> #info the possibility of another Fri Go/No-Go will be discussed in case of problems, with possibility to release on Thu 2012-01-17
20:05:56 <jreznik> and let's see how's still here for readiness meeting...
20:06:56 <jreznik> anything else?
20:07:23 * rbergeron has nothing else. except hunger. sweet, sweet hunger
20:08:57 <jreznik> ok, thanks for coming and for the amazing work on F18, even we did not make it!
20:09:16 <jreznik> closing meeting right now... any other issues could be raised on readiness one
20:09:19 <jreznik> #endmeeting