QA/Meetings/20121029

From FedoraProject

< QA | Meetings
Revision as of 18:54, 29 October 2012 by Adamwill (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

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&#230;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!