From Fedora Project Wiki
Attendees
- adamw (207)
- Viking-Ice (90)
- kparal (50)
- jreznik (31)
- Southern_Gentlem (7)
- jskladan (4)
- zodbot (4)
- garretraziel (3)
- tflink (2)
- mkrizek (2)
- satellit_ (1)
- pschindl (1)
Agenda
- Previous meeting follow-up
- Fedora 18 Beta status / mini blocker review
- Release criteria / test cases
- Open floor
Previous meeting follow-up
- adamw to report recommendation to fesco ticket - this was done
Fedora 18 Beta status / mini blocker review
- Go/No-Go is Thursday - we need to review blockers and fix them ASAP to get an RC spun
- We were still waiting on fedup to be fully available but tflink had been testing it and filing bugs with Will
Mini blocker review
- #868834 was accepted as a blocker per kickstart criterion
- #869839 was rejected as a blocker but accepted as NTH as it seems quite restricted in impact
- #870268 was accepted as NTH, no clear consensus regarding blocker state
- #869061 was left undetermined until further data could be obtained
Release criteria / test cases
- Adam will continue to work on the partitioning criteria, with feedback from David and this meeting
- Everyone was happy with the proposed security criterion, Adam would push it out after waiting a few more days for feedback
Open floor
- We agreed that any decision to take LVM-by-default (see ticket) made after today (2012-10-29) must include a slip for testing
- viking-ice argued that even a decision to take LVM-by-default made today should include a slip, there is not complete agreement on this and there are too few people present to vote on the idea
Action items
- adamw to finally finish drafting revised partitioning criteria
- adamw to push security criterion into 'production' after waiting a few more days for feedback
IRC Log
| adamw | #startmeeting Fedora QA meeting | 15:00 |
|---|---|---|
| zodbot | Meeting started Mon Oct 29 15:00:53 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 |
| adamw | what's occurrin'? | 15:01 |
| * satellit_ listening | 15:01 | |
| * kparal is washing the dishes | 15:01 | |
| * mkrizek is here | 15:01 | |
| * adamw sends his cereal bowl to kparal | 15:02 | |
| * garretraziel is here also | 15:02 | |
| * adamw throws burnt toast at tflink | 15:02 | |
| Viking-Ice | here | 15:04 |
| * pschindl is here | 15:04 | |
| * jskladan is here | 15:04 | |
| adamw | alrighty | 15:05 |
| adamw | sorry, was just looking at the lvm stuff | 15:05 |
| adamw | #topic Previous meeting follow-up | 15:05 |
| adamw | simple one here | 15:05 |
| adamw | #info "adamw to report recommendation to fesco ticket" - did that (it was the freeze-or-not-freeze ticket) | 15:06 |
| adamw | don't think there's anything else to follow up on which isn't in the rest of the agenda | 15:06 |
| adamw | #chair kparal viking-ice | 15:07 |
| zodbot | Current chairs: adamw kparal viking-ice | 15:07 |
| adamw | #topic Fedora 18 Beta status / mini blocker review | 15:07 |
| Viking-Ice | should we keep this one last and move it to the QA channel | 15:07 |
| Viking-Ice | ? | 15:07 |
| adamw | Viking-Ice: I think we're okay as the list is pretty short | 15:07 |
| adamw | only 5 bugs | 15:08 |
| adamw | on the general 18 beta topic....go/no-go is thursday so we really want to get an RC out today or tomorrow | 15:08 |
| adamw | as far as I can see we're kinda stuck waiting for developers, though | 15:08 |
| kparal | when fedup is not available... is RC useful? | 15:09 |
| kparal | it will be no-go anyway, won't it? | 15:09 |
| adamw | for all the other testing, sure. | 15:09 |
| adamw | i'm still assuming fedup will magically appear in working order by thursday | 15:09 |
| kparal | I mean it can be just another TC | 15:09 |
| Viking-Ice | yeah useful for general testing | 15:09 |
| adamw | call me an idiot if you like :) | 15:09 |
| adamw | #info Go/No-Go is Thursday, we need to have RC spun by tomorrow really | 15:10 |
| adamw | #info still waiting on fedup to be fully available but tflink has been testing it and filing bugs with Will | 15:10 |
| adamw | see above - tflink has been poking at it and finding bugs | 15:10 |
| jreznik | adamw: a question to veteran | 15:11 |
| Viking-Ice | even if tflink has been testing it not having it available for other testers per say makes it an no-go as kparal pointed out | 15:11 |
| jreznik | we moved go/no-to to Thursday but this means it's after readiness meeting - any policy which one should preceed another one/ | 15:11 |
| adamw | Viking-Ice: oh yeah i agree | 15:12 |
| adamw | jreznik: that sounds wrong, it should be just before readiness | 15:12 |
| adamw | an hour or two before it | 15:12 |
| jreznik | Viking-Ice: it's availble, I expect tflink is testing only what is in github | 15:12 |
| adamw | jreznik: in practice we want it available as a package for f17 though. | 15:12 |
| jreznik | adamw: you know, the problem with go/no-go is - it can take a looong time... | 15:12 |
| adamw | we don't really want to be telling people to check the upgrader out of git. | 15:13 |
| jreznik | adamw: definitely | 15:13 |
| adamw | jreznik: if go/no-go doesn't say Go by the time of readiness meeting, it's no-go. | 15:13 |
| adamw | so i don't have tflink's scripts handy to do the blocker review, i'll just do it manually, following the order of proposed blockers at http://qa.fedoraproject.org/blockerbugs/milestone/18/beta/buglist | 15:14 |
| adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=868834 | 15:14 |
| jreznik | adamw: ok, I'll try to schedule it later after go/no-go | 15:14 |
| adamw | jreznik: what we've done up till now is leave readiness where it is and run go/no-go earlier | 15:15 |
| adamw | it doesn't need to be at 5pm eastern or whatever | 15:15 |
| adamw | run it 2 hours before readiness | 15:15 |
| adamw | iirc anyhow. | 15:15 |
| adamw | so on this bug...kparal says the kickstart that reproduces it is what anaconda gives you for a default install, so it seems to hit the beta kickstart criterion | 15:15 |
| adamw | so +1 for me | 15:15 |
| Viking-Ice | +1 | 15:16 |
| kparal | yes, it's the very one kickstart, just autopart lines fiddled a bit | 15:16 |
| kparal | +1 blocker | 15:16 |
| adamw | propose #agreed #868834 is accepted as a blocker per criterion "The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible" | 15:17 |
| Viking-Ice | ack | 15:17 |
| mkrizek | ack | 15:17 |
| adamw | #agreed #868834 is accepted as a blocker per criterion "The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible" | 15:17 |
| adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=869839 | 15:18 |
| adamw | so a custom partitioning crasher when doing stuff with btrfs... | 15:18 |
| adamw | this is kinda borderline, i gave it a weak +1 in the bug but that might be a bit generous | 15:18 |
| kparal | do we have btrfs in anaconda officially now? | 15:19 |
| adamw | though i guess the installer crashing when you're just trying to make space is bad. | 15:19 |
| kparal | unhidden? | 15:19 |
| adamw | kparal: oh yeah. | 15:19 |
| adamw | it's been in since the start of newui. | 15:19 |
| Viking-Ice | is btrfs "officially" supported as a filesystem in the distribution and by the installer? | 15:19 |
| jreznik | so it's only brtfs? | 15:19 |
| kparal | then it should violate the criteria | 15:19 |
| adamw | in custom part, sure, it's a Device Type just like RAID etc | 15:19 |
| jreznik | if so, I'm -1 blocker, +1 nth | 15:19 |
| adamw | well now i look at it | 15:19 |
| adamw | it happened when cmurf tried to remove an existing btrfs parted setup | 15:19 |
| adamw | which is probably worse than trying to create a new one | 15:20 |
| jreznik | so the question - does it happen only in this situation or it's more generic? I don't see more data there | 15:20 |
| adamw | has more impact on 'testabilitiy' | 15:20 |
| Viking-Ice | -1 blocker +1 nth | 15:20 |
| adamw | jreznik: given dlehman's comment that it's 'caused by the same problem' as 866101, it's probably btrfs specific in some way, as that's a btry bug | 15:21 |
| adamw | and we don't have any duplicate reports of this one, i would expect some if it were more generic...i've done some installs pretty similar to what cmurf describes. so it's probably quite specifc. | 15:22 |
| adamw | so we've got two -1s and i'm counting kparal as a +1? or is that wrong kparal? | 15:22 |
| jreznik | well, then I'm more with Viking-Ice - it should not crash but brtfs I hope is not really supported fs | 15:22 |
| Viking-Ice | I'm a weak +1 nth btw dont want risk us messing up any installer storage stuff potentially by pulling in a fix for this | 15:23 |
| adamw | well there's nothing to indicate it's 'not supported' in the UI, but if you just mean we don't expect many people to be fiddling with btrfs, i can see that | 15:23 |
| kparal | well it seems to me that it really violates the criteria. but it depends whether it happens for everyone or just in a very specific corner case | 15:24 |
| adamw | kparal: we're still working on the criteria, so i don't want to tie us to them too much for this case | 15:24 |
| jreznik | kparal: btw. what criteria we talk about right now, don't see a proposal | 15:24 |
| adamw | if anything i'd rather see how we feel about the bug then let that feed into the criteria drafting | 15:25 |
| adamw | jreznik: on the existing criteria this would be "The installer's custom partitioning mode must be capable of the following: | 15:25 |
| adamw | Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types" | 15:25 |
| adamw | and the question of whether btrfs is a 'commonly-used filesystem type' would be what we'd be asking. | 15:25 |
| * adamw has no idea why he came up with such crack-addled wording, which is just an invitation for an argument every damn time | 15:26 | |
| kparal | if I don't really look at the criteria, I don't feel this bug to be terrible. anyone with btrfs is able to cope with that (partition manually using a different program or similar) | 15:26 |
| adamw | kparal: that's the kind of feeling i was looking for | 15:26 |
| adamw | it seems like we're broadly not too worried about this one | 15:26 |
| adamw | soo | 15:26 |
| kparal | :) | 15:27 |
| adamw | propose #agreed 869839 is rejected as a blocker on the basis it seems to be specific to btrfs and possibly certain btrfs configurations, and is easily workaroundable | 15:27 |
| adamw | oh, sec | 15:27 |
| adamw | propose #agreed 869839 is rejected as a blocker on the basis it seems to be specific to btrfs and possibly certain btrfs configurations, and is easily workaroundable. accepted as NTH as it could affect 'testability' of custom partitioning | 15:27 |
| kparal | ack | 15:28 |
| Viking-Ice | ack | 15:29 |
| adamw | #agreed 869839 is rejected as a blocker on the basis it seems to be specific to btrfs and possibly certain btrfs configurations, and is easily workaroundable. accepted as NTH as it could affect 'testability' of custom partitioning | 15:29 |
| jreznik | late ack | 15:29 |
| adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=870268 | 15:29 |
| adamw | sorry jreznik :) | 15:29 |
| adamw | i'm going with two acks just to move things along | 15:29 |
| jreznik | adamw: call of nature :0 | 15:29 |
| adamw | hey, that's usually me :) | 15:29 |
| adamw | this one stops the live images being Mac bootable, so it seems pretty straightforward blocker. and happily is easy to fix. | 15:30 |
| adamw | (actually we came up with the fix then filed the bug :>) | 15:30 |
| kparal | I think jskladan used to boot Lives on Mac before, haven't you? | 15:30 |
| kparal | but maybe this was broken with just fc18 livecd-tools | 15:31 |
| adamw | it affects creation of images not writing them to disks | 15:31 |
| Viking-Ice | +1 nth | 15:31 |
| adamw | (this gets a bit confusing as livecd-tools contains both livecd-creator and livecd-iso-to-disk) | 15:31 |
| kparal | ah | 15:31 |
| kparal | garretraziel's test is then not really useful | 15:32 |
| adamw | aiui if hfsplus-tools isn't in the environment when livecd-creator is run, the generated image won't be Mac bootable | 15:32 |
| kparal | he tried just cd->usb | 15:32 |
| Viking-Ice | or even reject since we rejected plethora of graphic hw spesific bug and mac is less common then that ( running fedora that ist )+ | 15:32 |
| garretraziel | yep, I have only tried cd->usb stick | 15:32 |
| adamw | Viking-Ice: i dunno if we have solid numbers on that, quite a lot of people seem to like the Mac HW... | 15:33 |
| Viking-Ice | adamw, and it has never properly worked for them | 15:33 |
| Viking-Ice | ever | 15:33 |
| adamw | ? 17 works fine on quite a few macs | 15:33 |
| adamw | others have graphics hardware issues (heh) | 15:34 |
| Viking-Ice | and the releases before that | 15:34 |
| kparal | Viking-Ice: we have Mac Mini in the office, it works OK | 15:34 |
| Viking-Ice | NOW | 15:34 |
| adamw | Viking-Ice: before 17 it was messier, still worked on some | 15:34 |
| adamw | i can see your argument for nth though | 15:34 |
| kparal | +1 nth for sure | 15:34 |
| adamw | let's just vote it through as NTH then to save time | 15:34 |
| Viking-Ice | the thing is we cant reject bunch of peoples graphical hw which is more common then people running Fedora on OS-X hw | 15:34 |
| Viking-Ice | then accept this one | 15:35 |
| kparal | I'd be inclined even for +1 blocker, this is trivial and it improves Mac chances to boot | 15:35 |
| adamw | propose #agreed 870268 is accepted as NTH: some debate over whether Macs are really prevalent enough for blocker status | 15:35 |
| Viking-Ice | ack | 15:35 |
| kparal | ack | 15:35 |
| adamw | Viking-Ice: i'm just not sure it's true to say any of the graphics bugs hits more fedora users than Mac ones...and it's hard as crap to get usable data on that kind of question out of smolt. oh well | 15:35 |
| Viking-Ice | smolt is no more ;) | 15:35 |
| adamw | #agreed 870268 is accepted as NTH: some debate over whether Macs are really prevalent enough for blocker status | 15:36 |
| adamw | Viking-Ice: you could still query the data on the web interface last i checked. dunno if you still can now. | 15:36 |
| jreznik | Viking-Ice: it's sad, but we actually never used it truly... | 15:36 |
| adamw | we have a dump of all the data in it somewhere | 15:36 |
| Viking-Ice | jreznik, not to the extent we might have | 15:36 |
| adamw | jreznik: we used it very occasionally to answer the 'how common is this HW' question, but it was just a giant PITA to get that data out of it | 15:36 |
| adamw | I'm gonna skip 844167 because the question is always 'does it apply to fedup' and since tflink isn't here the answer is inevitably 'we don't know; | 15:37 |
| adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=869061 | 15:37 |
| Viking-Ice | this needs to be added to F17 | 15:38 |
| Viking-Ice | why is this blocking F18 | 15:38 |
| Viking-Ice | or supposed to block F18 | 15:38 |
| adamw | i think it's to do with how fedup works | 15:39 |
| Viking-Ice | -1 blocker -1 nth | 15:39 |
| jreznik | Viking-Ice: there are some bits that are needed in f18 | 15:39 |
| adamw | the dracut environment it runs the upgrade process in is built from f18 packages, or something | 15:39 |
| Viking-Ice | oh shit | 15:39 |
| adamw | Viking-Ice: i don't know for sure | 15:39 |
| adamw | i haven't run fedup myself still, i think wwoods and tflink are the only ones who know for sure | 15:39 |
| adamw | and neither of them answered my question, so my vote would be punt on this one | 15:40 |
| jreznik | is second-switch already f18 then? | 15:40 |
| adamw | until one of them can tell us whether there's any reason this needs to be fixed in the frozen env | 15:40 |
| adamw | jreznik: I really don't know. | 15:40 |
| adamw | that's why i asked in the bug, but no reply. | 15:40 |
| adamw | hum. now i come to think of it, i'm guessing a lot of the continental U.S. folks aren't around for weather-related reasons... | 15:40 |
| adamw | obviously if this fix doesn't actually need to be in the frozen f18 package set i'd be -1/-1 | 15:41 |
| Viking-Ice | I+m -1/-1 | 15:41 |
| garretraziel | yep, fedup dracut should be built in F18, it requires F18 packages | 15:41 |
| kparal | I don't get it. how can this be fixed outside of the frozen set? | 15:41 |
| kparal | everything is frozen | 15:41 |
| adamw | kparal: well there's three possibilities | 15:42 |
| adamw | it could need fixing in the f17 updates | 15:42 |
| Viking-Ice | that's FESCO mistake they should have punted the release another week | 15:42 |
| adamw | it could need fixing in f18 updates | 15:42 |
| adamw | or it could need to go in the frozen f18 set. | 15:42 |
| adamw | even if f18 packages are used, if fedup's going to pull them from the update repo then we could fix this with a 0-day | 15:42 |
| adamw | i guess 'offline' upgrades might be affected in that case... | 15:42 |
| kparal | but we still need to track it somehow. how will we track it if we say 'not blocker'? | 15:43 |
| Viking-Ice | by cc | 15:43 |
| adamw | well that's why i voted to punt | 15:43 |
| kparal | because once we say RCx is GOLD, people will start upgrading | 15:43 |
| adamw | eh. | 15:43 |
| Viking-Ice | test upgrading | 15:43 |
| kparal | a lot of them won't wait for official announcements etc | 15:43 |
| adamw | does anyone aside from viking want to vote a solid +1 or -1? | 15:43 |
| adamw | if not we may as well move on | 15:43 |
| Viking-Ice | reporters are expected to wipe installs and redo tests | 15:43 |
| Viking-Ice | until we release FINAL | 15:44 |
| jreznik | I'd say punt and get more info from guys | 15:44 |
| kparal | yes, punt | 15:44 |
| kparal | but I still don't get it | 15:44 |
| kparal | nevermind :) | 15:44 |
| Viking-Ice | what's punt going to help? | 15:44 |
| Viking-Ice | dont we already have all the data we need | 15:45 |
| adamw | Viking-Ice: no, we don't have an answer to the question about whether there's any benefit to fixing it in the frozen packages... | 15:45 |
| adamw | propose #agreed cannot determine state of #869061 without an answer to the question about what are the implications about taking or not taking the fix in the f18 beta frozen package set | 15:46 |
| kparal | ack | 15:46 |
| Viking-Ice | ack | 15:46 |
| adamw | #agreed cannot determine state of #869061 without an answer to the question about what are the implications about taking or not taking the fix in the f18 beta frozen package set | 15:47 |
| jreznik | ack | 15:47 |
| jreznik | ah, late again :) | 15:47 |
| adamw | :) | 15:47 |
| adamw | okay, that looks to be all the blockers | 15:47 |
| adamw | #topic Release criteria / test cases | 15:47 |
| Viking-Ice | adamw, aren't you forgetting your journal one | 15:48 |
| adamw | so let's see what i had on the list... | 15:48 |
| adamw | Viking-Ice: mm? | 15:48 |
| Viking-Ice | https://bugzilla.redhat.com/show_bug.cgi?id=869061 | 15:48 |
| adamw | that's...the one we just talked about | 15:48 |
| Viking-Ice | https://bugzilla.redhat.com/show_bug.cgi?id=844167 | 15:49 |
| adamw | Viking-Ice: i said i was skipping that one as it's upgrade related and we don't know whether it affects fedup. | 15:49 |
| adamw | tflink or wwoods might know, but neither of them is around. | 15:49 |
| adamw | so not much to say. | 15:50 |
| Viking-Ice | ah ok | 15:50 |
| Viking-Ice | then punting makes sense we need to determin if that's an selinux issue | 15:50 |
| adamw | it's clearly selinux-related, the question is more whether selinux issues affect fedup or not | 15:51 |
| Viking-Ice | anyway back on topic | 15:51 |
| adamw | yup | 15:51 |
| adamw | so i still have the partitioning criteria to work on | 15:51 |
| adamw | but now we have some feedback from dlehman and this meeting which will help | 15:51 |
| adamw | #action adamw to finally finish drafting revised partitioning criteria | 15:52 |
| adamw | there's the security criterion i proposed, we could vote on that i guess | 15:52 |
| adamw | viking already +1ed it on the list, anyone else have comments? | 15:52 |
| kparal | I have read it and it sounds fine | 15:52 |
| adamw | the proposal is to add "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)" for final, for anyone who missed it. | 15:53 |
| * jreznik likes it - generic enough for security stuff, could be flexible - as security bugs are usually "what if" and reproducers are... | 15:54 | |
| adamw | cool. well we don't really have enough people here to just say it's approved, so i'll follow the usual procedure of leaving it for a few days. | 15:54 |
| Viking-Ice | the problem here who's going to do it | 15:54 |
| adamw | Viking-Ice: like i said the intent isn't to proactively go and look for security bugs a part of validation testing, that's pretty problemati | 15:54 |
| adamw | c | 15:54 |
| Viking-Ice | as in compare what's on the dvd and see if those packages match Red Hat severity classification | 15:55 |
| adamw | it's more for the case where a security bug gets found and raised for voting | 15:55 |
| Viking-Ice | anyway I acked it so.. | 15:55 |
| adamw | #action adamw to push security criterion into 'production' after waiting a few more days for feedback | 15:55 |
| adamw | i threw test case revision on the agenda in case anyone wanted to bring anything up about it, but i dunno if there's much to talk about. jskladan did a neat job of identifying things that need fixing. | 15:56 |
| Viking-Ice | yup | 15:56 |
| adamw | welp, sounds like we're on track | 15:58 |
| adamw | #topic open floor | 15:58 |
| adamw | anything I forgot to cover? | 15:58 |
| Viking-Ice | yup | 15:58 |
| Viking-Ice | lvm | 15:58 |
| Viking-Ice | as I posted to the test list | 15:58 |
| adamw | oh right, i meant to bring that up in the 18 status topic, d'oh | 15:58 |
| adamw | #topic open floor - LVM-by-default discussion | 15:58 |
| Viking-Ice | we formerly support adamw statement "If no decision is made by then I don't see any option but to stick with the current behaviour (ext4), we just cannot go poking this code two days before we sign off on the Beta, no matter how theoretically safe it is." " | 15:58 |
| adamw | #info FESCo ticket https://fedorahosted.org/fesco/ticket/964 , bug https://bugzilla.redhat.com/show_bug.cgi?id=870207 | 15:58 |
| adamw | Viking-Ice: they seem to be getting some votes in today...if they vote for LVM before end of today i'd say we go with it, if they can't get the vote done today then no | 15:59 |
| adamw | that'd be my position anyhoo | 15:59 |
| jreznik | I can see +3 now | 16:00 |
| Viking-Ice | the request for this change is to late in process and we simply dont like these kind of work methods those rh storage devs should just have been paying attention and cant expect neither FESCO nor the Anaconda developers to feed them information | 16:00 |
| Viking-Ice | it's a fundemental work process issue | 16:00 |
| Viking-Ice | for us | 16:00 |
| adamw | basically it needs to be decided by the time we spin the next build, and i was figuring we'd do a build today. | 16:00 |
| Viking-Ice | If fesco is going to approve this they are setting example | 16:00 |
| jreznik | it's if the vote is not done today and we're going to release this week, what if we slip? do we still want recondiser it? | 16:00 |
| adamw | sigh, we _really needed_ this to get even more complicated ;) | 16:01 |
| Viking-Ice | adamw, no we formally object the change | 16:01 |
| Viking-Ice | fesco still will do the wrong thing | 16:01 |
| adamw | Viking-Ice: as in, what, we pass a #agreed that we don't think it should be changed and comment that on the bug? well, we can put it to a vote | 16:02 |
| Viking-Ice | and we still have to implement it but we make a formal statement that we dont like thsi | 16:02 |
| adamw | there's only three QA here plus jreznik, though | 16:02 |
| adamw | er, s/bug/ticket/ | 16:02 |
| Viking-Ice | that's 2 -1 unless you are going to vote against yourself | 16:03 |
| * kparal is not sure he's part of Viking-Ice's "we" | 16:03 | |
| Viking-Ice | kparal, qa community | 16:03 |
| adamw | kparal: as i read it, viking is making a proposal | 16:03 |
| Viking-Ice | we cannot condole this work flow period we are after freeze | 16:03 |
| kparal | I think it's fesco decision, with all the consequences. they should give us at least half a week to make sure everything is tested properly | 16:04 |
| Viking-Ice | we are making statement on *when* the change is being introduce not *why* or rather if lvm should be or not to be the defauæt | 16:04 |
| Viking-Ice | a week | 16:04 |
| Viking-Ice | if accepted a firm week | 16:04 |
| kparal | a week is optimal | 16:04 |
| jreznik | it's when and it's up to fesco right now - with all consequences of possible slip etc. | 16:04 |
| adamw | if we're gonna vote on viking's proposal i'd vote -1 or +/-0, as kparal said it's an exceptional situation and has been elevated to fesco for that reason, i'm willing to go with whatever fesco decides as long as it's in a reasonable timeframe (today) | 16:04 |
| adamw | but since we only have 3+1 people i'm not sure a vote really means a lot. | 16:05 |
| jreznik | adamw: if fesco says hour before go/no-go we want lvm, then it's up to fesco - even it could lead to the slip | 16:05 |
| adamw | jreznik: if they want to take the change after today then we'd definitely want a slip, i think. | 16:06 |
| jreznik | adamw: yep, that's what I'm trying to tell now - just better words | 16:06 |
| kparal | so QA recommendation is: decide today, or later but slip a week | 16:07 |
| Viking-Ice | we should be firmly against these kind of changes *after* freeze but since it comes from your fellow rh camp I'm not surprised about your voting -1 in this | 16:07 |
| adamw | i dunno if we can say we have a complete consensus as a group, we have a disagreement just in the 3 people here | 16:07 |
| adamw | Viking-Ice: for me it's complicated by the fact that none of the options are good ones | 16:07 |
| adamw | in that the current state is _itself_ a change from f17 that wasn't properly communicated and discussed | 16:08 |
| adamw | but i think we've been over all this on the bug | 16:08 |
| Viking-Ice | this change should be rejected on procedures we have set out to follow | 16:08 |
| jreznik | kparal: yep, that' what I'd say | 16:08 |
| Viking-Ice | if fesco votes with this they are essentially giving big *F* to the process | 16:08 |
| * jskladan is +1 on what kparal said | 16:09 | |
| adamw | Viking-Ice: i think several people believe that 'the process' has already been f'ed by this change being made in the first place | 16:09 |
| Viking-Ice | and we QA should make a firm stance against these kind of changes be made *after* freeze | 16:09 |
| adamw | as i see it everyone agrees that making a change this late sucks, but some people think it sucks _less_ than changing our default partitioning behaviour from the last 13 releases if that's not what we would have decided following the proper feature process. | 16:10 |
| adamw | either way, some process gets screwed. | 16:10 |
| * Southern_Gentlem is thinking we say the heck with 18 and move on to 19 | 16:11 | |
| Viking-Ice | no only the process gets screwed if they bote yes | 16:11 |
| Viking-Ice | mean vote | 16:11 |
| adamw | well, if they vote 'no, we're totally happy with ext4 as default' then i guess you could say everything is hunky dory. | 16:11 |
| Viking-Ice | just make the goddam statement you yourself commented | 16:12 |
| Viking-Ice | with QA behind you | 16:12 |
| Viking-Ice | its the right thing to do | 16:12 |
| adamw | if all you want to do is say the QA's official stance is "If no decision is made by then I don't see any option but to stick with the current behaviour (ext4), we just cannot go poking this code two days before we sign off on the Beta, no matter how theoretically safe it is. " we probably have a consensus for that. | 16:12 |
| adamw | "by then" being "today". | 16:13 |
| adamw | i thought you wanted to make a stronger official recommendation that they reject the change on the basis it's too late. | 16:13 |
| Viking-Ice | yes " we just cannot go poking this code two days before we sign off on the Beta, no matter how theoretically safe it is." | 16:13 |
| Viking-Ice | be it lvm or be it something else | 16:13 |
| kparal | that's exactly what I proposed | 16:14 |
| kparal | "decide today, or later but slip a week" | 16:14 |
| adamw | propose #agreed QA's official position on the LVM topic is to back adamw's statement in https://fedorahosted.org/fesco/ticket/964#comment:8 | 16:14 |
| Viking-Ice | kparal, yup I agree | 16:14 |
| Viking-Ice | they can decide today but if accepted we must slip a week | 16:15 |
| kparal | adamw: with the addition that if they decide "let's slip a week", we have enough time to test some change | 16:15 |
| Viking-Ice | and arguably lift the freeze ( which would allow us to pull in those selinux changes right ? ) | 16:15 |
| adamw | let's see | 16:16 |
| adamw | Viking-Ice: uh, that's not what kparal said. he said 'decide today' (no slip) 'or later but slip a week' (slip). | 16:16 |
| adamw | that's why i said we don't have a consensus. | 16:16 |
| adamw | my statement was meant to mean that if they agree by today, we don't need to require a slip. you seem to be saying we should ask for a slip if they say yes, even if they say yes today. | 16:17 |
| kparal | today decision is fine, if we manage to ask for another TC/RC today | 16:17 |
| kparal | isn't it? | 16:17 |
| Southern_Gentlem | i thought the whole idea of freezes was that stuff needing fixed could be but everything else was frozen | 16:17 |
| adamw | Southern_Gentlem: more or less. as far as process goes, we take only blocker and NTH fixes through the freeze. | 16:18 |
| adamw | my assumption was that we are essentially deferring the decision on NTH status of this bug to fesco as it's so controversial. | 16:18 |
| adamw | if FESCo votes 'yes' that means we accept the bug as NTH. | 16:18 |
| Southern_Gentlem | its fedup correct ? | 16:19 |
| adamw | no, we're not talking about fedup at all | 16:19 |
| Southern_Gentlem | ok | 16:19 |
| adamw | we're talking about https://bugzilla.redhat.com/show_bug.cgi?id=870207 here | 16:19 |
| adamw | of course, the most likely outcome here is that we wind up slipping for fedup or the existing blockers and this whole thing becomes a bit less urgent, but eh. | 16:19 |
| Viking-Ice | what's more worrying to me is the *time* of the request for change and if fesco accepts it it can be used as a reference for other cases and we find ourselves exactly back in these shoes | 16:20 |
| Viking-Ice | heck if they accept this on *people not being informed* then we can file several request on that bases | 16:20 |
| adamw | Viking-Ice: well, i mean, in any case where someone wanted to argue a blocker or NTH decision and we couldn't agree on it via the usual process, it seems to me the natural escalation is FESCo | 16:20 |
| adamw | so i don't think we're really deviating from the policy/process here...we have a really hot potato as a proposed NTH bug and so it got escalated. | 16:21 |
| Viking-Ice | yeah from rh storage people | 16:21 |
| adamw | if not FESCo, to what body *would* we escalate a really controversial blocker/nth decision? | 16:21 |
| Viking-Ice | that cant even point me to their own claimed community within the distribution | 16:22 |
| Viking-Ice | and seem to have already decide that btrfs is going to be the default for 19 from what I gather from their response | 16:22 |
| Viking-Ice | s | 16:22 |
| adamw | well, no. two people already said specifically you're assuming too much there. | 16:23 |
| adamw | all they said is that the *target* is to go to btrfs by default in f19.\ | 16:23 |
| Viking-Ice | we will see | 16:23 |
| Viking-Ice | time will tell | 16:23 |
| adamw | it's already been accepted as a feature in theory by fesco, after all, it just keeps getting delayed because the tools aren't ready. all they're saying is they aim to have things ready by f19. | 16:23 |
| adamw | anyway, we just seem to be going around in circles... | 16:24 |
| adamw | i can't see much being raised which isn't already in the bug report or ticket. | 16:24 |
| Southern_Gentlem | Viking-Ice, since f18 is where RHel 7 is suppose to branch from i can see the RH people not liking this change either | 16:24 |
| adamw | Southern_Gentlem: this isn't a problem for RHEL | 16:24 |
| adamw | the code has been written so that RHEL can have a different default | 16:24 |
| Southern_Gentlem | (myself i have never liked lvm) but this is COMMUNICATION ISSUE IN THE LONG RUN | 16:24 |
| adamw | that was always in the plan. the people who are objecting to this are RH people but they're objecting to it for Fedora, not for RHEL. | 16:25 |
| kparal | can we please finish the discussion somehow? | 16:25 |
| adamw | yeah | 16:25 |
| adamw | um | 16:25 |
| adamw | it seems we all agree _at least_ that we have to slip if this gets decided later than today | 16:25 |
| kparal | yes | 16:25 |
| Viking-Ice | yes | 16:25 |
| adamw | viking has a stronger position than that, but we all agree on that | 16:25 |
| jskladan | yup | 16:26 |
| adamw | i can note viking's stronger position officially for the logs, and i think we shouldn't decide officially whether 'the group' is with him or against him as we just don't have enough people | 16:26 |
| kparal | and QA community is split whether today's decision is enough to make sure Beta can be tested until Thursday | 16:26 |
| adamw | so...let's say | 16:26 |
| kparal | ^^ | 16:26 |
| adamw | #agreed QA agrees that any decision to take LVM-by-default made after today (2012-10-29) must include a slip for testing | 16:26 |
| Viking-Ice | I'm nack-ing this and say if answer is yes then slip | 16:27 |
| adamw | #info viking-ice argues that even a decision to take LVM-by-default made today should include a slip, there is not complete agreement on this and there are too few people present to vote on the idea | 16:27 |
| kparal | Viking-Ice: you just changed your statement | 16:27 |
| adamw | does that at least represent everyone's concerns | 16:28 |
| adamw | ? | 16:28 |
| kparal | yes | 16:28 |
| tflink | yeah | 16:28 |
| jskladan | ^^ | 16:28 |
| kparal | I hope | 16:28 |
| Viking-Ice | yes | 16:28 |
| kparal | tflink: welcome | 16:28 |
| tflink | kparal: thanks, missed most of the meeting, though :-/ | 16:28 |
| Southern_Gentlem | +1 | 16:28 |
| adamw | okay, sorry for the length | 16:29 |
| adamw | any other topics for open floor? | 16:29 |
| jreznik | adamw: would it be ok for qa to have go/no-go 1 pm eastern and readiness 3 pm? or is it too early? just based on 18 alpha, so I take suggestions :) | 16:30 |
| Viking-Ice | jreznik, that in utc is | 16:30 |
| adamw | Viking-Ice: i think 1600 / 1800 | 16:30 |
| Viking-Ice | ok | 16:30 |
| adamw | oh, or 1700 / 1900? | 16:31 |
| adamw | yeah, 1700 / 1900. | 16:31 |
| jreznik | 3 edt is 19:00 utc | 16:31 |
| jreznik | (it's more complicated now, as there's no summer time here... so I'm lost in tz conversions right now :) | 16:32 |
| jreznik | but yeah, 17 and 19 | 16:32 |
| kparal | jreznik: we're now utc+1 | 16:32 |
| adamw | okay, fuse set for X minutes | 16:32 |
| adamw | thanks for coming folks | 16:32 |
| jreznik | well, ok, I schedule 17 go/no-go and 19 readiness (utc) | 16:33 |
| adamw | later is always better for us, but there's no particular problem with those times afaik | 16:33 |
| adamw | thanks again everyone | 16:34 |
| adamw | #endmeeting | 16:34 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!