17:00:03 #startmeeting f18-beta-freeze-readiness-meeting 17:00:03 Meeting started Mon Oct 8 17:00:03 2012 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:12 #meetingname f18-beta-freeze-readiness-meeting 17:00:12 The meeting name has been set to 'f18-beta-freeze-readiness-meeting' 17:00:49 hello. 17:01:00 #topic roll call 17:01:08 * tflink is present 17:01:22 Hello 17:01:27 who's in? fedora qa/fesco/anaconda... 17:01:28 * notting is here 17:01:29 * Martix is listening 17:02:59 * Viking-Ice here 17:03:10 #chair nirik tflink notting mitr 17:03:10 Current chairs: jreznik mitr nirik notting tflink 17:03:17 anybody else from anaconda? 17:03:21 sorry fesco 17:03:22 :) 17:03:29 hi 17:03:35 #chair t8m 17:03:35 Current chairs: jreznik mitr nirik notting t8m tflink 17:04:25 let's wait a sec 17:04:53 mjg59, around? 17:06:09 well, let's start - it supposed to be a quick meeting 17:06:35 * nirik nods. 17:06:50 * jwb is here now 17:07:16 #chair mjg59 jwb 17:07:16 Current chairs: jreznik jwb mitr mjg59 nirik notting t8m tflink 17:07:16 * akshayvyas is here 17:07:34 #info jreznik mitr nirik notting t8m tflink Viking-Ice Martix jwb present 17:07:42 #topic purpose of the meeting 17:07:53 Hi 17:08:00 #info the purpose of the meeting is to decide whether the current state of Fedora 18 is in a good shape to enter Beta freeze 17:08:10 #info based on FESCo ticket #946 the required functionality is a) upgrades, b) beta release partitioning in anaconda 17:08:19 #link https://fedorahosted.org/fesco/ticket/946 17:09:34 it's a for the first time we have such meeting, so let's find a format... 17:09:42 #topic current status 17:11:05 #info wwoods reported that the upgrade functionality is not yet ready, should be testable by the end of the week (no gui) 17:12:09 #info beta criteria partitioning - luks code posted for review, raid code already available in the current build in testable state 17:12:23 tflink: anything you can add to partitioning criteria? 17:13:06 LVM is or is not required for beta or at least rc? 17:13:31 jreznik: not really, the code is testable (or will be when we get a spin w/ new anaconda) so that seems to be satisfied 17:13:52 Martix: LVM is not required for beta, no 17:14:05 tflink: thanks 17:14:17 ok 17:14:40 so that's probably all for the current status, any questions? 17:14:43 tflink: if the GUI is not testable, is that considered "good enough", or is a GUI not a required component? 17:15:06 so the LUKS code is posted, but not in a build 17:15:20 what does 'no gui' mean in the context of the updater? CLI tool + upgrade only in dracut/plymouth? 17:15:50 wwoods: ^^^ 17:15:56 wwoods: re gui ... glade should be fixed now (you can edit the assistent pages; in case this is whats holding up the gui) 17:16:08 mitr: for upgrade? I'd say that CLI is probably good enough for testing assuming that there isn't much functionality in GUI only 17:16:28 notting: yeah, cli tool. there's a plymouth progress screen, just no GUI for the frontend/"preupgrade" part 17:16:31 arguably for beta the gui bits need to be present 17:16:31 if all the code isn't yet written, I'd be inclined to say push beta freeze back a week to allow that to be actually done before we enter freeze. 17:16:35 tflink: I guess I am asking whether a GUI will be a blocker for final. 17:16:43 jwb: there was an anaconda build on friday that might have had the LUKS code in it but there were other issues that made us decide not to request TC3 17:16:54 Viking-Ice: That's my reading of the beta freeze as well - "100% complete" 17:17:04 it didn't have luks patches in anyway. 17:17:11 drago01_: yup, pulled the fixed glade from bodhi a week or two ago. I have a prototype UI but it's not finished. 17:17:20 nirik, +1 17:17:20 LUKS is a criteria for beta? 17:17:21 wwoods: ok 17:17:31 mitr: the criterion isn't specific, but I would lean towards blocking beta for a gui on the upgrade tool 17:17:42 nirik, yeah. this is going to be a short meeting hopefully 17:17:43 jwb: yes, LUKS is a criterion for beta 17:17:53 I'm definitely for slipping the freeze a week given the current status. 17:18:07 * jreznik is inclined too not to block beta for gui but would be great to have it in beta (if possible) 17:18:47 "The installer's custom partitioning mode must be capable of the following: ... Creating encrypted partitions" 17:19:04 #link http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 17:20:26 for the record, QA recommends not entering freeze at this time because there is no released upgrade tool to test 17:20:42 #link http://meetbot.fedoraproject.org/fedora-meeting/2012-10-08/fedora-qa.2012-10-08-15.02.html 17:20:47 #info QA recommends not entering freeze at this time because there is no released upgrade tool to test 17:21:07 * nirik nods. 17:21:36 on the other hand as I understand QA is ok with the current partitioning functionality state (as the code is written, should be testable soon) 17:22:37 let's propose formally what nirik already said... 17:22:55 #info proposal: to push beta freeze back a week to allow that to be actually done before we enter freeze 17:23:15 +1 17:23:17 +1 17:23:33 proposal: due to upgrade functionality not being in a testable state, push schedule 1 week to allow it to land before entering beta freeze. 17:23:40 (I think that might be more clear) 17:23:47 +1 17:23:47 nirik: good one! 17:23:52 +1 17:23:54 nirik: +1 17:24:05 * nirik is +1 to his own proposal too. 17:24:11 do we have quorum? 17:24:17 +1 17:24:35 +1 17:24:59 nirik: the question is - is this fesco only mtg? or in coop with qa/pgm? :) but I suppose FESCo so my vote shouldn't be counted... 17:25:17 Can we expect the situation to change in a week, or do we already know that we will have to slip by more? 17:25:17 pjones, mjg59 ^ 17:25:20 qa has already voted slip 17:25:21 nirik: no (assuming I can count ;) ) 17:25:27 yes, +1. 17:25:49 mitr: from the above, it's hoped that testable upgrade code will be available later this week. 17:25:57 mitr: so, that would mean we could enter freeze ok next week 17:25:59 ok 17:26:14 yep, it's what wwoods told me 17:26:21 I guess I'm +1 17:26:32 I see +6 FESCo votes already 17:26:37 yeah - at this point I've done a half-dozen upgrades from F17-F18, where the flow is like: 17:26:46 run ./fedup.cli --network, wait for downloads 17:27:11 reboot, add 'systemd.unit=system-update.taget' to boot args 17:27:25 watch upgrade, which finishes, then crashes at the end and reboots 17:27:59 then the resulting system doesn't start up quite right because of bug 841451 17:28:07 how will be "add 'systemd.unit=system-update.taget' to boot args" handled? 17:28:24 (hope not manually :D) 17:28:53 it should just create a new boot entry (like preupgrade did) 17:28:55 so at this point it's a matter of gluing the bits together, eliminating that crash, sorting out the selinux junk, etc. 17:29:04 actually, no 17:29:23 for f18 and later there's a special 'system-update.target' that triggers if you set stuff up appropriately 17:29:50 (i.e. no need to mess with the bootloader) 17:30:10 could be F17's selinux-policy updated to fix bugs like 841451 17:30:12 ? 17:30:18 not having to deal with the bootloader sounds like a win. ;) 17:30:27 trying to emulate that for F17. although I might decide to just add a boot entry and reboot with grub2-reboot 17:31:31 turns out in F17 the other choice is messing with default.target instead. which is.. not great 17:31:50 Martix: I couldn't think of a reason why not ... ping dwalsh about it 17:32:04 Martix: probably? but in the general case the SELinux guys suggest that loading the new policy before the upgrade is probably the safest course 17:32:36 well, let's count votes - we have +6 by FESCo (quorum met), +1 as the whole QA, +1 FPGM 17:33:25 #agreed due to upgrade functionality not being in a testable state, push schedule 1 week to allow it to land before entering beta freeze (+1 6, 0 0, -1 0 for FESCo, +1 for the whole QA, +1 for FPGM) 17:33:55 wwoods: thanks for status, looks good to me ;-) 17:35:15 and to revisit the decision in one week? 17:35:22 thanks for the updates wwoods. :) Do let folks know when things are ready for testing. 17:35:42 jreznik, I'd say we can use the ticket to revisit 17:36:15 t8m: works for me and it the worst case we can set up another "quick" mtg :))) 17:36:18 jreznik, unless there is a demand to revisit and slip more we could freeze next week by default 17:36:36 by default? 17:37:05 jreznik, yes, freeze next week by default 17:37:27 lets assume we can freeze as scheduled next week, but if someone wants to change that and meet again, they can ask for that in the ticket later in the week 17:37:45 nirik, +1 17:38:04 +1 17:38:52 #info to use ticket #946 to revisit the decision, freeze by default next week 17:39:27 anything else? otherwise I think we're done today (just a few action items for me) 17:39:32 * drago01_ notes that the upgrade tool still have to be packaged & reviewd 17:39:36 * nirik has nothing. 17:39:57 drago01_: wwoods: i'd suggest starting the review process now 17:40:06 * nirik is happy to help review, etc. 17:40:15 * jreznik is also willing to help 17:40:19 unless it's intended to be a subpackage of something that already exists. 17:41:40 #info suggested to start packaging/reviewing of fedup as soon as possible (in case a new package is needed) 17:41:48 it's not a subpackage. I'll let you know when I get to the point where I'm writing a specfile. 17:42:43 wwoods: would be great to have at least preliminary one to go through the process as it can take some time... I know, overhead but... 17:43:05 wwoods, i think nirik was suggesting you make it a subpackage of something and avoid review. 17:43:08 ;) 17:43:26 shortcut :D 17:43:35 ok, let's wrap up 17:43:35 well, I didn't know how it was going to be organized... 17:43:59 if it's it's own thing it should probibly be it's own package (which also makes sense from a update for older releases standpoint) 17:44:05 #action jreznik to announce pre-freeze Beta slip and to adjust F18 schedule 17:45:00 #topic open floor 17:46:29 btw. do we want freeze readiness before every milestone (alpha/beta/final) in the future? this time we know anaconda is broken but similar situation already occured and I expect it will occure in the future (with other components) 17:47:06 I think it may likely be overkill normally. 17:47:17 agreed 17:47:21 but perhaps we could discuss that at the next regular fesco meeting. 17:48:28 nirik: good idea, I'll file the ticket... /me is scared of overkill but also this sounds reasonable in case we know something is going to break a lot 17:48:38 jreznik: I think RC freeze is equivalent to go/no-go 17:50:38 #action jreznik to report a ticket to fesco if we want to have freeze readiness meetings regularly or not 17:51:07 thanks for coming, we're done, I'll end meeting in... 17:51:09 3... 17:51:41 2... 17:52:12 1... 17:52:17 #endmeeting