15:01:22 #startmeeting Fedora QA Meeting 15:01:22 Meeting started Mon Oct 1 15:01:22 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:25 #meetingname fedora-qa 15:01:25 The meeting name has been set to 'fedora-qa' 15:01:28 #topic roll call 15:01:35 morning folks! who's around for the qa meeting? 15:01:38 * pschindl is here 15:01:40 * mkrizek is here 15:01:42 * jskladan yay for meeting time (before party time) 15:01:48 * tflink is here 15:01:48 * nirik is lurking, ping if I can help with anything. 15:01:54 * kparal hails to the king 15:01:57 * akshayvyas is here 15:02:00 * Viking-Ice here 15:02:06 #agreed all qa work to be done by nirik 15:02:12 nirik: ping ^^^^ 15:02:12 ack 15:02:16 ack 15:02:17 ack 15:02:19 :P 15:02:22 :) 15:02:26 I'll get right on it. 15:02:32 patch: all work to be done by nirik 15:02:54 let's be realistic 15:03:11 all qa work is enough for one man 15:03:30 only dwalsh can pull that off 15:03:34 and that man is ?? 15:03:45 james bond? 15:03:56 :) 15:05:18 okey dokey 15:05:21 bond is good at breaking stuff, I suppose but I think I'd rather have Q working on that :) 15:05:50 #topic Previous meeting follow-up 15:06:28 #info "adamw to refine alpha partitioning criterion" and "adamw to draft new partitioning criterion for Beta once we know what will be in anaconda" - the proposal's on the list, we'll come to it later 15:06:39 #info "adamw to consider revisions to 'kickstart delivery method' criterion" - didn't get to that one yet, sorry 15:06:47 tflink: "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - anything from that? 15:07:28 * jreznik is here, sorry for being a little bit late 15:07:32 nothing yet, no. I was waiting for the partitioning criteria 15:07:44 I have a draft email that I'm planning to send out later today 15:08:07 * jwb is here for kernel stuffs 15:08:16 #info "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - tflink was waiting for the revised partitioning criteria before doing this, so will happen soon 15:08:19 hi jwb 15:09:32 I think we are missing one or more hd criteria for the storage spoke but other then that I just think we should be more or less on par what other OS are doing 15:09:41 just a sec, let me topic up 15:10:03 #topic Release criteria: partitioning criteria proposal 15:10:31 so, for anyone who missed it, I posted a rough proposal for partitioning criteria to the list last night: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html 15:10:46 #info adamw proposed revised partition criteria for F18+ to the list: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html 15:10:52 discuss away! 15:11:04 Viking-Ice: 'one or more hd criteria for the storage spoke' - what do you mean exactly? 15:11:31 do we care about reuse of encrypted partitions? 15:11:50 ie reusing LUKS setup if /home is encrypted 15:11:51 ugh, I didn't get to that discussion today 15:11:54 * kparal reading it 15:13:20 tflink: I think yeah we should cover that 'upgrade' scenario 15:13:21 adamw, if you have one or more hd detected and install on to 15:13:23 that means fully custom partitioning should be just in Final, right? 15:13:26 i did miss that one out 15:13:26 mena too 15:13:33 mean mean frack! 15:13:52 I have one concern about that - it wouldn't be tested as well (as if we required it in Beta) 15:14:13 dlehman: the (rough) criteria proposal for partitioning is at https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html , if you didn't catch it yet 15:14:25 true but I think that reusing LUKS setup falls pretty well into the realm of custom partitioning 15:14:40 kparal: the beta criteria i proposed require some specific abilities for the custom part code 15:14:52 the second criterion is all stuff you can only do in custom part, in newUI 15:14:54 adamw: oh, I have skipped one paragraph. now I see it 15:15:03 for those that have not read it yet http://blog.linuxgrrl.com/2012/09/25/anaconda-bootloader-reusing-home-assigning-partitions-to-disks/ 15:15:10 and i'd agree with tflink that we should add 're-use existing /home' to that 15:15:39 yeah re-use should be added to the criteria as well 15:15:46 existing LUKS is absolutely custom. always has been. 15:16:00 dlehman: that's fine 15:16:24 yeah, it kind of branched into two discussions - reusing existing home and reusing existing encrypted home 15:16:35 tflink: re-use existing /home is also custom partitioning. 15:16:39 I added a comment there on the blog post what probably is the expected expectation in that regard 15:17:02 well, now i think about it 15:17:13 which criteria could be built upon 15:17:15 adamw: yeah, but I thought that we were talking about adding that particular use case to what is needed for beta 15:17:17 if you have to use custom partitioning for something, then effectively, pre-f18, it was only required at final 15:17:19 yeah 15:17:36 so if we add anything that required custom partitioning in oldUI to the beta criteria, we're setting the bar higher than previously 15:18:25 adamw: good point, final is fine 15:18:35 I tend to agree with kparal that custom partitioning fits in beta criteria ( alpha not required, beta required to work ) 15:18:35 so we might want to re-word the final criterion a bit to be less vague, rather than adding to beta 15:19:03 Viking-Ice: well i was going for a middle way, in which custom partitioning is required to not be hideously broken at beta, but not required to work entirely 15:19:21 * tflink smells another epicly long release criterion :) 15:19:39 heh :) 15:20:05 custom partitioning in anaconda has never work entirely at least not up to the extend kernel supports so I'm not following what you are getting at there? 15:20:13 * kparal is fine with almost-but-not-fully covered custom partitioning in Beta 15:20:28 Viking-Ice: well 'completely' would be 'passes the Final criterion' 15:21:11 just create what 15 partitions on a single drive and see how anaconda handles that ( insane but you know supported by the kernel ) 15:21:16 oh, here's a modification... 15:21:36 change "Creating and assigning" to "Creating, destroying and assigning" 15:21:50 or 'removing', whatever 15:22:04 i'm looking at making sure the pre-18 *alpha* requirements are covered 15:22:04 adamw: +1 15:22:20 one of which was the 'existing Linux partition' autopart method, which wiped existing linux installs but left windows alone 15:23:02 Viking-Ice: well that's not really anything new, since we're not proposing to change the final criterion...can we focus on the beta? 15:23:22 Viking-Ice: is it that you want further requirements for custom part at beta beyond what's already proposed? 15:23:49 does anaconda actually fail when disks contain the maximum number of partitions? if so, it's just because that never happens in real life (or in bugzilla AFAICT) 15:24:21 in alpha only the autopart should be required to work and quite frankly I dont think we should be having multiboot support in our criteria et all unless the other OS support that as well 15:25:13 Viking-Ice: well that's what the currently proposed alpha criterion does, so no problem there 15:25:22 and we only have multiboot in final, and we're not talking about final right now... 15:25:31 adamw: autopart-in-freespace. I'm not sure how binding this is. Do we need to specify things like "assuming the disk contains a valid disklabel and is bootable, &c" ? 15:25:59 dlehman: eh, we don't _need_ to really, we can always clarify that at blocker review time, but maybe we could 15:26:05 let me see how verbose it looks 15:26:46 dlehman: actually, i think the current wording works fine 15:26:49 you guys have been good in the past at calling out dealbreaker variations so I'm willing to trust you based on that 15:27:18 adamw, are we just talking about fixing the criteria for beta or fixing the criteria in general? 15:27:34 Viking-Ice: well right now i'd like to focus on the specific partitioning criteria proposal on the list 15:27:42 Viking-Ice: there's a topic later for 'general criteria revision ideas' 15:27:50 adamw: in that free space case, are we supposed to not install any bootloader? 15:28:08 no, I don't know what we used to do 15:28:10 dlehman: yeah, i was just pondering that when i went quiet there 15:28:28 dlehman: we used to install a bootloader, i would expect we still will. so the wording might need a bit of a change. 15:28:54 although, strictly, the MBR isn't part of the 'existing partition table' or 'existing data', really. 'existing user data'? 15:28:59 maybe add something about offering to access preexisting encrypted devices? 15:29:01 help? :) 15:29:03 (in custom) 15:29:24 existing partitions or filesystems? 15:29:27 dlehman: well, access is needed only for re-use, right>? 15:29:30 hi 15:29:32 right 15:29:38 the one case we're specifically concerned about there is re-using an existing /home 15:29:55 but then we also considered that, per the pre-f18 criteria, that wasn't actually required to work until final 15:30:06 so if we add that to beta, we're _tightening_ the requirements 15:30:10 i mean we can do that, but it's a consideration 15:30:12 I see 15:30:42 it's a bit tricky trying to strike a balance of exactly what we think really needs to be working in custom part by beta, given that custom part is obviously more important in newui since autopart is more restricted. 15:31:19 Viking-Ice: so do you have anything you'd like to add to/remove from the beta criteria proposed? 15:33:15 dlehman: for the 'empty space' one..."The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"? 15:33:16 adamw, I actually would like to move the whole custom partitioning from final to beta 15:33:57 adamw: sounds okay to me 15:34:05 adamw: what about /boot partitions? 15:34:16 tflink: in relation to what? 15:34:25 Viking-Ice: if you're going to do that you'll have to do so at the beginning of a cycle 15:34:46 if you mean the criterion me and dlehman are discussing, irrelevant, 'autopart into empty space' does not re-use any existing partitions, it'd create its own /boot 15:34:48 dlehman, yup 15:34:49 'leaving the pre-existing partitions and data untouched' - does that apply to any existing /boot partitions 15:34:58 tflink: per the above, yeah. 15:35:07 an install re-using an existing /boot would have to be done through custom part. 15:35:12 dlehman, so it would not be subjected for F18 but F19 if we change it 15:35:33 Viking-Ice: ok, so if you're not proposing that for f18, can we table it for now? since it's important that we nail down the f18 requirements 15:35:41 adamw, ok 15:35:58 the reason i want to get this done now, btw, is that it feeds into the 'should we freeze beta' discussion 15:36:13 whatever we decide the beta criteria need to be, that's what needs to be basically implemented before we freeze for beta 15:36:28 ditto for upgrade 15:36:52 so here's what we have so far, modified from the list proposal: 15:37:00 1. "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched" 15:37:11 2. "The installer's custom partitioning mode must be capable of the following:" 15:37:26 2a. "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types" 15:37:33 2b. "Creating encrypted partitions" 15:37:41 2c. "Rejecting obviously invalid operations without crashing" 15:37:58 any specific proposed revisions to those, to be enforced for f18 beta? 15:38:14 does anyone reckon we should include a requirement for re-using an existing /home at beta rather than final? 15:38:18 we're leaving LVM for ginal? 15:38:28 final 15:38:34 tflink: i left LVM on the basis that anaconda team say it's really going to be de-emphasized for newui. 15:38:39 LVM is The Past, btr is The Future. 15:38:50 but we could change that if we think it's still important enough 15:38:57 dlehman: wdyt? 15:39:18 tflink: LVM was kinda in the previous criteria because it was the Fedora default and we were very big on it for a while. 15:39:20 it's somewhat of a departure from previous requirements but yeah, btr seems like it will replace LVM at some point 15:39:50 lvm still needed for encrypted tho right? 15:39:52 if fedora isn't so 'ra ra LVM' as it was, which kinda seems to be the case, it's probably not as important 15:39:56 adamw: I'd say that reuse of /home is OK for final 15:39:57 nirik: no? you can encrypt a regular partition. 15:39:57 nirik: no 15:40:08 "re-use" and "upgrade" criteria belong in the same milestone ( beta from my pov ) 15:40:22 encryption + LVM == pain (from my experience) 15:40:25 ok, cool. I thought it was tied to lvm at one point. 15:40:34 well, encrypting the VG == pain, anyways 15:40:57 so btrfs is default now 15:41:19 akshaysth: not right now no, still ext4 15:41:20 for F18? I thought that was still pending 15:41:24 but i think the plan is for btrfs as default in future 15:41:34 F20+ 15:41:37 adamw: explicit inclusion of lvm in addition to plain partitions? 15:42:00 Viking-Ice: i can see that, yeah, since the main use case for re-use is basically upgrading. 15:42:11 yup 15:42:31 dlehman: well that's what we were just discussing - i left it out on the basis that you folks thought LVM isn't as important as it used to be, i remember us talking about that in #anaconda, but we can certainly add it back if you think we still should for now. 15:42:43 adamw: pointed the wrong one :) 15:43:11 akshaysth is someone else 15:43:24 Viking-Ice: the counter-point to that is that we require upgrade to be in place for beta because upgrade is complex and so we want it in beta so people can test it and report bugs and they can get fixed for final 15:43:35 Viking-Ice: re-use of /home isn't at all as complex an operation as an upgrade installation is 15:43:47 it doesn't really need months of testing, it just...either works or doesn't work 15:44:08 adamw: reuse of non-encrypted home, sure 15:44:23 true, encrypted home is a bit messier 15:44:34 depends on how you look at it, that feature from my pov of view should be handled automatically from the storage spoke ( as opposed forcing the user having to go to custom partitioning and do all the necessary steps there ) 15:44:35 anyhow, we're now debating *strengthening* the proposed criteria, i don't hear anyone saying we should weaken them 15:44:50 so should we approve what's proposed now as a baseline at least? we can always tighten things from there 15:44:50 adamw: I don't really know, to be honest. partitions are a must. lvm, md, btrfs, all debatable. 15:45:26 * tflink wonders about leaving md and btrfs for final, though 15:45:28 Viking-Ice: i don't think that's gonna happen for 18 at least, aiui. re-use is something you'll definitely have to do through custom part (like it was in oldui) 15:45:40 seems like it could cause a lot of problems, no matter when it lands, I suppose 15:45:49 tflink: we don't have them in the current beta proposal, dlehman was floating them, 15:45:51 Viking-Ice: that amounts to a sizable RFE, so not going to add that for F18. 15:46:39 I'm not against the idea of requiring md and btrfs/lvm for beta as long as we're being reasonable 15:47:01 ok, so how bout this: we vote on approving the new criteria proposed above, then i'll send out a new mail proposing some kind of limited re-use of /home requirement for beta, to be discussed separately 15:47:03 adamw, then it falls just under the general custom partitioning criteria 15:47:16 Viking-Ice: it'd certainly be covered by the existing final criterion yes 15:47:20 adamw: works for me 15:47:24 Viking-Ice: but we could also add it to beta if we want it to work by beta 15:47:25 ack 15:47:42 to the limited beta criteria proposal surrounding re-use of /home 15:47:48 * tflink is +1 on the partitioning criteria as proposed above 15:48:34 adamw: the biggest problems with btrfs and lvm are they are so overfull with options that requiring support for any existing config is quite a demand. creating what is supported in the installer, OTOH, it not. 15:48:47 propose #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately 15:48:56 dlack 15:49:01 ack 15:49:01 mean ack 15:49:06 ack 15:49:27 dlehman: right, hence the proposal for a 'limited' re-use criterion - i was thinking exactly along the lines of *not* needing any kind of massively complex encrypted-btrfs-on-encrypted-lv /home partition scenario to wrok :) 15:49:28 ack 15:49:44 dlehman: do you think it would be reasonable to require creating a new layout with btrfs/lvm/md @ beta would be reasonable, leaving reuse for final? 15:50:05 #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately 15:50:16 that gets hard to write out in any reasonable way, though 15:50:36 dlehman, any particular reason we should be single out re-use as a special feature until you guys have though things through on how you would like to have it in the end ( which means we could just scrap any kind of criteria around it for F18 ) 15:50:37 tflink: not really, i could add it to the wording of 2a) easily enough 15:50:53 tflink: probably, yes. I won't sign anything saying as much until I have time to reflect on it further, though. 15:50:58 :P 15:51:14 it's not just whether it's reasonable, though, it's the basic question of 'does all that really need to work in a Fedora beta'. 15:51:23 anyhoo, we have a baseline now at least 15:51:26 and this is taking a while 15:51:36 shall we move on to the upgrade criterion? which with any luck should be easier 15:52:17 dlehman: ok, I wasn't looking for anything definitive today - mostly wondering whether the idea was unreasonable 15:52:33 #action adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta 15:52:33 adamw: yeah, that proposal has been pretty quiet as of late 15:53:01 #info viking-ice suggests that for f19+, much more custom partitioning functionality should be required at Beta 15:53:17 * adamw trying to capture the major thoughts from the partitioning discussion for the record, any others? 15:54:26 adamw: the idea of requiring new lvm/md/btrfs for beta while leaving the reuse/modification of existing layouts for final? 15:54:28 * jreznik is ok for now, a little bit harder to follow you here... 15:54:30 #info there is some support for requiring creation of LVs/advanced btrfs partitions/RAID to work at beta 15:54:54 tflink: did you want a definite #action or is it OK to leave it vague? 15:55:14 I prefer vague 15:55:24 adamw: I'm fine with it being vague as long as we don't forget entirely 15:55:52 tflink: well it'll be in the meeting summary. only #actions are 'guaranteed' to get picked up on later though, in the sense that they get covered at the next meeting. 15:55:57 #chair tflink kparal viking-ice 15:55:57 Current chairs: adamw kparal tflink viking-ice 15:56:09 now you can #action yourself if you like :) 15:56:36 #topic Release criteria: upgrade criteria proposal 15:56:56 #info tflink quoted the current proposals at https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html 15:57:22 basically, for beta it must be possible to upgrade with any 'officially recommended upgrade mechanism', at final they all have to work. 15:57:49 as things stand i think we will only have one 'officially recommended upgrade mechanism' for f18 anyway, so it's kinda moot, but hey 15:57:59 anyone want to propose changes to it that haven't already been discussed? 15:58:10 * adamw +1 to the proposal 15:58:21 +1 15:58:42 we kinda have to decide how far back we expect official upgrade is supposed to work 15:59:22 Viking-Ice: as these are applied to f18, as I understand the current plan, it pretty much means 'upgrade has to work at beta'. 15:59:29 which is what we had previously. 15:59:53 i think we have pretty solid agreement that that's what we want, a lot of the discussion was just covering loopholes and making the wording apply when it's not anaconda doing the upgrading. 16:00:18 I'm ack on the proposal but we still need to add how far back release upgrades are supposed to be supported 16:00:27 oh right 16:00:29 iswym 16:00:35 mean do we support upgrading from F1 to F18 beta? 16:00:35 I think that the current wording of "previous stable release" is pretty clear - Fn-1 to Fn only 16:00:44 with the current proposal it's the same as the previous one: we only support F(n-1) 16:00:57 as far as f18 is concerned it probably makes sense not to change that now 16:01:05 if we want to support n-2 we should probably make that f19 stuff 16:01:12 agreed 16:01:13 but you're right we still need to determine that 16:01:22 that seems a bit much to change right before freeze 16:01:36 and make other documentation consistent with whatever we ultimately agree development/qa will care about 16:02:02 #info viking-ice points out that the question of the status of upgrades from older Fedora releases has still not been entirely settled 16:02:43 I could have sworn we had a packager guideline about caring about N-2... but nothing saying what upgrades were "supported" 16:03:08 perhaps we could have N-1 as blocker, and N-2 as NTH? :) (but perhaps thats f19 as you said) 16:03:20 nirik: as far as QA is concerned we've had the criterion written as 'the previous release' ever since f12, and we've only enforced that (we have a test for n-2 but it's optional and rarely actually performed) 16:03:31 yeah 16:03:33 it makes sense we support N-2 as in F16 being supported to be upgraded to F18 16:03:43 Viking-Ice: yeah, I agree with that too. 16:04:23 the counter to that is stuff like usrmove and if it would be a problem to support multiple upgrade vectors 16:04:24 Viking-Ice: i'm kinda torn - i think it's probably correct that we should change and support N-2, but i'm not sure we should do it for F18 since it's pretty late now 16:04:26 adamw, our lazyness not testing it is no excuse ;) 16:04:49 Viking-Ice: i'd definitely be on board with supporting F17-F19 and onwards, but i'm a bit unsure about F16-F18 16:05:03 anyone else? 16:05:06 could be a final upgrade criteria 16:05:07 either way, I'm against requiring n-2 upgrades for F18 - it's too late in the release cycle to be making changes like that 16:05:24 Viking-Ice: ironic, usually you're the one saying we should only change for future cycles and i'm the one saying we should change now :) 16:05:35 I don't think upgrade from n-2 is a good idea at all, so I wouldn't definitely change that for F18 16:06:12 anyway, again we can at least accept that we want *at least* the current proposal 16:06:23 which is the important thing for the 'should we freeze' discussion 16:06:25 so... 16:06:26 let's clarify that then for F19 16:06:33 ack on the current proposal 16:06:35 * tflink is still +1 for current proposals 16:06:45 propose #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted 16:06:51 ack 16:06:53 ack 16:07:07 ack 16:07:20 * nirik re-reads 16:07:27 #info there is some support for extending the criteria to support upgrades from the two previous stable releases, we will discuss that separately 16:07:32 so is the 'or' in final intended? 16:07:33 wait, does that link point to the actual criterion proposal? 16:07:46 it contains them, nvm 16:07:51 nirik: what 'or'? 16:07:59 oh 16:08:13 hm. 16:08:14 minimal or blocking desktop 16:08:19 it's meant to mean 'all of these', not 'any of these' 16:08:24 'or' is a bit ambiguous 16:08:24 shouldn't that be 'minimal and all blocking desktops' ? 16:08:47 the problem with 'and' is it makes it sound like 'you have to be able to upgrade a system which has both GNOME and KDE installed' 16:09:20 making the wording completely clear seems a bit tricky, shall we agree with the intent and try to refine the wording later? 16:09:33 * tflink wonders if we should have some definition of 'release blocking package sets' elsewhere in the criteria 16:09:45 tflink: we define 'release-blocking desktops' in the preamble 16:10:02 oh, iswym, that might work 16:10:06 we should not be supporting multiple *de installs et al from my pov 16:10:12 nirik: is that OK with you or do you want to nail down the wording now? 16:10:22 Viking-Ice: yeah, that's not the intent here, which is why i don't just want to replace 'or' with 'and 16:10:26 sure. I think we all agree on intent. 16:10:40 yup 16:10:53 * kparal back in a few minutes 16:10:54 the set of: minimal and (seperately) each release blocking desktop 16:10:56 or something 16:11:02 'yeah, something like that, but more elegant :) 16:11:20 right 16:11:27 #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted (but we note that the use of 'or' is slightly ambiguous and can be improved) 16:11:33 ack 16:11:42 ack 16:11:54 #agreed the intent of the proposed criteria is that you must be able to upgrade all three of: a) a minimal install, b) a GNOME install, c) a KDE install 16:11:58 (just so we have that clearly noted) 16:12:14 alrighty! 16:12:23 adamw: how can you have minimal, gnome and kde installed at the same time? 16:12:26 :-D 16:12:28 * tflink ducks 16:12:31 * adamw throws things at tflink 16:12:34 d'oh, you're way ahead of me 16:12:45 ok, this is really dragging on, so let's move straight to the pre-freeze discussion 16:12:56 #topic Fedora 18 Beta status: freeze-worthy? 16:13:13 nope 16:13:43 we need to delay the freeze until the upgrade tool is in place 16:13:43 there's a bunch of stuff that I haven't even tried to poke at yet 16:13:44 #info FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta 16:14:05 #info the idea is that we freeze only once the code required by the Beta criteria is broadly in place 16:14:05 but I would agree that without a testable upgrade tool, there's little point in entering freeze 16:14:13 yeah, i agree with that too 16:14:14 freeze is scheduled to start 2012-10-09 currently. 16:14:22 * nirik nods. 16:14:42 it's noted on the FESCo ticket that the upgrade tool code technically exists: https://github.com/wgwoods/fedup 16:14:50 but afaik there has been no release yet, and i don't know if it's in working state. 16:15:01 dlehman: do you have any info there? 16:15:02 wwoods, around? 16:15:29 no idea about the upgrade tool 16:16:02 nirik: fesco is looking at it this week right, though? since next week's meeting will be 10-10 16:16:13 I think so... let me look 16:16:42 dlehman: the other thing that we just agreed, that i'm not sure of the status of: error handling 16:16:54 yes, it should be this week. 16:17:05 #info the new upgrade tool code is at https://github.com/wgwoods/fedup , but as far as we are aware there has been no release and no indication that it is yet in testable state 16:17:34 dlehman: is error handling in yet? i.e. will anaconda still just crash if you do something wrong in custom part? 16:17:43 I would argue that we need ~ 24 hours to poke at any released upgrade tool before determining whether it's testable 16:17:47 adamw: error handling is largely complete during configuration, but we haven't done much for errors that occur during actual install 16:18:01 tflink, atleast 24 hours 16:18:17 dlehman: well the criterion covered partitioning specifically, so if we're handling errors during custom part that's probably okayish. 16:18:44 Viking-Ice: to determine whether it's testable or not? a week would be awesome but I'm not sure how practical any of that is 16:18:50 * wwoods is around 16:18:56 dlehman: would you say that right now the partitioning code broadly covers the criteria we agreed earlier? i don't think 'autopart to empty space' was working in 18.10 16:19:08 wwoods: what's the current state of fedup? 16:19:39 that seems rather unfortunately named, but as long as it works ... 16:19:40 it's a work in progress. it'll be testable soon. 16:19:50 tflink: i suspect humour 16:19:57 wwoods: can you put a date on 'soon'? 16:19:59 it's short for "Fedora Upgrader", obviously 16:20:02 adamw: no. 16:20:16 or: "before the freeze" 16:20:16 adamw: yes, the criteria are largely covered as of now. 16:20:26 adamw: as do I, but the meaning of "fed up" has other connotations which don't inspire confidence 16:20:27 that kinda answers that 16:20:59 we delay the freeze 16:21:41 okay so here's more info. 16:22:17 the CLI frontend is basically done, at least for a beta of a 1.0 release 16:22:23 the GUI is coming along 16:22:56 the actual upgrade part needs to be tested a bit to figure out whether we can reliably run the upgrade from system-update.target 16:23:18 otherwise we'll run it from an external system image like anaconda used to 16:24:09 I've been talking to mizmo a bit about a plymouth progress screen for the upgrade 16:24:29 should have something testable.. sometime before the freeze, which I understand to be 10/10 16:25:03 okay 16:25:16 #info wwoods says fedup should be testable before freeze 16:25:16 is the decision to delay freeze being made @ FESCo on wednesday, or just discussed? 16:25:20 wwoods: it's 10/9 not 10/10. 16:25:25 tflink: not sure 16:25:36 ah, yep. that's what I have on my calendar. 16:25:46 #info dlehman says current partitioning code covers the criteria as accepted earlier in the meeting 16:26:04 so...i'd say we think the current state of things isn't freeze-able 16:26:18 but if fedup is indeed testable by 10/9 we'd say that is freeze-able 16:26:19 adamw: agreed 16:26:21 right? 16:26:46 anyone have any other areas they're worried about for beta freeze, any other requirements i missed? 16:26:53 PXE 16:27:27 that can mean alot of things are you refering to kickstart installs ? 16:27:30 oh, that's beta isn't it, what's the status of that? 16:27:33 adamw: device encryption is still in development 16:27:47 adamw: not sure, haven't gotten around to trying it yet 16:27:52 Viking-Ice: general topic, is anyone aware of any other major features of anaconda that would be required to be in place by the beta criteria but aren't yet written 16:28:13 Viking-Ice: we're talking major features that aren't done yet, like the upgrade code, not just beta blocker bugs - it's fine for blockers to exist at freeze time, but we want the code to be at least _written_ 16:28:13 adamw, tflink mentioned PXE 16:28:15 how are we defining testable for upgrade - something that compiles and starts to run? 16:28:16 yeah 16:28:30 tflink: my wibbly concept is 'the code is there' 16:29:04 PXE with http repo works 16:29:16 I couldn't test nfs repo yet 16:29:29 that sounds freezeable to me 16:29:32 (for pxe) 16:29:35 yup 16:29:52 did nfs work for alpha? 16:29:56 no 16:30:24 there is a bug somewhere around I intend to verify 16:30:25 that would be another area of concern unless someone else has tried it 16:30:36 OK, it sounds addressed, at least 16:30:37 but I was sick for the last few days so I didn't get to it 16:31:27 serial console? 16:31:45 i think that's in 16:31:54 ok so how about this 16:32:46 propose #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space 16:33:39 ack 16:33:49 sounds good 16:33:50 that works 16:36:24 #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space 16:36:27 ok, i have to run right now 16:36:32 tflink/kparal, can you take over? 16:36:40 either wind things up or do a blocker review, whatever people feel like 16:37:06 yeah, can do 16:37:36 I would prefer leaving the blocker review to wednesday 16:37:43 yup 16:37:47 we're already at 1.5 hours, do we really want to do a blocker review? 16:37:52 sounds like not so much :) 16:37:56 ;) 16:38:11 but reviewing blocker bugs is _so_ much fun ... 16:38:28 if there are no objections, we can move on to open floor 16:38:53 let's move to open floor 16:39:04 #topic Open Floor 16:39:15 * kparal moves to the dance floor 16:39:34 * Viking-Ice points out that nobody dances on monday's 16:39:35 Anything else before we finish up? 16:40:01 sounds like someone has a case of the "mondays" 16:41:18 * tflink will hopefully be sending out a testing request for the devel version of the blocker tracking app this week 16:41:33 do the countdown 16:41:54 if there's nothing else - I'm setting the fuse for [0,5] minutes 16:44:07 Thanks for coming everyone! 16:44:10 #endmeeting