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