15:01:22 <adamw> #startmeeting Fedora QA Meeting
15:01:22 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:25 <adamw> #meetingname fedora-qa
15:01:25 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:28 <adamw> #topic roll call
15:01:35 <adamw> 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 <adamw> #agreed all qa work to be done by nirik
15:02:12 <adamw> nirik: ping ^^^^
15:02:12 <kparal> ack
15:02:16 <Viking-Ice> ack
15:02:17 <tflink> ack
15:02:19 <adamw> :P
15:02:22 <nirik> :)
15:02:26 <nirik> I'll get right on it.
15:02:32 <jskladan> patch: all work to be done by nirik
15:02:54 <kparal> let's be realistic
15:03:11 <kparal> all qa work is enough for one man
15:03:30 <Viking-Ice> only dwalsh can pull that off
15:03:34 <akshayvyas> and that man is ??
15:03:45 <adamw> james bond?
15:03:56 <akshayvyas> :)
15:05:18 <adamw> okey dokey
15:05:21 <tflink> bond is good at breaking stuff, I suppose but I think I'd rather have Q working on that :)
15:05:50 <adamw> #topic Previous meeting follow-up
15:06:28 <adamw> #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 <adamw> #info "adamw to consider revisions to 'kickstart delivery method' criterion" - didn't get to that one yet, sorry
15:06:47 <adamw> 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 <tflink> nothing yet, no. I was waiting for the partitioning criteria
15:07:44 <tflink> 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 <adamw> #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 <adamw> hi jwb
15:09:32 <Viking-Ice> 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 <adamw> just a sec, let me topic up
15:10:03 <adamw> #topic Release criteria: partitioning criteria proposal
15:10:31 <adamw> 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 <adamw> #info adamw proposed revised partition criteria for F18+ to the list: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html
15:10:52 <adamw> discuss away!
15:11:04 <adamw> Viking-Ice: 'one or more hd criteria for the storage spoke' - what do you mean exactly?
15:11:31 <tflink> do we care about reuse of encrypted partitions?
15:11:50 <tflink> ie reusing LUKS setup if /home is encrypted
15:11:51 <kparal> ugh, I didn't get to that discussion today
15:11:54 * kparal reading it
15:13:20 <adamw> tflink: I think yeah we should cover that 'upgrade' scenario
15:13:21 <Viking-Ice> adamw, if you have one or more hd detected and install on to
15:13:23 <kparal> that means fully custom partitioning should be just in Final, right?
15:13:26 <adamw> i did miss that one out
15:13:26 <Viking-Ice> mena too
15:13:33 <Viking-Ice> mean mean frack!
15:13:52 <kparal> I have one concern about that - it wouldn't be tested as well (as if we required it in Beta)
15:14:13 <adamw> 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 <tflink> true but I think that reusing LUKS setup falls pretty well into the realm of custom partitioning
15:14:40 <adamw> kparal: the beta criteria i proposed require some specific abilities for the custom part code
15:14:52 <adamw> the second criterion is all stuff you can only do in custom part, in newUI
15:14:54 <kparal> adamw: oh, I have skipped one paragraph. now I see it
15:15:03 <Viking-Ice> 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 <adamw> and i'd agree with tflink that we should add 're-use existing /home' to that
15:15:39 <Viking-Ice> yeah re-use should be added to the criteria as well
15:15:46 <dlehman> existing LUKS is absolutely custom. always has been.
15:16:00 <adamw> dlehman: that's fine
15:16:24 <tflink> yeah, it kind of branched into two discussions - reusing existing home and reusing existing encrypted home
15:16:35 <adamw> tflink: re-use existing /home is also custom partitioning.
15:16:39 <Viking-Ice> I added a comment there on the blog post what probably is the expected expectation in that regard
15:17:02 <adamw> well, now i think about it
15:17:13 <Viking-Ice> which criteria could be built upon
15:17:15 <tflink> adamw: yeah, but I thought that we were talking about adding that particular use case to what is needed for beta
15:17:17 <adamw> if you have to use custom partitioning for something, then effectively, pre-f18, it was only required at final
15:17:19 <adamw> yeah
15:17:36 <adamw> 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 <tflink> adamw: good point, final is fine
15:18:35 <Viking-Ice> I tend to agree with kparal that custom partitioning fits in beta criteria ( alpha not required, beta required to work )
15:18:35 <adamw> so we might want to re-word the final criterion a bit to be less vague, rather than adding to beta
15:19:03 <adamw> 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 <adamw> heh :)
15:20:05 <Viking-Ice> 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 <adamw> Viking-Ice: well 'completely' would be 'passes the Final criterion'
15:21:11 <Viking-Ice> 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 <adamw> oh, here's a modification...
15:21:36 <adamw> change "Creating and assigning" to "Creating, destroying and assigning"
15:21:50 <adamw> or 'removing', whatever
15:22:04 <adamw> i'm looking at making sure the pre-18 *alpha* requirements are covered
15:22:04 <akshayvyas> adamw: +1
15:22:20 <adamw> one of which was the 'existing Linux partition' autopart method, which wiped existing linux installs but left windows alone
15:23:02 <adamw> 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 <adamw> Viking-Ice: is it that you want further requirements for custom part at beta beyond what's already proposed?
15:23:49 <dlehman> 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 <Viking-Ice> 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 <adamw> Viking-Ice: well that's what the currently proposed alpha criterion does, so no problem there
15:25:22 <adamw> and we only have multiboot in final, and we're not talking about final right now...
15:25:31 <dlehman> 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 <adamw> dlehman: eh, we don't _need_ to really, we can always clarify that at blocker review time, but maybe we could
15:26:05 <adamw> let me see how verbose it looks
15:26:46 <adamw> dlehman: actually, i think the current wording works fine
15:26:49 <dlehman> 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 <Viking-Ice> adamw, are we just talking about fixing the criteria for beta or fixing the criteria in general?
15:27:34 <adamw> Viking-Ice: well right now i'd like to focus on the specific partitioning criteria proposal on the list
15:27:42 <adamw> Viking-Ice: there's a topic later for 'general criteria revision ideas'
15:27:50 <dlehman> adamw: in that free space case, are we supposed to not install any bootloader?
15:28:08 <dlehman> no, I don't know what we used to do
15:28:10 <adamw> dlehman: yeah, i was just pondering that when i went quiet there
15:28:28 <adamw> 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 <adamw> although, strictly, the MBR isn't part of the 'existing partition table' or 'existing data', really. 'existing user data'?
15:28:59 <dlehman> maybe add something about offering to access preexisting encrypted devices?
15:29:01 <adamw> help? :)
15:29:03 <dlehman> (in custom)
15:29:24 <dlehman> existing partitions or filesystems?
15:29:27 <adamw> dlehman: well, access is needed only for re-use, right>?
15:29:30 <Martix> hi
15:29:32 <dlehman> right
15:29:38 <adamw> the one case we're specifically concerned about there is re-using an existing /home
15:29:55 <adamw> but then we also considered that, per the pre-f18 criteria, that wasn't actually required to work until final
15:30:06 <adamw> so if we add that to beta, we're _tightening_ the requirements
15:30:10 <adamw> i mean we can do that, but it's a consideration
15:30:12 <dlehman> I see
15:30:42 <adamw> 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 <adamw> Viking-Ice: so do you have anything you'd like to add to/remove from the beta criteria proposed?
15:33:15 <adamw> 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 <Viking-Ice> adamw, I actually would like to move the whole custom partitioning from final to beta
15:33:57 <dlehman> adamw: sounds okay to me
15:34:05 <tflink> adamw: what about /boot partitions?
15:34:16 <adamw> tflink: in relation to what?
15:34:25 <dlehman> Viking-Ice: if you're going to do that you'll have to do so at the beginning of a cycle
15:34:46 <adamw> 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 <Viking-Ice> dlehman, yup
15:34:49 <tflink> 'leaving the pre-existing partitions and data untouched' - does that apply to any existing /boot partitions
15:34:58 <adamw> tflink: per the above, yeah.
15:35:07 <adamw> an install re-using an existing /boot would have to be done through custom part.
15:35:12 <Viking-Ice> dlehman, so it would not be subjected for F18 but F19 if we change it
15:35:33 <adamw> 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 <Viking-Ice> adamw, ok
15:35:58 <adamw> the reason i want to get this done now, btw, is that it feeds into the 'should we freeze beta' discussion
15:36:13 <adamw> 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 <adamw> ditto for upgrade
15:36:52 <adamw> so here's what we have so far, modified from the list proposal:
15:37:00 <adamw> 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 <adamw> 2. "The installer's custom partitioning mode must be capable of the following:"
15:37:26 <adamw> 2a. "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
15:37:33 <adamw> 2b. "Creating encrypted partitions"
15:37:41 <adamw> 2c. "Rejecting obviously invalid operations without crashing"
15:37:58 <adamw> any specific proposed revisions to those, to be enforced for f18 beta?
15:38:14 <adamw> does anyone reckon we should include a requirement for re-using an existing /home at beta rather than final?
15:38:18 <tflink> we're leaving LVM for ginal?
15:38:28 <tflink> final
15:38:34 <adamw> tflink: i left LVM on the basis that anaconda team say it's really going to be de-emphasized for newui.
15:38:39 <adamw> LVM is The Past, btr is The Future.
15:38:50 <adamw> but we could change that if we think it's still important enough
15:38:57 <adamw> dlehman: wdyt?
15:39:18 <adamw> 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 <tflink> it's somewhat of a departure from previous requirements but yeah, btr seems like it will replace LVM at some point
15:39:50 <nirik> lvm still needed for encrypted tho right?
15:39:52 <adamw> 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 <tflink> adamw: I'd say that reuse of /home is OK for final
15:39:57 <adamw> nirik: no? you can encrypt a regular partition.
15:39:57 <dlehman> nirik: no
15:40:08 <Viking-Ice> "re-use" and "upgrade" criteria belong in the same milestone ( beta from my pov )
15:40:22 <tflink> encryption + LVM == pain (from my experience)
15:40:25 <nirik> ok, cool. I thought it was tied to lvm at one point.
15:40:34 <tflink> well, encrypting the VG == pain, anyways
15:40:57 <akshayvyas> so btrfs is default now
15:41:19 <adamw> akshaysth: not right now no, still ext4
15:41:20 <tflink> for F18? I thought that was still pending
15:41:24 <adamw> but i think the plan is for btrfs as default in future
15:41:34 <Viking-Ice> F20+
15:41:37 <dlehman> adamw: explicit inclusion of lvm in addition to plain partitions?
15:42:00 <adamw> Viking-Ice: i can see that, yeah, since the main use case for re-use is basically upgrading.
15:42:11 <Viking-Ice> yup
15:42:31 <adamw> 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 <akshayvyas> adamw: pointed the wrong one :)
15:43:11 <akshayvyas> akshaysth is someone else
15:43:24 <adamw> 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 <adamw> Viking-Ice: re-use of /home isn't at all as complex an operation as an upgrade installation is
15:43:47 <adamw> it doesn't really need months of testing, it just...either works or doesn't work
15:44:08 <tflink> adamw: reuse of non-encrypted home, sure
15:44:23 <adamw> true, encrypted home is a bit messier
15:44:34 <Viking-Ice> 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 <adamw> anyhow, we're now debating *strengthening* the proposed criteria, i don't hear anyone saying we should weaken them
15:44:50 <adamw> so should we approve what's proposed now as a baseline at least? we can always tighten things from there
15:44:50 <dlehman> 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 <adamw> 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 <tflink> seems like it could cause a lot of problems, no matter when it lands, I suppose
15:45:49 <adamw> tflink: we don't have them in the current beta proposal, dlehman was floating them,
15:45:51 <dlehman> Viking-Ice: that amounts to a sizable RFE, so not going to add that for F18.
15:46:39 <tflink> I'm not against the idea of requiring md and btrfs/lvm for beta as long as we're being reasonable
15:47:01 <adamw> 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 <Viking-Ice> adamw, then it falls just under the general custom partitioning criteria
15:47:16 <adamw> Viking-Ice: it'd certainly be covered by the existing final criterion yes
15:47:20 <tflink> adamw: works for me
15:47:24 <adamw> Viking-Ice: but we could also add it to beta if we want it to work by beta
15:47:25 <Viking-Ice> ack
15:47:42 <Viking-Ice> 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 <dlehman> 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 <adamw> 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 <Viking-Ice> dlack
15:49:01 <tflink> ack
15:49:01 <Viking-Ice> mean ack
15:49:06 <akshayvyas> ack
15:49:27 <adamw> 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 <kparal> ack
15:49:44 <tflink> 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 <adamw> #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 <tflink> that gets hard to write out in any reasonable way, though
15:50:36 <Viking-Ice> 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 <adamw> tflink: not really, i could add it to the wording of 2a) easily enough
15:50:53 <dlehman> tflink: probably, yes. I won't sign anything saying as much until I have time to reflect on it further, though.
15:50:58 <adamw> :P
15:51:14 <adamw> 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 <adamw> anyhoo, we have a baseline now at least
15:51:26 <adamw> and this is taking a while
15:51:36 <adamw> shall we move on to the upgrade criterion? which with any luck should be easier
15:52:17 <tflink> dlehman: ok, I wasn't looking for anything definitive today - mostly wondering whether the idea was unreasonable
15:52:33 <adamw> #action adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta
15:52:33 <tflink> adamw: yeah, that proposal has been pretty quiet as of late
15:53:01 <adamw> #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 <tflink> 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 <adamw> #info there is some support for requiring creation of LVs/advanced btrfs partitions/RAID to work at beta
15:54:54 <adamw> tflink: did you want a definite #action or is it OK to leave it vague?
15:55:14 <Viking-Ice> I prefer vague
15:55:24 <tflink> adamw: I'm fine with it being vague as long as we don't forget entirely
15:55:52 <adamw> 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 <adamw> #chair tflink kparal viking-ice
15:55:57 <zodbot> Current chairs: adamw kparal tflink viking-ice
15:56:09 <adamw> now you can #action yourself if you like :)
15:56:36 <adamw> #topic Release criteria: upgrade criteria proposal
15:56:56 <adamw> #info tflink quoted the current proposals at https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html
15:57:22 <adamw> 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 <adamw> 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 <adamw> anyone want to propose changes to it that haven't already been discussed?
15:58:10 * adamw +1 to the proposal
15:58:21 <tflink> +1
15:58:42 <Viking-Ice> we kinda have to decide how far back we expect official upgrade is supposed to work
15:59:22 <adamw> 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 <adamw> which is what we had previously.
15:59:53 <adamw> 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 <Viking-Ice> 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 <adamw> oh right
16:00:29 <adamw> iswym
16:00:35 <Viking-Ice> mean do we support upgrading from F1 to F18 beta?
16:00:35 <tflink> I think that the current wording of "previous stable release" is pretty clear - Fn-1 to Fn only
16:00:44 <adamw> with the current proposal it's the same as the previous one: we only support F(n-1)
16:00:57 <adamw> as far as f18 is concerned it probably makes sense not to change that now
16:01:05 <adamw> if we want to support n-2 we should probably make that f19 stuff
16:01:12 <tflink> agreed
16:01:13 <adamw> but you're right we still need to determine that
16:01:22 <tflink> that seems a bit much to change right before freeze
16:01:36 <adamw> and make other documentation consistent with whatever we ultimately agree development/qa will care about
16:02:02 <adamw> #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 <nirik> I could have sworn we had a packager guideline about caring about N-2... but nothing saying what upgrades were "supported"
16:03:08 <nirik> perhaps we could have N-1 as blocker, and N-2 as NTH? :) (but perhaps thats f19 as you said)
16:03:20 <adamw> 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 <nirik> yeah
16:03:33 <Viking-Ice> it makes sense we support N-2 as in F16 being supported to be upgraded to F18
16:03:43 <nirik> Viking-Ice: yeah, I agree with that too.
16:04:23 <tflink> the counter to that is stuff like usrmove and if it would be a problem to support multiple upgrade vectors
16:04:24 <adamw> 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 <Viking-Ice> adamw, our lazyness not testing it is no excuse ;)
16:04:49 <adamw> 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 <adamw> anyone else?
16:05:06 <Viking-Ice> could be a final upgrade criteria
16:05:07 <tflink> 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 <adamw> 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 <kparal> 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 <adamw> anyway, again we can at least accept that we want *at least* the current proposal
16:06:23 <adamw> which is the important thing for the 'should we freeze' discussion
16:06:25 <adamw> so...
16:06:26 <Viking-Ice> let's clarify that then for F19
16:06:33 <Viking-Ice> ack on the current proposal
16:06:35 * tflink is still +1 for current proposals
16:06:45 <adamw> propose #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted
16:06:51 <tflink> ack
16:06:53 <Viking-Ice> ack
16:07:07 <kparal> ack
16:07:20 * nirik re-reads
16:07:27 <adamw> #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 <nirik> so is the 'or' in final intended?
16:07:33 <tflink> wait, does that link point to the actual criterion proposal?
16:07:46 <tflink> it contains them, nvm
16:07:51 <adamw> nirik: what 'or'?
16:07:59 <adamw> oh
16:08:13 <adamw> hm.
16:08:14 <nirik> minimal or blocking desktop
16:08:19 <adamw> it's meant to mean 'all of these', not 'any of these'
16:08:24 <adamw> 'or' is a bit ambiguous
16:08:24 <nirik> shouldn't that be 'minimal and all blocking desktops' ?
16:08:47 <adamw> 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 <adamw> 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 <adamw> tflink: we define 'release-blocking desktops' in the preamble
16:10:02 <adamw> oh, iswym, that might work
16:10:06 <Viking-Ice> we should not be supporting multiple *de installs et al from my pov
16:10:12 <adamw> nirik: is that OK with you or do you want to nail down the wording now?
16:10:22 <adamw> 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 <nirik> sure. I think we all agree on intent.
16:10:40 <Viking-Ice> yup
16:10:53 * kparal back in a few minutes
16:10:54 <nirik> the set of: minimal and (seperately) each release blocking desktop
16:10:56 <nirik> or something
16:11:02 <adamw> 'yeah, something like that, but more elegant :)
16:11:20 <nirik> right
16:11:27 <adamw> #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 <Viking-Ice> ack
16:11:42 <nirik> ack
16:11:54 <adamw> #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 <adamw> (just so we have that clearly noted)
16:12:14 <adamw> alrighty!
16:12:23 <tflink> adamw: how can you have minimal, gnome and kde installed at the same time?
16:12:26 <tflink> :-D
16:12:28 * tflink ducks
16:12:31 * adamw throws things at tflink
16:12:34 <adamw> d'oh, you're way ahead of me
16:12:45 <adamw> ok, this is really dragging on, so let's move straight to the pre-freeze discussion
16:12:56 <adamw> #topic Fedora 18 Beta status: freeze-worthy?
16:13:13 <Viking-Ice> nope
16:13:43 <Viking-Ice> we need to delay the freeze until the upgrade tool is in place
16:13:43 <tflink> there's a bunch of stuff that I haven't even tried to poke at yet
16:13:44 <adamw> #info FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta
16:14:05 <adamw> #info the idea is that we freeze only once the code required by the Beta criteria is broadly in place
16:14:05 <tflink> but I would agree that without a testable upgrade tool, there's little point in entering freeze
16:14:13 <adamw> yeah, i agree with that too
16:14:14 <nirik> freeze is scheduled to start 2012-10-09 currently.
16:14:22 * nirik nods.
16:14:42 <adamw> it's noted on the FESCo ticket that the upgrade tool code technically exists: https://github.com/wgwoods/fedup
16:14:50 <adamw> but afaik there has been no release yet, and i don't know if it's in working state.
16:15:01 <adamw> dlehman: do you have any info there?
16:15:02 <Viking-Ice> wwoods, around?
16:15:29 <dlehman> no idea about the upgrade tool
16:16:02 <adamw> nirik: fesco is looking at it this week right, though? since next week's meeting will be 10-10
16:16:13 <nirik> I think so... let me look
16:16:42 <adamw> dlehman: the other thing that we just agreed, that i'm not sure of the status of: error handling
16:16:54 <nirik> yes, it should be this week.
16:17:05 <adamw> #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 <adamw> dlehman: is error handling in yet? i.e. will anaconda still just crash if you do something wrong in custom part?
16:17:43 <tflink> I would argue that we need ~ 24 hours to poke at any released upgrade tool before determining whether it's testable
16:17:47 <dlehman> adamw: error handling is largely complete during configuration, but we haven't done much for errors that occur during actual install
16:18:01 <Viking-Ice> tflink, atleast 24 hours
16:18:17 <adamw> dlehman: well the criterion covered partitioning specifically, so if we're handling errors during custom part that's probably okayish.
16:18:44 <tflink> 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 <adamw> 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 <adamw> wwoods: what's the current state of fedup?
16:19:39 <tflink> that seems rather unfortunately named, but as long as it works ...
16:19:40 <wwoods> it's a work in progress. it'll be testable soon.
16:19:50 <adamw> tflink: i suspect humour
16:19:57 <adamw> wwoods: can you put a date on 'soon'?
16:19:59 <wwoods> it's short for "Fedora Upgrader", obviously
16:20:02 <wwoods> adamw: no.
16:20:16 <wwoods> or: "before the freeze"
16:20:16 <dlehman> adamw: yes, the criteria are largely covered as of now.
16:20:26 <tflink> adamw: as do I, but the meaning of "fed up" has other connotations which don't inspire confidence
16:20:27 <Viking-Ice> that kinda answers that
16:20:59 <Viking-Ice> we delay the freeze
16:21:41 <wwoods> okay so here's more info.
16:22:17 <wwoods> the CLI frontend is basically done, at least for a beta of a 1.0 release
16:22:23 <wwoods> the GUI is coming along
16:22:56 <wwoods> 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 <wwoods> otherwise we'll run it from an external system image like anaconda used to
16:24:09 <wwoods> I've been talking to mizmo a bit about a plymouth progress screen for the upgrade
16:24:29 <wwoods> should have something testable.. sometime before the freeze, which I understand to be 10/10
16:25:03 <adamw> okay
16:25:16 <adamw> #info wwoods says fedup should be testable before freeze
16:25:16 <tflink> is the decision to delay freeze being made @ FESCo on wednesday, or just discussed?
16:25:20 <adamw> wwoods: it's 10/9 not 10/10.
16:25:25 <adamw> tflink: not sure
16:25:36 <wwoods> ah, yep. that's what I have on my calendar.
16:25:46 <adamw> #info dlehman says current partitioning code covers the criteria as accepted earlier in the meeting
16:26:04 <adamw> so...i'd say we think the current state of things isn't freeze-able
16:26:18 <adamw> but if fedup is indeed testable by 10/9 we'd say that is freeze-able
16:26:19 <tflink> adamw: agreed
16:26:21 <adamw> right?
16:26:46 <adamw> anyone have any other areas they're worried about for beta freeze, any other requirements i missed?
16:26:53 <tflink> PXE
16:27:27 <Viking-Ice> that can mean alot of things are you refering to kickstart installs ?
16:27:30 <adamw> oh, that's beta isn't it, what's the status of that?
16:27:33 <dlehman> adamw: device encryption is still in development
16:27:47 <tflink> adamw: not sure, haven't gotten around to trying it yet
16:27:52 <adamw> 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 <adamw> 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 <Viking-Ice> adamw, tflink mentioned PXE
16:28:15 <tflink> how are we defining testable for upgrade - something that compiles and starts to run?
16:28:16 <adamw> yeah
16:28:30 <adamw> tflink: my wibbly concept is 'the code is there'
16:29:04 <kparal> PXE with http repo works
16:29:16 <kparal> I couldn't test nfs repo yet
16:29:29 <adamw> that sounds freezeable to me
16:29:32 <adamw> (for pxe)
16:29:35 <Viking-Ice> yup
16:29:52 <tflink> did nfs work for alpha?
16:29:56 <kparal> no
16:30:24 <kparal> there is a bug somewhere around I intend to verify
16:30:25 <tflink> that would be another area of concern unless someone else has tried it
16:30:36 <tflink> OK, it sounds addressed, at least
16:30:37 <kparal> but I was sick for the last few days so I didn't get to it
16:31:27 <tflink> serial console?
16:31:45 <adamw> i think that's in
16:31:54 <adamw> ok so how about this
16:32:46 <adamw> 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 <Viking-Ice> ack
16:33:49 <kparal> sounds good
16:33:50 <tflink> that works
16:36:24 <adamw> #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 <adamw> ok, i have to run right now
16:36:32 <adamw> tflink/kparal, can you take over?
16:36:40 <adamw> either wind things up or do a blocker review, whatever people feel like
16:37:06 <tflink> yeah, can do
16:37:36 <kparal> I would prefer leaving the blocker review to wednesday
16:37:43 <Viking-Ice> yup
16:37:47 <tflink> we're already at 1.5 hours, do we really want to do a blocker review?
16:37:52 <tflink> sounds like not so much :)
16:37:56 <Viking-Ice> ;)
16:38:11 <tflink> but reviewing blocker bugs is _so_ much fun ...
16:38:28 <tflink> if there are no objections, we can move on to open floor
16:38:53 <Viking-Ice> let's move to open floor
16:39:04 <tflink> #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 <tflink> Anything else before we finish up?
16:40:01 <tflink> 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 <Viking-Ice> do the countdown
16:41:54 <tflink> if there's nothing else - I'm setting the fuse for [0,5] minutes
16:44:07 <tflink> Thanks for coming everyone!
16:44:10 <tflink> #endmeeting