15:00:53 <adamw> #startmeeting Fedora QA meeting
15:00:53 <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:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:55 <adamw> #meetingname fedora-qa
15:00:55 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:57 <adamw> #topic roll call
15:01:01 <adamw> what's occurrin'?
15:01:30 * satellit_ listening
15:01:43 * kparal is washing the dishes
15:01:52 * mkrizek is here
15:02:31 * adamw sends his cereal bowl to kparal
15:02:50 * garretraziel is here also
15:02:55 * adamw throws burnt toast at tflink
15:04:05 <Viking-Ice> here
15:04:35 * pschindl is here
15:04:57 * jskladan is here
15:05:18 <adamw> alrighty
15:05:27 <adamw> sorry, was just looking at the lvm stuff
15:05:33 <adamw> #topic Previous meeting follow-up
15:05:41 <adamw> simple one here
15:06:15 <adamw> #info "adamw to report recommendation to fesco ticket" - did that (it was the freeze-or-not-freeze ticket)
15:06:30 <adamw> don't think there's anything else to follow up on which isn't in the rest of the agenda
15:07:00 <adamw> #chair kparal viking-ice
15:07:00 <zodbot> Current chairs: adamw kparal viking-ice
15:07:16 <adamw> #topic Fedora 18 Beta status / mini blocker review
15:07:49 <Viking-Ice> should we keep this one last and move it to the QA channel
15:07:52 <Viking-Ice> ?
15:07:58 <adamw> Viking-Ice: I think we're okay as the list is pretty short
15:08:15 <adamw> only 5 bugs
15:08:40 <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:48 <adamw> as far as I can see we're kinda stuck waiting for developers, though
15:09:10 <kparal> when fedup is not available... is RC useful?
15:09:29 <kparal> it will be no-go anyway, won't it?
15:09:30 <adamw> for all the other testing, sure.
15:09:42 <adamw> i'm still assuming fedup will magically appear in working order by thursday
15:09:43 <kparal> I mean it can be just another TC
15:09:43 <Viking-Ice> yeah useful for general testing
15:09:47 <adamw> call me an idiot if you like :)
15:10:13 <adamw> #info Go/No-Go is Thursday, we need to have RC spun by tomorrow really
15:10:30 <adamw> #info still waiting on fedup to be fully available but tflink has been testing it and filing bugs with Will
15:10:48 <adamw> see above - tflink has been poking at it and finding bugs
15:11:27 <jreznik> adamw: a question to veteran
15:11:38 <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:59 <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:12:04 <adamw> Viking-Ice: oh yeah i agree
15:12:21 <adamw> jreznik: that sounds wrong, it should be just before readiness
15:12:25 <adamw> an hour or two before it
15:12:32 <jreznik> Viking-Ice: it's availble, I expect tflink is testing only what is in github
15:12:52 <adamw> jreznik: in practice we want it available as a package for f17 though.
15:12:56 <jreznik> adamw: you know, the problem with go/no-go is - it can take a looong time...
15:13:00 <adamw> we don't really want to be telling people to check the upgrader out of git.
15:13:02 <jreznik> adamw: definitely
15:13:29 <adamw> jreznik: if go/no-go doesn't say Go by the time of readiness meeting, it's no-go.
15:14:02 <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:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=868834
15:14:28 <jreznik> adamw: ok, I'll try to schedule it later after go/no-go
15:15:12 <adamw> jreznik: what we've done up till now is leave readiness where it is and run go/no-go earlier
15:15:18 <adamw> it doesn't need to be at 5pm eastern or whatever
15:15:23 <adamw> run it 2 hours before readiness
15:15:26 <adamw> iirc anyhow.
15:15:48 <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:50 <adamw> so +1 for me
15:16:02 <Viking-Ice> +1
15:16:11 <kparal> yes, it's the very one kickstart, just autopart lines fiddled a bit
15:16:16 <kparal> +1 blocker
15:17:06 <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:19 <Viking-Ice> ack
15:17:20 <mkrizek> ack
15:17:57 <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:18:09 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=869839
15:18:36 <adamw> so a custom partitioning crasher when doing stuff with btrfs...
15:18:47 <adamw> this is kinda borderline, i gave it a weak +1 in the bug but that might be a bit generous
15:19:07 <kparal> do we have btrfs in anaconda officially now?
15:19:09 <adamw> though i guess the installer crashing when you're just trying to make space is bad.
15:19:10 <kparal> unhidden?
15:19:14 <adamw> kparal: oh yeah.
15:19:20 <adamw> it's been in since the start of newui.
15:19:22 <Viking-Ice> is btrfs "officially" supported as a filesystem in the distribution and by the installer?
15:19:27 <jreznik> so it's only brtfs?
15:19:30 <kparal> then it should violate the criteria
15:19:34 <adamw> in custom part, sure, it's a Device Type just like RAID etc
15:19:35 <jreznik> if so, I'm -1 blocker, +1 nth
15:19:43 <adamw> well now i look at it
15:19:56 <adamw> it happened when cmurf tried to remove an existing btrfs parted setup
15:20:06 <adamw> which is probably worse than trying to create a new one
15:20:25 <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:27 <adamw> has more impact on 'testabilitiy'
15:20:40 <Viking-Ice> -1 blocker +1 nth
15:21:38 <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:22:16 <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:32 <adamw> so we've got two -1s and i'm counting kparal as a +1? or is that wrong kparal?
15:22:42 <jreznik> well, then I'm more with Viking-Ice - it should not crash but brtfs I hope is not really supported fs
15:23:43 <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:44 <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:24:11 <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:53 <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:55 <jreznik> kparal: btw. what criteria we talk about right now, don't see a proposal
15:25:04 <adamw> if anything i'd rather see how we feel about the bug then let that feed into the criteria drafting
15:25:32 <adamw> jreznik: on the existing criteria this would be "The installer's custom partitioning mode must be capable of the following:
15:25:32 <adamw> Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
15:25:46 <adamw> and the question of whether btrfs is a 'commonly-used filesystem type' would be what we'd be asking.
15:26:04 * 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:29 <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:47 <adamw> kparal: that's the kind of feeling i was looking for
15:26:56 <adamw> it seems like we're broadly not too worried about this one
15:26:56 <adamw> soo
15:27:04 <kparal> :)
15:27:29 <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:38 <adamw> oh, sec
15:27:54 <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:28:12 <kparal> ack
15:29:12 <Viking-Ice> ack
15:29:20 <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:30 <jreznik> late ack
15:29:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=870268
15:29:34 <adamw> sorry jreznik :)
15:29:39 <adamw> i'm going with two acks just to move things along
15:29:43 <jreznik> adamw: call of nature :0
15:29:54 <adamw> hey, that's usually me :)
15:30:15 <adamw> this one stops the live images being Mac bootable, so it seems pretty straightforward blocker. and happily is easy to fix.
15:30:25 <adamw> (actually we came up with the fix then filed the bug :>)
15:30:49 <kparal> I think jskladan used to boot Lives on Mac before, haven't you?
15:31:01 <kparal> but maybe this was broken with just fc18 livecd-tools
15:31:37 <adamw> it affects creation of images not writing them to disks
15:31:46 <Viking-Ice> +1 nth
15:31:49 <adamw> (this gets a bit confusing as livecd-tools contains both livecd-creator and livecd-iso-to-disk)
15:31:53 <kparal> ah
15:32:07 <kparal> garretraziel's test is then not really useful
15:32:17 <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:18 <kparal> he tried just cd->usb
15:32:28 <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:36 <garretraziel> yep, I have only tried cd->usb stick
15:33:21 <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:43 <Viking-Ice> adamw, and it has never properly worked for them
15:33:46 <Viking-Ice> ever
15:33:58 <adamw> ? 17 works fine on quite a few macs
15:34:03 <adamw> others have graphics hardware issues (heh)
15:34:07 <Viking-Ice> and the releases before that
15:34:08 <kparal> Viking-Ice: we have Mac Mini in the office, it works OK
15:34:16 <Viking-Ice> NOW
15:34:23 <adamw> Viking-Ice: before 17 it was messier, still worked on some
15:34:28 <adamw> i can see your argument for nth though
15:34:41 <kparal> +1 nth for sure
15:34:54 <adamw> let's just vote it through as NTH then to save time
15:34:59 <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:35:02 <Viking-Ice> then accept this one
15:35:06 <kparal> I'd be inclined even for +1 blocker, this is trivial and it improves Mac chances to boot
15:35:17 <adamw> propose #agreed 870268 is accepted as NTH: some debate over whether Macs are really prevalent enough for blocker status
15:35:26 <Viking-Ice> ack
15:35:27 <kparal> ack
15:35:45 <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:59 <Viking-Ice> smolt is no more ;)
15:36:01 <adamw> #agreed 870268 is accepted as NTH: some debate over whether Macs are really prevalent enough for blocker status
15:36:14 <adamw> Viking-Ice: you could still query the data on the web interface last i checked. dunno if you still can now.
15:36:21 <jreznik> Viking-Ice: it's sad, but we actually never used it truly...
15:36:25 <adamw> we have a dump of all the data in it somewhere
15:36:34 <Viking-Ice> jreznik, not to the extent we might have
15:36:56 <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:37:40 <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:50 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=869061
15:38:18 <Viking-Ice> this needs to be added to F17
15:38:34 <Viking-Ice> why is this blocking F18
15:38:42 <Viking-Ice> or supposed to block F18
15:39:10 <adamw> i think it's to do with how fedup works
15:39:17 <Viking-Ice> -1 blocker -1 nth
15:39:26 <jreznik> Viking-Ice: there are some bits that are needed in f18
15:39:27 <adamw> the dracut environment it runs the upgrade process in is built from f18 packages, or something
15:39:34 <Viking-Ice> oh shit
15:39:40 <adamw> Viking-Ice: i don't know for sure
15:39:50 <adamw> i haven't run fedup myself still, i think wwoods and tflink are the only ones who know for sure
15:40:00 <adamw> and neither of them answered my question, so my vote would be punt on this one
15:40:12 <jreznik> is second-switch already f18 then?
15:40:16 <adamw> until one of them can tell us whether there's any reason this needs to be fixed in the frozen env
15:40:18 <adamw> jreznik: I really don't know.
15:40:24 <adamw> that's why i asked in the bug, but no reply.
15:40:53 <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:41:24 <adamw> obviously if this fix doesn't actually need to be in the frozen f18 package set i'd be -1/-1
15:41:33 <Viking-Ice> I+m -1/-1
15:41:35 <garretraziel> yep, fedup dracut should be built in F18, it requires F18 packages
15:41:46 <kparal> I don't get it. how can this be fixed outside of the frozen set?
15:41:52 <kparal> everything is frozen
15:42:10 <adamw> kparal: well there's three possibilities
15:42:15 <adamw> it could need fixing in the f17 updates
15:42:16 <Viking-Ice> that's FESCO mistake they should have punted the release another week
15:42:19 <adamw> it could need fixing in f18 updates
15:42:25 <adamw> or it could need to go in the frozen f18 set.
15:42:38 <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:53 <adamw> i guess 'offline' upgrades might be affected in that case...
15:43:09 <kparal> but we still need to track it somehow. how will we track it if we say 'not blocker'?
15:43:22 <Viking-Ice> by cc
15:43:23 <adamw> well that's why i voted to punt
15:43:24 <kparal> because once we say RCx is GOLD, people will start upgrading
15:43:35 <adamw> eh.
15:43:38 <Viking-Ice> test upgrading
15:43:39 <kparal> a lot of them won't wait for official announcements etc
15:43:50 <adamw> does anyone aside from viking want to vote a solid +1 or -1?
15:43:52 <adamw> if not we may as well move on
15:43:53 <Viking-Ice> reporters are expected to wipe installs and redo tests
15:44:13 <Viking-Ice> until we release FINAL
15:44:28 <jreznik> I'd say punt and get more info from guys
15:44:36 <kparal> yes, punt
15:44:41 <kparal> but I still don't get it
15:44:44 <kparal> nevermind :)
15:44:53 <Viking-Ice> what's punt going to help?
15:45:07 <Viking-Ice> dont we already have all the data we need
15:45:37 <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:46:17 <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:30 <kparal> ack
15:46:55 <Viking-Ice> ack
15:47:20 <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:22 <jreznik> ack
15:47:27 <jreznik> ah, late again :)
15:47:32 <adamw> :)
15:47:36 <adamw> okay, that looks to be all the blockers
15:47:54 <adamw> #topic Release criteria / test cases
15:48:08 <Viking-Ice> adamw, aren't you forgetting your journal one
15:48:08 <adamw> so let's see what i had on the list...
15:48:13 <adamw> Viking-Ice: mm?
15:48:30 <Viking-Ice> https://bugzilla.redhat.com/show_bug.cgi?id=869061
15:48:46 <adamw> that's...the one we just talked about
15:49:29 <Viking-Ice> https://bugzilla.redhat.com/show_bug.cgi?id=844167
15:49:48 <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:59 <adamw> tflink or wwoods might know, but neither of them is around.
15:50:01 <adamw> so not much to say.
15:50:11 <Viking-Ice> ah ok
15:50:32 <Viking-Ice> then punting makes sense we need to determin if that's an selinux issue
15:51:20 <adamw> it's clearly selinux-related, the question is more whether selinux issues affect fedup or not
15:51:22 <Viking-Ice> anyway back on topic
15:51:24 <adamw> yup
15:51:31 <adamw> so i still have the partitioning criteria to work on
15:51:39 <adamw> but now we have some feedback from dlehman and this meeting which will help
15:52:01 <adamw> #action adamw to finally finish drafting revised partitioning criteria
15:52:24 <adamw> there's the security criterion i proposed, we could vote on that i guess
15:52:36 <adamw> viking already +1ed it on the list, anyone else have comments?
15:52:56 <kparal> I have read it and it sounds fine
15:53:10 <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:54:14 * jreznik likes it - generic enough for security stuff, could be flexible - as security bugs are usually "what if" and reproducers are...
15:54:20 <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:28 <Viking-Ice> the problem here who's going to do it
15:54:49 <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:49 <adamw> c
15:55:00 <Viking-Ice> as in compare what's on the dvd and see if those packages match  Red Hat severity classification
15:55:07 <adamw> it's more for the case where a security bug gets found and raised for voting
15:55:19 <Viking-Ice> anyway I acked it so..
15:55:58 <adamw> #action adamw to push security criterion into 'production' after waiting a few more days for feedback
15:56:30 <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:48 <Viking-Ice> yup
15:58:08 <adamw> welp, sounds like we're on track
15:58:10 <adamw> #topic open floor
15:58:14 <adamw> anything I forgot to cover?
15:58:15 <Viking-Ice> yup
15:58:16 <Viking-Ice> lvm
15:58:20 <Viking-Ice> as I posted to the test list
15:58:27 <adamw> oh right, i meant to bring that up in the 18 status topic, d'oh
15:58:36 <adamw> #topic open floor - LVM-by-default discussion
15:58:57 <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:58 <adamw> #info FESCo ticket https://fedorahosted.org/fesco/ticket/964 , bug https://bugzilla.redhat.com/show_bug.cgi?id=870207
15:59:53 <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:59 <adamw> that'd be my position anyhoo
16:00:00 <jreznik> I can see +3 now
16:00:02 <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:21 <Viking-Ice> it's a fundemental work process issue
16:00:23 <Viking-Ice> for us
16:00:50 <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:51 <Viking-Ice> If fesco is going to approve this they are setting example
16:00:56 <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:01:14 <adamw> sigh, we _really needed_ this to get even more complicated ;)
16:01:32 <Viking-Ice> adamw, no we formally object the change
16:01:57 <Viking-Ice> fesco still will do the wrong thing
16:02:08 <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:13 <Viking-Ice> and we still have to implement it but we make a formal statement that we dont like thsi
16:02:22 <adamw> there's only three QA here plus jreznik, though
16:02:41 <adamw> er, s/bug/ticket/
16:03:04 <Viking-Ice> that's 2 -1 unless you are going to vote against yourself
16:03:07 * kparal is not sure he's part of Viking-Ice's "we"
16:03:16 <Viking-Ice> kparal, qa community
16:03:21 <adamw> kparal: as i read it, viking is making a proposal
16:03:56 <Viking-Ice> we cannot condole this work flow period we are after freeze
16:04:14 <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:26 <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:42 <Viking-Ice> a week
16:04:47 <Viking-Ice> if accepted a firm week
16:04:53 <kparal> a week is optimal
16:04:55 <jreznik> it's when and it's up to fesco right now - with all consequences of possible slip etc.
16:04:57 <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:05:40 <adamw> but since we only have 3+1 people i'm not sure a vote really means a lot.
16:05:48 <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:06:19 <adamw> jreznik: if they want to take the change after today then we'd definitely want a slip, i think.
16:06:45 <jreznik> adamw: yep, that's what I'm trying to tell now - just better words
16:07:05 <kparal> so QA recommendation is: decide today, or later but slip a week
16:07:12 <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:22 <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:36 <adamw> Viking-Ice: for me it's complicated by the fact that none of the options are good ones
16:08:03 <adamw> in that the current state is _itself_ a change from f17 that wasn't properly communicated and discussed
16:08:14 <adamw> but i think we've been over all this on the bug
16:08:19 <Viking-Ice> this change should be rejected on procedures we have set out to follow
16:08:21 <jreznik> kparal: yep, that' what I'd say
16:08:51 <Viking-Ice> if fesco votes with this they are essentially giving big *F* to the process
16:09:12 * jskladan is +1 on what kparal said
16:09:14 <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:52 <Viking-Ice> and we QA should make a  firm stance against these kind of changes be made *after* freeze
16:10:07 <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:20 <adamw> either way, some process gets screwed.
16:11:01 * Southern_Gentlem is thinking we say the heck with 18 and move on to 19
16:11:03 <Viking-Ice> no only the process gets screwed if they bote yes
16:11:10 <Viking-Ice> mean vote
16:11:37 <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:12:03 <Viking-Ice> just make the goddam statement you yourself commented
16:12:09 <Viking-Ice> with QA behind you
16:12:22 <Viking-Ice> its the right thing to do
16:12:51 <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:13:01 <adamw> "by then" being "today".
16:13:15 <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:40 <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:47 <Viking-Ice> be it lvm or be it something else
16:14:05 <kparal> that's exactly what I proposed
16:14:31 <kparal> "decide today, or later but slip a week"
16:14:36 <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:55 <Viking-Ice> kparal, yup I agree
16:15:06 <Viking-Ice> they can decide today but if accepted we must slip a week
16:15:32 <kparal> adamw: with the addition that if they decide "let's slip a week", we have enough time to test some change
16:15:33 <Viking-Ice> and arguably lift the freeze ( which would allow us to pull in those selinux changes right ? )
16:16:20 <adamw> let's see
16:16:37 <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:43 <adamw> that's why i said we don't have a consensus.
16:17:08 <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:41 <kparal> today decision is fine, if we manage to ask for another TC/RC today
16:17:43 <kparal> isn't it?
16:17:44 <Southern_Gentlem> i thought the whole idea of freezes was that stuff needing fixed could be but everything else was frozen
16:18:25 <adamw> Southern_Gentlem: more or less. as far as process goes, we take only blocker and NTH fixes through the freeze.
16:18:43 <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:49 <adamw> if FESCo votes 'yes' that means we accept the bug as NTH.
16:19:06 <Southern_Gentlem> its fedup correct ?
16:19:17 <adamw> no, we're not talking about fedup at all
16:19:21 <Southern_Gentlem> ok
16:19:24 <adamw> we're talking about https://bugzilla.redhat.com/show_bug.cgi?id=870207 here
16:19:53 <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:20:10 <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:48 <Viking-Ice> heck if they accept this on *people not being informed* then we can file several request on that bases
16:20:49 <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:21:27 <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:47 <Viking-Ice> yeah from rh storage people
16:21:51 <adamw> if not FESCo, to what body *would* we escalate a really controversial blocker/nth decision?
16:22:16 <Viking-Ice> that cant even point me to their own claimed community within the distribution
16:22:50 <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:52 <Viking-Ice> s
16:23:17 <adamw> well, no. two people already said specifically you're assuming too much there.
16:23:25 <adamw> all they said is that the *target* is to go to btrfs by default in f19.\
16:23:44 <Viking-Ice> we will see
16:23:48 <Viking-Ice> time will tell
16:23:48 <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:24:06 <adamw> anyway, we just seem to be going around in circles...
16:24:14 <adamw> i can't see much being raised which isn't already in the bug report or ticket.
16:24:15 <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:22 <adamw> Southern_Gentlem: this isn't a problem for RHEL
16:24:34 <adamw> the code has been written so that RHEL can have a different default
16:24:57 <Southern_Gentlem> (myself i have never liked lvm) but this is  COMMUNICATION ISSUE IN THE LONG RUN
16:25:05 <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:19 <kparal> can we please finish the discussion somehow?
16:25:21 <adamw> yeah
16:25:25 <adamw> um
16:25:47 <adamw> it seems we all agree _at least_ that we have to slip if this gets decided later than today
16:25:54 <kparal> yes
16:25:57 <Viking-Ice> yes
16:25:57 <adamw> viking has a stronger position than that, but we all agree on that
16:26:07 <jskladan> yup
16:26:28 <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:28 <kparal> and QA community is split whether today's decision is enough to make sure Beta can be tested until Thursday
16:26:30 <adamw> so...let's say
16:26:50 <kparal> ^^
16:26:56 <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:27:25 <Viking-Ice> I'm nack-ing this and say if answer is yes then slip
16:27:40 <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:49 <kparal> Viking-Ice: you just changed your statement
16:28:18 <adamw> does that at least represent everyone's concerns
16:28:19 <adamw> ?
16:28:23 <kparal> yes
16:28:29 <tflink> yeah
16:28:30 <jskladan> ^^
16:28:30 <kparal> I hope
16:28:31 <Viking-Ice> yes
16:28:34 <kparal> tflink: welcome
16:28:52 <tflink> kparal: thanks, missed most of the meeting, though :-/
16:28:52 <Southern_Gentlem> +1
16:29:01 <adamw> okay, sorry for the length
16:29:06 <adamw> any other topics for open floor?
16:30:15 <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:35 <Viking-Ice> jreznik, that in utc is
16:30:53 <adamw> Viking-Ice: i think 1600 / 1800
16:30:58 <Viking-Ice> ok
16:31:14 <adamw> oh, or 1700 / 1900?
16:31:36 <adamw> yeah, 1700 / 1900.
16:31:41 <jreznik> 3 edt is 19:00 utc
16:32:07 <jreznik> (it's more complicated now, as there's no summer time here... so I'm lost in tz conversions right now :)
16:32:12 <jreznik> but yeah, 17 and 19
16:32:24 <kparal> jreznik: we're now utc+1
16:32:44 <adamw> okay, fuse set for X minutes
16:32:50 <adamw> thanks for coming folks
16:33:06 <jreznik> well, ok, I schedule 17 go/no-go and 19 readiness (utc)
16:33:44 <adamw> later is always better for us, but there's no particular problem with those times afaik
16:34:23 <adamw> thanks again everyone
16:34:25 <adamw> #endmeeting