From Fedora Project Wiki
Attendees
- adamw (138)
- tflink (101)
- kparal (73)
- jreznik (30)
- Martix (19)
- cmurf (16)
- zodbot (9)
- mkrizek (4)
- wsirc_4772732 (4)
- jskladan (3)
- maxamillion (1)
Agenda
- Previous meeting follow-up
- Fedora 18 Beta status / mini blocker review
- Release criteria / test cases
- Open floor
Previous meeting follow-up
- tflink try again with asking other teams to review the updated release criteria - tim forgot about this, he'll do it now
- adamw to update fesco freeze ticket - this was done
Fedora 18 Beta status / mini blocker review
- The new upgrade tool was still not ready, Will says he will have it ready this week if all goes well
- Agreed that QA still could not recommend freezing for Beta as new upgrade tool is still not available for testing: we would pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures
- TC6 seemed a decent build, we would continue with the validation testing
Mini blocker review
- #866519 was accepted as a blocker per RAID partitioning criterion
- #867296 was left undetermined until further data could be obtained
- #868777 was left undetermined until further data could be obtained
Release criteria / test cases
- Adam was still working on the partitioning criteria, general agreement at the meeting that requirements for custom partitioning should not be heavy at beta time
- Many test cases still needed revising for newui, if you feel like helping out, please do
Open floor
N/A
Action items
- adamw to report recommendation to fesco ticket
IRC Log
| adamw | #startmeeting Fedora QA meeting | 15:00 |
|---|---|---|
| zodbot | Meeting started Mon Oct 22 15:00:08 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 15:00 |
| adamw | #meetingname fedora-qa | 15:00 |
| zodbot | The meeting name has been set to 'fedora-qa' | 15:00 |
| adamw | #topic roll call | 15:00 |
| * kparal joins | 15:00 | |
| adamw | morning folks | 15:00 |
| * jreznik is ready | 15:00 | |
| * mkrizek is here | 15:00 | |
| jreznik | morning adamw! /me would sleep... | 15:00 |
| * tflink is present | 15:01 | |
| adamw | don't worry, i pretty much am. | 15:01 |
| * wsirc_4772732 is watching.. :-) | 15:02 | |
| adamw | #topic previous meeting follow-up | 15:02 |
| adamw | " tflink try again with asking other teams to review the updated release criteria " - what happened there, tim? | 15:02 |
| tflink | forgot, again. writing email now | 15:03 |
| * Martix is here | 15:03 | |
| adamw | #info "tflink try again with asking other teams to review the updated release criteria" - tim forgot about this, he'll do it now | 15:03 |
| adamw | #info "adamw to update fesco freeze ticket" - I did that | 15:04 |
| adamw | #topic Fedora 18 Beta status / mini blocker review | 15:04 |
| adamw | well, it's groundhog day again, folks | 15:04 |
| maxamillion | it is? | 15:04 |
| adamw | it is | 15:04 |
| adamw | we're still on Beta TCs and we're still waiting for the new upgrade tool. | 15:05 |
| jreznik | it is, for me the latest status from wwoods looks like we can be happier this time | 15:05 |
| jreznik | wwoods: are you around? | 15:05 |
| kparal | should we start creating backup plans? | 15:05 |
| adamw | could you report that again for the meeting? | 15:05 |
| tflink | jreznik: something testable and packaged? | 15:05 |
| adamw | tflink: no, but there's GOING to be, honest guv, we really mean it this time. | 15:05 |
| kparal | what the 'contingency' section of our feature page says? | 15:05 |
| jreznik | tflink: not packaged but should be in the state "ready for qa to take a look on" | 15:05 |
| jreznik | kparal: but I'm +1 for creating backup plan | 15:06 |
| tflink | sounds like I know what I'm going to be doing today :) | 15:06 |
| tflink | I'm not sure what we can do other than ship beta w/o upgrade | 15:06 |
| tflink | or endorse yum upgrades | 15:06 |
| adamw | kparal: 1) there is no feature page for this, it's part of anaconda newui. 2) anaconda newui feature explicitly says there is no contingency plan after a merge into rawhide. to sum up, the contingency plan says "suck it". | 15:07 |
| tflink | but then again, I'm not the upgrade tool expert | 15:07 |
| kparal | right, yum updates | 15:07 |
| adamw | yeah, yum is our only option. | 15:07 |
| kparal | if yum upgrade works reasonably enough, it can be a backup plan | 15:07 |
| * jreznik definitely tend to freeze now, we already avoided two weeks of being frozen... | 15:07 | |
| jreznik | at least to have some "force" basis to push things forward | 15:08 |
| tflink | jreznik: I'm not sure I follow you if nothing has changed from the last 2 weeks - same state | 15:08 |
| adamw | the only problem i have with that is that we have to be clear we're making such a decision entirely and only due to time pressure, there's no other reason to make a different decision this week than we did last week | 15:08 |
| adamw | (that applies to QA and to fesco) | 15:08 |
| jreznik | adamw: yep, from this side - there's no, it's not done - on the other hand, latest status gives some chance that there was some move and with some luck, we can have it this week | 15:09 |
| adamw | well, okay. there's will saying he's sure he'll get it done THIS week. but then it was planned to be done the week before and also last week, so pardon me for not placing a high reliability value on said prediction :) | 15:09 |
| tflink | adamw: +1 - nothing against will but upgrades are complicated. I'd hesitate freezing this week even if we get something testable today - who knows what issues are lurking | 15:10 |
| adamw | i think personally i'd like to be awkward and recommend a slip again | 15:10 |
| adamw | fesco of course can go against our recommendation...i think if it's anyone's job to be considering time pressure and voting for fudges it's fesco's, not ours. | 15:10 |
| kparal | F18 will be the most polished release ever :) | 15:10 |
| adamw | what does everyone else think? | 15:11 |
| tflink | we could freeze and move go/no-go up a week, I suppose if the matrices are in good shape (haven't checked TC6 yet) | 15:11 |
| * jskladan is here | 15:11 | |
| tflink | +1 freeze slip | 15:11 |
| wsirc_4772732 | +1 freeze slip | 15:11 |
| adamw | whoever signed in via webirc can you identify yourself, just so we know who you are in the logs? thanks :) | 15:12 |
| Martix | F18 should enter freeze | 15:12 |
| adamw | #info new upgrade tool is still not ready, Will says he will have it ready this week if all goes well | 15:12 |
| kparal | I have no really hard opinion here. fedup looks like a pony, having yum as a Beta backup and freezing doesn't sound that bad | 15:12 |
| adamw | kparal: then why didn't we do that last week or the week before? | 15:12 |
| Martix | kparal: +1 | 15:12 |
| * wsirc_4772732 is t.bubeck@reinform.de a fedora ambassador and packager. Sorry, but I am on customer site.. | 15:12 | |
| kparal | adamw: because we believed it would be done soon | 15:12 |
| adamw | wsirc_4772732: no problems, thanks :) | 15:12 |
| jreznik | kparal: yep, I tend more trying a backup option | 15:12 |
| Martix | adamw: because we had faith in empty promises from fedup developers :-) | 15:13 |
| adamw | @info wsirc_4772732 is t.bubeck | 15:13 |
| adamw | grr | 15:13 |
| adamw | #info wsirc_4772732 is t.bubeck | 15:13 |
| jreznik | Martix: yep... | 15:13 |
| jreznik | I asked kparal last week to prepare on the backup solution :) | 15:13 |
| adamw | okay. well, i mean, we've always had yum. | 15:13 |
| adamw | my problem with yum is more about messaging than optics - we've always said that yum isn't a supported/recommended upgrade option and people should use the 'proper' tools because yum can't possibly handle upgrades 100% reliably. | 15:14 |
| adamw | now when our proper tool isn't done we're like 'oh, just use yum, it'll be fine'? eh. | 15:14 |
| kparal | adamw: I agree, it seems like a Fedora failure | 15:14 |
| Martix | adamw: we can test yum and try to fix issues | 15:14 |
| kparal | but this whole situation is a sort of a failure | 15:15 |
| tflink | adamw: agreed about the messaging | 15:15 |
| * jreznik understands... but are we willing to wait month for the tool? two, three? ;-) | 15:15 | |
| Martix | or find workaround which will work for everybody | 15:15 |
| Martix | *workarounds | 15:15 |
| adamw | jreznik: like i said, i see that as a fesco issue, not a QA one. | 15:15 |
| tflink | jreznik: that's a good question but not a QA issue | 15:15 |
| adamw | jreznik: we're making a recommendation based on QA considerations, time pressure is your consideration. | 15:15 |
| kparal | the first time we postponed freeze, we should have set a maximum wait deadline | 15:15 |
| jreznik | adamw, tflink: yep, it is - but I'd like to offer fesco an alternative - if QA could help with testing... | 15:16 |
| tflink | kparal: why? How is that different from voting every week | 15:16 |
| adamw | jreznik: well, the alternative is as discussed, unfreeze and have yum as a backup plan. yum upgrade is already pretty well documented. | 15:16 |
| kparal | tflink: because then adamw asks - what is different this week? :) | 15:16 |
| adamw | =) | 15:16 |
| adamw | i'm always the awkward one | 15:16 |
| tflink | jreznik: I'll help test whatever we need to but I'm against accepting yum as a recommended upgrade method | 15:16 |
| adamw | if we don't have consensus i can write a split recommendation in the fesco ticket and we can dump it on them. it's their fault for not running the feature process properly anyway. =) | 15:17 |
| jreznik | tflink: fair enough | 15:17 |
| kparal | from QA standpoint, as adamw puts it, yes, postponing freeze is better | 15:17 |
| adamw | or we can say that from a QA standpoint we recommend slip but we recognize FESCo may consider time issues that we don't | 15:17 |
| * jreznik does not want to influence QA decision based on time pressure... | 15:17 | |
| kparal | and we also agree that there is a working alternative - yum | 15:18 |
| kparal | even though controversial | 15:18 |
| tflink | is it really wise to put off upgrade testing until final" | 15:18 |
| Martix | btw what fedup is meant to do better then yum distro-sync+permissive selinux? | 15:18 |
| kparal | tflink: I wonder whether yum backup plan would stay also in Final | 15:18 |
| jreznik | kparal: I can take that "dirty" thing from your hands | 15:18 |
| Martix | we dont have "problem" features like /usr move in F17 | 15:18 |
| adamw | kparal: as tflink says the issue isn't so much having a working upgrade option | 15:18 |
| adamw | kparal: it's about *testing* our upgrade | 15:19 |
| tflink | I'd say that we're +1 freeze slip unless fesco endorses yum as a recommended upgrade tool | 15:19 |
| kparal | tflink: for F18 Final, right? | 15:19 |
| tflink | and I'm not crazy about saying "yum is recommended only for beta" | 15:19 |
| tflink | kparal: for beta | 15:19 |
| * adamw puts entirely arbitrary 5 minute limit on further discussion | 15:20 | |
| tflink | I'm very strongly against changing the release criteria just for a beta | 15:20 |
| adamw | okay, how about a vote | 15:20 |
| tflink | if fesco wants to recommend yum as an upgrade method, fine. I'd like to know who's going to fix any bugs that come up and handle the discussion in F19 about whether or not yum is a recommended tool for upgrade | 15:20 |
| Martix | ok, only problem change is DisplayManagerRework | 15:21 |
| jreznik | tflink: with offline updates I'd say yum will be never endorsed as recommended tool at all | 15:21 |
| adamw | propose #agreed QA still cannot recommend freezing for Beta as new upgrade tool is still not available for testing: we will pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures | 15:21 |
| tflink | jreznik: so we'd be fudging the release criteria for beta and possibly final? | 15:22 |
| kparal | ack | 15:22 |
| tflink | adamw: works for me | 15:22 |
| mkrizek | ack | 15:22 |
| tflink | wait, what about beta slips? | 15:23 |
| wsirc_4772732 | ack | 15:23 |
| tflink | do we want to go into freeze without fesco deciding on a backup plan? | 15:23 |
| tflink | I'd still rather slip freeze than slip after freeze | 15:23 |
| adamw | tflink: want me to patch it to ask fesco to address post-freeze concerns? | 15:23 |
| jreznik | tflink: in this wording for fesco ticket it's definitely slip before freeze | 15:24 |
| tflink | adamw: yeah | 15:24 |
| tflink | jreznik: I'd still rather slip before freeze than during | 15:24 |
| adamw | tflink: i can add it as a #info it'd be too long for the #agreed | 15:24 |
| jreznik | tflink: yep, it's all we are talking about right now | 15:24 |
| tflink | if we're going to still slip for the upgrade tool, I don't see how entering freeze now is any better than slipping freeze and pushing go/no-go up a week | 15:25 |
| jreznik | otherwise we would go through the standard go/no-go process without the fesco approval | 15:25 |
| adamw | so we want fesco to have a definite plan for shipping without the upgrade tool being ready, if it votes to freeze now | 15:25 |
| adamw | i can note that. | 15:25 |
| adamw | #agreed QA still cannot recommend freezing for Beta as new upgrade tool is still not available for testing: we will pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures | 15:25 |
| tflink | adamw: a second #agreed for that? | 15:26 |
| adamw | #info if FESCo votes to freeze now we would like them to have a definite plan for how Beta can be shipped without the upgrade tool ready, we do not want to see post-freeze slips due to the upgrade tool | 15:26 |
| adamw | tflink: i think it's okay as an info? | 15:26 |
| tflink | ok | 15:26 |
| tflink | jreznik: are you updating the fesco ticket? | 15:26 |
| Martix | tflink: consider other devel teams which takes advantage of opened window before freeze and trying to push more feature which could break F18 more | 15:26 |
| adamw | #action adamw to report recommendation to fesco ticket | 15:27 |
| jreznik | tflink: I can do it, for sure | 15:27 |
| adamw | Martix: they shouldn't be pushing anything major outside of the feature process. | 15:27 |
| tflink | Martix: sure, that's possible but it hasn't seemed to happen yet. is that really all that worse than freezing for 3-5 weeks? | 15:27 |
| jreznik | adamw: should not... | 15:27 |
| tflink | and if something bad gets pushed, it can be fixed during freeze or unpushed | 15:28 |
| tflink | unpushed/undone etc. | 15:28 |
| jreznik | tflink: it's more about finding the right point when disadvantages kills all advantages get by non freezing | 15:28 |
| tflink | if it's something that's not undoable and can't be fixed during freeze, I think we're in trouble no matter what | 15:28 |
| Martix | adamw: tflink I heard from some devs that they like freeze slip because they have more time for pushing new code to F18 | 15:28 |
| tflink | Martix: that was part of the point for slipping freeze | 15:29 |
| tflink | so that other development isn't held up | 15:29 |
| jreznik | to not disrupt devels | 15:29 |
| tflink | and we don't end up in the same situation as alpha "we've been frozen too long already, just ship the damn thing" | 15:29 |
| adamw | i think we're just skating over old ground here | 15:30 |
| jreznik | and I'm trying to talk to the people doing bigget changes to be more conservative | 15:30 |
| adamw | any objections to moving on? | 15:30 |
| jreznik | adamw: move on ;-) | 15:30 |
| tflink | no, I think we've covered the QA related stuff well, the rest of it is PM | 15:30 |
| adamw | okay | 15:30 |
| adamw | #info Beta TC5 and TC6 came out over the weekend | 15:30 |
| adamw | anyone have any headline news from TC5 or TC6 testing? | 15:30 |
| kparal | works reasonably it seems | 15:31 |
| adamw | i don't see any showstopping fails | 15:31 |
| kparal | NM crashes are gone | 15:31 |
| jreznik | works quite good for me | 15:32 |
| adamw | okay, cool | 15:32 |
| mkrizek | so far so good for me too | 15:32 |
| adamw | #info TC6 seems a decent build, we will continue with the validation testing | 15:32 |
| Martix | I got crash when removing old partitions, but unable to reproduce it | 15:33 |
| jreznik | I just hit the reclaiming issues - kparal is right, preserve/delete is really confusing | 15:33 |
| adamw | there's a lot of fixed blockers to verify so please everyone check through that list | 15:33 |
| adamw | and provide karma on the anaconda update so we can push it stable | 15:33 |
| adamw | that'll clean out a lot of stuff from the blocker list | 15:33 |
| Martix | too many option permutations to test and just some crashes :-/ | 15:33 |
| adamw | #info please provide + karma for the anaconda update if TC6 is working reasonably for you | 15:33 |
| kparal | anaconda is already going stable | 15:34 |
| adamw | ah okay, cool | 15:34 |
| adamw | #undo | 15:34 |
| zodbot | Removing item from minutes: <MeetBot.items.Info object at 0x22677e90> | 15:34 |
| adamw | tflink, do you want to go through the proposed blockers quick? | 15:34 |
| adamw | note I just added the VNC bug to the proposed blocker list | 15:34 |
| adamw | that's https://bugzilla.redhat.com/show_bug.cgi?id=868777 | 15:34 |
| tflink | adamw: sure but I don't see much to go through | 15:34 |
| adamw | #chair tflink kparal | 15:34 |
| zodbot | Current chairs: adamw kparal tflink | 15:34 |
| adamw | 866519 looks like it could be voted on | 15:35 |
| * tflink is skipping all the upgrade related bugs | 15:35 | |
| tflink | #topic (862784) newUI custom partitioning does not allow formatting of an existing partition for use in the installed system | 15:36 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=862784 | 15:36 |
| tflink | #info Proposed Blocker, anaconda, NEW | 15:36 |
| adamw | this is kinda tied to the partitioning criteria revie | 15:36 |
| adamw | w | 15:36 |
| adamw | personally i'm not in favour of requiring this to work for beta, there's too many other ways to do it | 15:36 |
| tflink | yeah, I should have skipped it | 15:36 |
| tflink | #undo | 15:37 |
| zodbot | Removing item from minutes: <MeetBot.items.Info object at 0x176259d0> | 15:37 |
| tflink | #undo | 15:37 |
| zodbot | Removing item from minutes: <MeetBot.items.Link object at 0x291e67d0> | 15:37 |
| tflink | #undo | 15:37 |
| zodbot | Removing item from minutes: <MeetBot.items.Topic object at 0x2e60b990> | 15:37 |
| tflink | #topic (866519) BIOS RAID is not shown on harddrive screen | 15:37 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=866519 | 15:37 |
| tflink | #info Proposed Blocker, anaconda, NEW | 15:37 |
| tflink | we're already +2 blocker on this (adamw, tflink) from bz | 15:37 |
| Martix | +1 betablocker | 15:38 |
| tflink | proposed #agreed 866519 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" | 15:38 |
| adamw | ack | 15:39 |
| mkrizek | ack | 15:39 |
| tflink | anyone else? | 15:39 |
| kparal | I read quickly, but seems like ack | 15:40 |
| adamw | it's pretty straightforward, yeah. | 15:40 |
| kparal | ack | 15:40 |
| tflink | #agreed 866519 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" | 15:40 |
| tflink | #topic (867296) NameError: global name 'gtk_call_once' is not defined | 15:41 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=867296 | 15:41 |
| tflink | #info Proposed Blocker, anaconda, ON_QA | 15:41 |
| kparal | this was verified already | 15:41 |
| tflink | it was? | 15:42 |
| kparal | with no comment | 15:42 |
| kparal | yes, look at History | 15:42 |
| adamw | we still have no information on this | 15:42 |
| adamw | dan verified it. | 15:42 |
| adamw | i'm happy just to punt on this again and let it die a natural death... | 15:42 |
| tflink | but it's still ON_QA | 15:42 |
| tflink | oh, I see | 15:42 |
| tflink | works for me | 15:43 |
| kparal | it's the Bodhi madness | 15:43 |
| adamw | i've filed a ticket on Bodhi doing that, btw. | 15:43 |
| kparal | adamw: can you send me a number or CC me? | 15:43 |
| tflink | proposed #agreed 867296 - There is still not enough information on this to decide on blocker status, will re-visit when there is more information available | 15:43 |
| kparal | let's skip all verified bugs? | 15:43 |
| kparal | ack | 15:44 |
| adamw | kparal: will do | 15:44 |
| adamw | ack | 15:44 |
| Martix | agreed | 15:44 |
| tflink | kparal: that's generally the plan but it didn't show up as VERIFIED when I started | 15:44 |
| tflink | #agreed 867296 - There is still not enough information on this to decide on blocker status, will re-visit when there is more information available | 15:44 |
| kparal | tflink: yes, most of them is not verified, because Bodhi switched it all to ON_QA | 15:45 |
| tflink | kparal: we can skip all the accepted blockers | 15:46 |
| tflink | #topic (868777) fail to install the system use vnc | 15:46 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=868777 | 15:46 |
| tflink | #info Proposed Blocker, anaconda, NEW | 15:46 |
| tflink | how often is this happening? | 15:47 |
| adamw | if this is timing-based then that complicates things, but it looks pretty blockery | 15:47 |
| adamw | "How reproducible: | 15:47 |
| adamw | sometimes - depends on dhcp lease" | 15:47 |
| tflink | I wonder how many people are doing VNC + media | 15:47 |
| kparal | quite a few, I think. at least some of my colleagues | 15:48 |
| kparal | with remote servers | 15:48 |
| tflink | if the server is remote, how are they using media? | 15:48 |
| kparal | cobbler or something | 15:48 |
| tflink | but that's not media based | 15:48 |
| kparal | hmm, right, I'm not fully sure it is netinst | 15:49 |
| tflink | with the information we have, I'm not -1 but I'm not fully +1, either | 15:49 |
| tflink | I'd like to see more testing with PXE | 15:49 |
| adamw | what more info would you like to have? | 15:49 |
| kparal | I can do that | 15:49 |
| tflink | if it's just media + vnc + dhcp, I'm not sure this is a clear blocker | 15:50 |
| kparal | I think it is a full-fledged blocker | 15:50 |
| kparal | but I can re-test with pxe boot | 15:51 |
| adamw | i'm okay to go along with that. | 15:51 |
| tflink | I'm not -1 blocker, I'm just not sure about slipping if this was the last blocker at go/no-go | 15:51 |
| kparal | hmm, it might not related to PXE, because PXE boots from network | 15:52 |
| kparal | that's why comment 4 says only media | 15:52 |
| kparal | with PXE your network is already up | 15:52 |
| tflink | potential workarounds: use static IP during install, use monitor (if you have access to do media, you probably have physical access and don't 100% need VNC) | 15:52 |
| tflink | kparal: yeah, that's what I was wondering - PXE gets an ip before booting the installer env | 15:53 |
| kparal | but booting from kernel pair in VM could trigger it | 15:53 |
| kparal | but VM has probably very fast dhcp | 15:53 |
| tflink | good point | 15:53 |
| kparal | unless you have it bridged | 15:53 |
| tflink | any other votes? | 15:53 |
| kparal | and I don't | 15:53 |
| tflink | I see an implicit +1 from kparal and a +/- 0 from me | 15:54 |
| adamw | i'm with tflink | 15:54 |
| kparal | that means I still win :-) no, really, what that means, punt? | 15:55 |
| tflink | proposed #agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this? | 15:55 |
| kparal | patch | 15:56 |
| kparal | does static IP assignment work? | 15:56 |
| kparal | might be a good question to ask | 15:56 |
| tflink | proposed #agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this? Is using a static IP a valid workaround? | 15:56 |
| adamw | ack | 15:56 |
| kparal | ack | 15:57 |
| tflink | #agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this? Is using a static IP a valid workaround? | 15:58 |
| adamw | i think we lost everyone else | 15:58 |
| tflink | yeah, do we want to go through the accepted blockers that aren't ON_QA or VERIFIED? | 15:58 |
| adamw | no | 15:59 |
| adamw | we never do at this meeting, just proposed | 15:59 |
| tflink | ok, works for me | 15:59 |
| adamw | we only do the mini review in this meeting to clean out the proposed list | 15:59 |
| adamw | so, we have a couple other topics, but if there's only the three of us here, not much point discussing them | 15:59 |
| adamw | anyone else around for criteria / test case discussion? | 15:59 |
| jskladan | yaay | 15:59 |
| jskladan | criteria | 16:00 |
| kparal | :D | 16:00 |
| * kparal pokes mkrizek | 16:00 | |
| * cmurf is lurking | 16:00 | |
| tflink | it'd be nice to have some anaconda folk if we're talking about the partitioning criteria | 16:00 |
| adamw | #topic Release criteria / test cases | 16:00 |
| adamw | so yeah...i'm still kinda struggling with the partitioning criteria | 16:01 |
| adamw | only had one reply to my last mail about the overall approach to take, from cmurf (thanks cmurf) | 16:01 |
| adamw | so i'm not sure what the feeling is there | 16:01 |
| cmurf | It's a tedious subject that's for sure, I don't envy anyone deeply involved in this. | 16:02 |
| adamw | heh. | 16:02 |
| adamw | so does anyone have an opinion on whether we really need to be requiring a lot of functionality from custom part at beta at all? aside from me and cmurf? | 16:02 |
| * kparal digging through archives | 16:04 | |
| tflink | define a lot - I like the approach of requiring what we did before regardless of whether it's autopart or not any more | 16:04 |
| cmurf | FWIW I'm very conservative / set low expectations for custom partitioning given a whole new installer. My main thought is to test for data loss. That's the scenario most worth avoiding. Functionality I consider icing on the cake. | 16:05 |
| tflink | but I'm not really a fan of requiring too much custom partitioning @ beta | 16:05 |
| cmurf | tflink: exactly my position | 16:05 |
| adamw | kparal: you mean you don't keep all my posts open on your desktop for regular reading?! | 16:05 |
| adamw | .fire kparal | 16:05 |
| zodbot | adamw fires kparal | 16:05 |
| adamw | https://lists.fedoraproject.org/pipermail/test/2012-October/110967.html | 16:05 |
| kparal | I pin them to the wall | 16:05 |
| adamw | they better be framed | 16:05 |
| kparal | I just don't have enough walls, so they are layered | 16:05 |
| tflink | I layer my hamster's cage with them :) | 16:06 |
| * tflink doesn't actually have a hamster | 16:06 | |
| cmurf | You guys have enough paper in your printers for this? Or does the shrink setting actually go that low? | 16:06 |
| adamw | that's somehow even wrose. | 16:06 |
| adamw | that's right. poke the tiger. | 16:07 |
| cmurf | haha | 16:07 |
| tflink | ooh, tiger ... | 16:07 |
| Martix | cmurf: talking about shrinking filesystems... | 16:07 |
| cmurf | ? | 16:08 |
| adamw | so i guess in general folks are in favour of the minimal option, okay. | 16:08 |
| * kparal finished refreshing his memories | 16:08 | |
| Martix | cmurf: is it supposed to work? | 16:08 |
| adamw | kparal: wdyt? | 16:09 |
| cmurf | Martix: btrfs? I'm not shrinking, I'm trying to migrate extents from a smaller device to a larger one. | 16:09 |
| kparal | so what are the criteria we would like to remove/not add to Beta wrt custom partitioning? | 16:09 |
| Martix | cmurf: ext4 on LVM | 16:09 |
| tflink | I'm not crazy about not requiring LVM/btrfs @ beta but I'm not sure I see much of a place in between | 16:09 |
| tflink | but I think that RAID needs to stay | 16:10 |
| cmurf | Martix: I haven't tested extensively but it should work. | 16:10 |
| adamw | kparal: well the 'new' ones we added a few weeks back | 16:10 |
| adamw | kparal: plus all the previous proposals in that thread | 16:10 |
| cmurf | tflink: I definitely would not require btrfs, LVM is maybe a slightly different story because it's been around so long, like RAID. But I'm totally dead set against RAID 5 holding up a beta…FWIW. | 16:10 |
| kparal | adamw: so this one? The installer's custom partitioning mode must be capable of the following: | 16:11 |
| kparal | Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types | 16:11 |
| kparal | Creating encrypted partitions | 16:11 |
| kparal | Rejecting obviously invalid operations without crashing | 16:11 |
| adamw | kparal: i haven't looked at the precise adjustments | 16:11 |
| adamw | kparal: yeah, basically. | 16:11 |
| kparal | all erased? | 16:11 |
| adamw | it was more a general-approach thing. | 16:11 |
| adamw | broadly, yeah. | 16:11 |
| tflink | cmurf: I was thinking of LVM/btrfs as more of a one-or-the other kind of thing | 16:11 |
| cmurf | The problem with lowering expectations for beta, is that we in effect turn final TC's into beta redux... | 16:12 |
| tflink | cmurf: I don't really follow how RAID5/6 is any worse than 0/1 | 16:12 |
| kparal | that means we wouldn't require Beta to be able to install into dual-boot. because usually you are not satisfied with some ad-hoc automatic disk layout | 16:12 |
| tflink | unless mdraid is busted, which I think is blocker worthy | 16:12 |
| tflink | kparal: I thought that dual-boot was always a final thing, not beta | 16:13 |
| kparal | tflink: I mean install alongside an existing system, I don't really mean windows thing | 16:13 |
| cmurf | tflink: btrfs raid0 with boot+root+home as subvols in a single volume, is now bootable with anaconda 18.19 | 16:14 |
| kparal | I think a lot of people might try to install Beta alongside F17 | 16:14 |
| cmurf | That exceeds the requirements. I don't know any other arrangement that supports /boot on raid0. | 16:14 |
| kparal | if it just says "no" without eating their disk, ... /me shrugs | 16:14 |
| tflink | cmurf: I'm still not following you, we don't require /boot on raid | 16:15 |
| adamw | kparal: it should be possible to do that via guided partitioning... | 16:15 |
| kparal | adamw: but we should have criteria that it doesn't eat their other partitions, even if they use custom part | 16:15 |
| kparal | at least no data loss should be checked | 16:15 |
| adamw | hmm | 16:15 |
| adamw | how would you do that, practically speaking? | 16:15 |
| adamw | it's hard to prove a negative | 16:16 |
| kparal | well if someone reports a bug that anaconda touched a different partition, we can have it as a blocker | 16:16 |
| kparal | of course we can't prove it works | 16:16 |
| kparal | we can just block if it doesn't | 16:16 |
| adamw | ok | 16:17 |
| adamw | thanks for the thoughts | 16:17 |
| adamw | i guess we should push on | 16:17 |
| adamw | #info adamw still working partitioning criteria, general agreement that requirements for custom partitioning should not be heavy at beta time | 16:17 |
| adamw | so on test cases, i really just wanted to note that quite a few still seem to need modification for newui | 16:18 |
| adamw | i was planning to get the partitioning test cases updated this week | 16:18 |
| kparal | I also plan to work on it | 16:18 |
| adamw | if anyone feels like working on an old test case please just do it, and let the list know (as kparal and I did, for an example) | 16:18 |
| kparal | but then I spend whole day re-testing blockers :/ | 16:18 |
| adamw | =) | 16:18 |
| cmurf | tflink: I know it's not required today, but for btrfs it may need to be one day soon because it's simply how btrfs makes valid multidevice volumes. | 16:20 |
| adamw | #info many test cases still need revising for newui, if you feel like helping out, please do! | 16:20 |
| adamw | welp, i guess that's that | 16:21 |
| adamw | #topic open floor | 16:22 |
| adamw | any more for any more? | 16:22 |
| * cmurf will be in Brno Nov 8-13 | 16:23 | |
| cmurf | :-) | 16:23 |
| adamw | on tour with the cmurfettes? | 16:24 |
| adamw | FINALLY i got to use that! | 16:24 |
| adamw | i can die happy now | 16:24 |
| * adamw sets fuse for 1 minute | 16:25 | |
| jreznik | adamw: could you please update fesco ticket so I can add my part? :) | 16:26 |
| adamw | #endmeeting | 16:26 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!