21:00:26 <rbergeron> #startmeeting F16 Alpha Go/No-Go Meeting
21:00:26 <zodbot> Meeting started Wed Aug 10 21:00:26 2011 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:31 <cwickert> thanks everybody for somint
21:00:40 <rbergeron> #meetingname F16 Alpha Go/No-Go Meeting
21:00:40 <zodbot> The meeting name has been set to 'f16_alpha_go/no-go_meeting'
21:01:19 <rbergeron> adamw, dgilmore, nirik, spot, anyone else interested: ping.
21:01:30 * spot is here
21:01:32 * CodeBlock here
21:01:52 * jsmith-mobile is on the road
21:01:58 * cebbert here
21:02:06 <dgilmore> rbergeron: hola
21:02:40 <rbergeron> hai.
21:02:44 * rbergeron looks for QA lovin'
21:02:57 <CodeBlock> nirik had to go to the vet, guessing he's not back yet
21:03:06 * rbergeron nods
21:03:20 * pjones is here too
21:03:35 <adamw> yo
21:03:42 <rbergeron> #info present: spot, codeblock, dgilmore, pjones, athmane, cebbert, jsmith-mobile, adamw
21:03:46 * adamw was making a smoothie
21:03:58 <rbergeron> ooh.
21:03:59 <rbergeron> I hope you're sharing.
21:04:07 <rbergeron> #topic Go/No-Go Meeting
21:04:08 <athmane> hello everyone
21:04:28 <clumens> i'm present too, just in case a voice of installation sanity is needed.
21:04:47 <rbergeron> So normally i have some nice notes all prepped for this, about the purpose of this meeting and whatnot, but my whole system just took a giant crap, so I'm winging it.
21:05:01 <adamw> rbergeron: i tried a /dsc send but you didn't respond
21:05:05 <pjones> rbergeron: that's the Fedora spirit we know and love.
21:05:07 <adamw> are you not set up for Direct Smoothie Connection?
21:05:28 <rbergeron> #info the Purpose of the Go/No-Go is to gather yay/nay's from Release Engineering, QA, and devel on whether or not what we have put together is ready for release and meets the release criteria.
21:05:33 <dgilmore> pjones: :)
21:05:43 <rbergeron> I am not. I only get Direct Candy Connections. Crap.
21:05:49 * rbergeron hopes to work up to Direct Pony connections someday
21:06:02 <rbergeron> Am I missing anything about why we're here?
21:06:10 * rbergeron goes to dig up the current test matrix and post the blocker list.
21:06:10 <adamw> nope
21:06:17 <adamw> well, we have documentation!
21:06:17 <adamw> https://fedoraproject.org/wiki/Go_No_Go_Meeting
21:06:24 <rbergeron> Yeah.
21:06:32 <adamw> to which a little bit has been added since last time
21:06:32 <rbergeron> Well, firefox is working up its courage to restart here on my end of life.
21:06:42 <rbergeron> #link https://fedoraproject.org/wiki/Current_Release_Blockers <-- that one I know by heart, though.
21:06:46 <adamw> it now says "Verifying that the Release criteria are met is the responsibility of the QA Team. QA team's determination must be based on the blocker bug process. QA approves the release if there are no accepted blocker bugs that are unaddressed in the candidate compose. QA does not approve the release if there are any accepted blocker bugs that are unaddressed in the candidate compose. There is no room for discretion in this determination."
21:06:57 <rbergeron> Awesome.
21:07:03 <adamw> so...since there are accepted blocker bugs that are unaddressed in the candidate compose...QA votes no-go
21:07:14 <rbergeron> So I don't even need to ask. ;)
21:07:16 <rbergeron> Yeah.
21:07:38 <rbergeron> And I'm happy to back that up. We do have additional blocker bugs that probably need yays/nays at this point.
21:07:51 <pjones> adamw: presumably we discuss those bugs and if it's still true at the *end* of the meeting, QA votes no? ;)
21:07:53 <dgilmore> releng votes no-go
21:08:09 <pjones> or are we just going to skip that part and assume it's done?
21:08:20 <pjones> (I'm actually fine with that)
21:08:21 <dgilmore> pjones: we do normally go over the bugs
21:08:38 <rbergeron> Yup. Let's do that.
21:09:01 <rbergeron> Do we want to skip the ones in on_qa/verified, or cover those as well?
21:09:06 <pjones> skip
21:09:06 <adamw> pjones: usually we're closer to a determination and we can knock off a few blockers in the meeting, yeah
21:09:17 <rbergeron> #chair adamw
21:09:17 <zodbot> Current chairs: adamw rbergeron
21:09:21 <rbergeron> #chair tflink
21:09:21 <zodbot> Current chairs: adamw rbergeron tflink
21:09:21 <adamw> pjones: but it's pretty cut and dried for this one unfortunately :/
21:09:46 <rbergeron> alrighty.
21:09:50 <rbergeron> #topic Proposed Blockers
21:09:54 <adamw> there are very definitely already reviewed and accepted blockers that are very definitely not fixed in rc3. le sigh.
21:10:04 <rbergeron> #link https://bugzilla.redhat.com/show_bug.cgi?id=729563
21:10:25 <clumens> i have an updates image out for that if anyone would like to test.
21:10:27 <rbergeron> This is the "F16Alpha install does not have selinux enabled!" bug.
21:10:44 <rbergeron> We don't have specific release criteria for alpha about selinux needing to be enabled.
21:11:22 <cebbert> we probably should add that
21:11:26 <rbergeron> Thoughts? adamw, you mentioned in the bz that we could discuss adding it.
21:11:31 <rbergeron> And i agree, as does cebbert.
21:11:34 <dgilmore> i thought we had a selinux must always work criteria
21:11:41 <pjones> for alpha?
21:11:48 <dgilmore> or the system should boot without any audit alerts or some such
21:11:50 <rbergeron> for Final, yes.
21:11:54 <rbergeron> Not for alpha, that i saw.
21:11:55 <pjones> honestly I'm not convinced it's worth the trouble for alpha
21:12:00 <dgilmore> ok
21:12:25 <pjones> You can manually turn it on after install and relabel.
21:12:33 <pjones> it doesn't prevent installation, nor even using selinux.
21:12:33 <rbergeron> #info clumens has an updates image (linked in BZ) for people to try out.
21:12:42 <adamw> we have a criterion that says there should be no selinux alerts (i think it's beta or final)
21:12:49 <adamw> but of course, if selinux is disabled, you won't get any alerts. =)
21:12:52 <tflink> adamw: its final
21:12:54 <clumens> it is kind of embarassingly lame, but alright.
21:12:55 <dgilmore> adamw: thatd good enough for mr
21:12:59 <clumens> left hand, right hand
21:13:03 <adamw> there isn't any criterion for 'selinux must be enabled by default'
21:13:09 <Viking_Alpha> not a bug
21:13:15 <adamw> it probably makes sense to add one, question is whether alpha, beta or final
21:13:18 <pjones> We could flag it as NTH
21:13:34 <Viking_Alpha> yup btw dont we have beta criteria for seliniux
21:13:37 <Viking_Alpha> ?
21:13:38 <adamw> yeah, i'd vote +1 nth for sure
21:13:38 <pjones> Viking_Alpha: that's not exactly constructive help you've got here.
21:13:41 <rbergeron> right. and do we wan to do that *now*, or add it for consideration for beta/final, and deal with what we have now as NTH?
21:13:44 <rbergeron> okay.
21:13:54 <Viking_Alpha> pjones, what do you mean?
21:14:01 <pjones> it most certainly is a bug.
21:14:03 <adamw> if anyone really wants this to be an alpha blocker, we'd need to discuss the criterion issue now
21:14:03 <tflink> +1 alpha NTH
21:14:11 <adamw> if everyone's happy with NTH for alpha, we can discuss the criterion issue later
21:14:16 <Viking_Alpha> ack
21:14:18 * pjones also +1 on NTH
21:14:20 <rbergeron> Propose: #729563, NTH Alpha, consider adding criterion for selinux must be enabled by default later.
21:14:24 <rbergeron> yes?
21:14:25 <adamw> ack
21:14:26 <rbergeron> I think everyone's kosher with that.
21:14:26 <tflink> ack
21:14:28 <pjones> yess.
21:14:33 <Viking_Alpha> ack
21:14:39 <rbergeron> #agreed : #729563, NTH Alpha, consider adding criterion for selinux must be enabled by default later.
21:15:04 <rbergeron> #topic http://bugzilla.redhat.com/show_bug.cgi?id=729500
21:15:20 <rbergeron> #info Error while installing updates on Fedora 16 Alpha RC3
21:15:28 <adamw> this is one i found while doing some desktop validation last night
21:15:39 <tflink> is someone playing secretary for the bug updates?
21:15:43 <adamw> hughesie will look into it, it'd be good if others can test and see if they hit it
21:15:45 <adamw> tflink: you are! ;)
21:15:52 * rbergeron notes she *has* to leave in 15-20 minutes to go do school stuff with kids so they know who their teacher is for school on the first day tomorrow. :\
21:15:56 <tflink> wow, I got volunteered :-D
21:16:01 <rbergeron> tflink: i htink you just got hit by the bus. :)
21:16:08 <adamw> the criterion for this is "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
21:16:26 <rbergeron> Taking proposals....
21:16:31 <adamw> if this error happens reasonably commonly when you try and do updates to an installed f16, i'd say it's a blocker
21:16:35 <rbergeron> is anyone else hitting it?
21:16:38 <adamw> but i'd probably want to see if other people hit it first before voting
21:16:42 <adamw> i don't know if anyone's tried really
21:16:51 <adamw> we've been pretty hung up on all these anaconda / live boot bugs most of the time
21:16:55 <rbergeron> Do we want to hold on it and advertise that we need some tsting on it to duplicate the issue?
21:17:07 <adamw> yeah, i think friday's meeting would be a good time to evaluate this one
21:17:09 <rbergeron> and revisit at blocker meeting friday which we'll presumably have?
21:17:11 <tflink> the only updates I've done were yum from command line
21:17:11 <pjones> yeah
21:17:11 <Viking_Alpha> hum arent upgrades test beta as well ?
21:17:17 <adamw> Viking-Ice: no, it's alpha
21:17:34 <rbergeron> #agreed revisit #729563 at Blocker meeting friday, try to get more testers. PLEASE TEST THIS ONE AND TRY TO DUPLICATE, FOLKS!
21:17:39 <adamw> Viking-Ice: alpha is working browser (which is kind of a proxy for vaguely usable desktop environment) + be able to install updates
21:17:53 <rbergeron> #topic https://bugzilla.redhat.com/show_bug.cgi?id=729528
21:18:09 <rbergeron> #info #729528 - Unable to configure events in reporter to forward in anaconda for F-16-Alpha-RC3
21:18:45 <rbergeron> Anyone want to volunteer criterion this one is hitting?
21:18:49 <adamw> criterion here is "The installer must be able to report failures to Bugzilla, with appropriate information included "
21:18:54 <rbergeron> Thank you, sir.
21:18:55 <adamw> it's a pretty straightforward case
21:18:58 * rbergeron nods
21:19:05 <adamw> rc3 can't report crashes in any way at all, really
21:19:18 <clumens> good.
21:19:23 <adamw> there was one bug with the process in rc1/rc2, that's fixed in rc3, but it's exposed some subsequent bugs, so it still doesn't work
21:19:45 <adamw> there's another bug we'll hit in a bit which is the same thing in text install mode - you can't report anaconda fails in text or graphical mode, it just doesn't work.
21:19:49 <pjones> so shockingly, the completely transparent you won't need to fix anything honest we swear move to libreport basically just didn't work.
21:20:02 <rbergeron> Propose: #729528 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included.
21:20:12 <adamw> pjones: IOW, it's a Nothing Could Possibly Stop Me Now
21:20:45 <adamw> heh
21:20:49 <adamw> +1 blocker
21:20:55 <tflink> ack
21:21:01 <Viking_Alpha> for consistency I nack that one
21:21:09 <adamw> Viking-Ice: note that you actually can't save crashes *at all*
21:21:17 <adamw> Viking-Ice: it's not just bugzilla - you can't save it to a usb key or anything
21:21:29 <pjones> Viking_Alpha: the consistency is that you're -1'ing everything that actually meets the criteria?
21:21:44 <adamw> pjones: viking doesn't agree this should be an alpha criterion
21:21:54 <pjones> adamw: yes, I gathered that.
21:21:55 <Viking_Alpha> pjones your first meeting?
21:22:01 <dgilmore> +1 to blocker from me
21:22:07 <pjones> Viking_Alpha: no, I just usually ignore you.
21:22:19 <rbergeron> #agreed #729528 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included.
21:22:22 * rbergeron moves along
21:22:28 <Viking_Alpha> pjones, then ignore me somewhere else please
21:22:39 <adamw> wow, that's kinda metaphysical.
21:22:53 <rbergeron> #topic http://bugzilla.redhat.com/show_bug.cgi?id=729537
21:23:10 <adamw> so, yeah, same deal, in text mode
21:23:14 <rbergeron> #info 729537 - Anaconda cannot report crashes in text mode in F16 Alpha RC3 due to missing report-cli
21:23:24 <adamw> it may be that these are essentially dupes, kinda depends how you want to look at it
21:23:35 <pjones> yeah
21:23:36 <rbergeron> Propose: #729537 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included.
21:23:43 <tflink> I thought we had talked about not requiring this in text mode
21:23:47 <tflink> or was that firstboot
21:23:53 <tflink> nvm, I'm getting my bugs mixed up
21:23:53 <adamw> tflink: that was firstboot
21:23:57 <clumens> they seem like two different bugs to me, though i have not researched the cause of the first one
21:23:58 <Viking_Alpha> yup that was firstboot
21:24:21 <adamw> clumens: i think the root cause of both is ultimately bits of libreport missing from lorax, or at least that's the sense i get from jiri's comment
21:24:32 <clumens> adamw: ahh
21:24:37 <pjones> this really is a dupe then.
21:24:45 <dgilmore> clumens: is the firstone likely due to dropping off of report* and only having libreport* available?
21:24:46 <adamw> but yeah, +1 blocker, and if it gets made a dupe, fine...we can sort that out outside of the meeting
21:24:48 <clumens> guh, i should have caught this at the same time as i did the same for rhel6.
21:24:50 <rbergeron> ack/nack?
21:24:51 <clumens> my mistake.
21:24:53 <adamw> dgilmore: no, that's not it
21:25:01 <dgilmore> adamw: ok just a thought
21:25:02 <tflink> +1 blocker
21:25:08 <dgilmore> +1 to blocker
21:25:16 <Viking_Alpha> just flag it as dupe
21:25:19 <adamw> dgilmore: i thought the same thing, and checked it :)
21:25:32 <rbergeron> #agreed 729537 Alpha Blocker, per criterion of installer must be able to report failures to BZ, with appropriate info included.
21:25:48 <rbergeron> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728707
21:26:02 <rbergeron> #info 728707 - on package upgrade RPM is removing empty directories accidentally
21:26:11 <adamw> this is an interesting one...
21:26:38 <pjones> somewhat terrifying.
21:26:39 <tflink> I'd say this could fall under not properly applying updates
21:26:43 <adamw> it's clearly an icky bug, it's a bit conceptually vague when it comes to the criteria, and it's something that happens after you've installed and started updating
21:26:51 <adamw> yeah, we could put it in the updates criteria
21:26:55 <pjones> Well, it means upgrades trash the system
21:27:01 <tflink> The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
21:27:16 <jlk> never says has to /instal/ them… :)
21:27:22 <adamw> or we could use the get-out clause
21:27:28 <adamw> "A bug in a Critical Path package that:
21:27:28 <adamw> Cannot be fixed with a future stable update
21:27:28 <adamw> Has a severity rating of high or greater and no reasonable workaround (see definition of severity and priority) "
21:27:43 <adamw> rpm is certainly critical path, and this bug certainly counts as high/urgent
21:28:01 <tflink> do we have any idea what is causing the problem and/or what would need to be fixed?
21:28:03 <adamw> whether it can be fixed with a future stable update is questionable, though i think yum and pk both update rpm before they update anything else
21:28:11 <adamw> tflink: current thinking is it's a bug in rpm, i believe
21:28:23 <pjones> adamw: and "Cannot be fixed with a future stable update" probably also applies, yes.
21:28:32 <tflink> adamw: point. poorly worded question
21:28:54 <tflink> any idea how long we would be waiting for a fix in rpm or would we downgrade?
21:28:59 <adamw> so my caveat here is really just that it doesn't make a deal of sense to hold _the iso composes_ to fix this
21:29:00 <pjones> even if rpm is fixed, it's not going to know which directories to magically put back without a lot of extra work.
21:29:09 <pjones> true.
21:29:13 <adamw> especially since upgrading is completely broken atm, so no-one will be able to hit this by upgrading from f15 to f16a
21:29:21 <adamw> (unless we fix the anaconda upgrade bugs for rc4)
21:29:32 <pjones> we really don't want to make isos that will cause this bug to affect people, though
21:29:32 <tflink> I thought that this was a problem with updates, too - not just upgrade
21:29:44 <pjones> tflink: both, yes.
21:29:46 <adamw> tflink: yes, but think about it like this
21:29:59 <adamw> imagine we ship alpha with this bug in the rpm on the ISOs, but an update that fixes it is available 0-day
21:30:14 <adamw> the first time you upgrade, you'll get the fixed rpm before any other upgrade happens (at least, that's how it should work)
21:30:18 <adamw> so you don't get bitten
21:30:18 <tflink> yeah, that would work
21:30:23 <tflink> assuming we have a fix by then
21:30:42 <jlk> adamw: uh, pretty sure that's not how it works
21:30:42 <spot> seems like a bit assumption at this point.
21:30:50 <rbergeron> Folks: i have to bail for $schoolcrapforkids - if someone can wrap up the meeting, i can ship out the Slippy mail in about an hr when I get home.
21:30:50 <adamw> spot: yeah, it's a bit fragile
21:30:54 * rbergeron bets for a helper.
21:30:55 <tflink> the pessimistic view would be: we release and several people get borked systems because dirs are being deleted on updates before a fix is available
21:30:57 <rbergeron> begs, even
21:31:05 <spot> it would mean that rpm was available before any other updates go out.
21:31:10 <jlk> unless something changed recently, yum doesn't force rpm before anything else.
21:31:10 <adamw> jlk: i'm pretty sure it is, i remember talking to hughsie about it
21:31:23 <adamw> jlk: mmf...maybe it's only PK that does that
21:31:24 <adamw> oh right
21:31:27 <jlk> maybe PK does something, but yum doesn't.
21:31:38 <jlk> can cause some interesting ordering issues too
21:31:45 <adamw> since we had that mess where we got caught in a catch-22 when we shipped a broken PK, PK checks for updates to itself before updating anything else
21:31:46 <jlk> if say your rpm upgrade needs a glibc upgrade
21:31:48 <jlk> and well...
21:31:49 <adamw> but i think you're right and yum doesn't do it
21:31:56 <adamw> so yeah, we would need to fix this on the ISOs
21:32:19 <adamw> in that case...+1 blocker, under whichever criteria wiggle :)
21:32:22 <jlk> yum would have to re-import rpm after the update too, and re-start the update process
21:32:36 * pjones also thinks this is a blocker.
21:32:42 <Viking_Alpha> me too
21:32:44 <tflink> +1 blocker
21:32:49 * dgilmore is +1 blocker
21:32:49 <cebbert> yes, blocker
21:32:51 <Viking_Alpha> +1 blocker
21:33:03 <adamw> i'll take over with proposals and such
21:33:11 * tflink will list the updates criterion unless someone has a better idea
21:33:12 <adamw> (since robyn left)
21:33:19 <adamw> tflink: let's go with that
21:33:36 <adamw> #agreed 728707 is a blocker under 'must be able to install updates' criterion - this constitutes not installing updates properly
21:33:52 * spot has to bail too, but fwiw, this is no-go from where i'm sitting.
21:34:12 <adamw> right
21:34:25 <adamw> i think that's all the proposed blockers
21:34:36 <Viking_Alpha> nope missing mine
21:34:42 <adamw> but i just wnat to check the wiki page is in line with current bugzilla
21:34:43 <rbergeron> thanks. sorry, guys.
21:34:43 <dgilmore> adamw: ok, so we definetly have new blockers
21:34:44 <adamw> ah, i guess it isn't =)
21:34:52 <adamw> just a sec then, let me pull out what we've missed
21:34:54 <rbergeron> yeah, it's a no-go from here too. :\
21:34:54 <dgilmore> adamw: that exist in rc3
21:34:55 <Viking_Alpha> conveniently maybe
21:35:05 <dgilmore> adamw: releng is nogo
21:35:16 <pjones> yeah, so everybody thinks it's no-go.
21:35:25 <dgilmore> pjones: i think so
21:35:42 <dgilmore> pjones: whats your thoughts?
21:35:46 <clumens> so it looks like i need to do yet another anaconda build whilst waiting on selinux results
21:35:54 <adamw> Viking-Ice: where's yours? it doesn't show up in the f16alpha list
21:36:12 <Viking_Alpha> 729600
21:36:21 <pjones> dgilmore: definitely no-go from here.
21:36:52 * jsmith is back online
21:36:57 <adamw> Viking-Ice: ah. clumens took it off the list.
21:37:10 <pjones> because it doesn't meet any of the criteria.
21:37:15 <adamw> well.
21:37:22 <adamw> that's what blocker review meetings are supposed to decide.
21:37:30 <adamw> it's rather bad form to un-propose a blocker someone else proposed.
21:37:37 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=729600
21:37:54 <adamw> a bug that's blocking f16alpha (or whatever) but not marked AcceptedBlocker is a *proposed* blocker, not an accepted one.
21:38:17 <Viking_Alpha> hey anaconda team here is to vote on their own bugs if they are blockers so it does not change matter if they remove it from the list or vote it down anyway
21:38:27 <adamw> you can vote against this being a blocker, but taking it off f16alpha prevents it from being properly considered at a review meeting, so...please don't do that =)
21:38:54 <adamw> so
21:38:59 <adamw> what's the exact impact of this bug?
21:39:04 <pjones> I'm very tempted to NOTABUG it, honestly.
21:39:07 <Viking_Alpha> the main problem is that anconda errors out after it has wiped the disk not before leaving the end user with no installed system to return to and no means of installing it ( that is if they are without network connection )
21:39:08 <clumens> i don't even consider it yeah
21:39:09 <jlk> the bug should have just been closed
21:39:12 <jlk> it's not a bug.
21:39:22 <adamw> installs from the DVD ISO dd'ed to a USB stick fail?
21:39:29 <adamw> i do think the impact viking mentions above is a rather icky one.
21:39:39 <clumens> adamw: see my most recent comment.
21:39:39 <jlk> Viking-Ice: it errored out because you didn't let it get on the network when it asked.
21:39:48 <jlk> adamw: read the bug again.
21:39:50 <Viking_Alpha> there was no network
21:40:09 <Viking_Alpha> and it asked for the network connection after it had finished the partitioning setup
21:40:11 <Viking_Alpha> not before
21:40:11 * nirik arrives, thought meeting was in 20min. ;(
21:40:23 <adamw> nirik: heh, np
21:40:28 <Viking_Alpha> it was advertised to start 22:00 some one changed it
21:40:34 <Viking_Alpha> utc that is
21:40:41 <adamw> Viking-Ice: i think someone got UTC wrong
21:40:51 <adamw> Viking-Ice: we started at the eastern time listed in the announce
21:40:53 <Viking_Alpha> can that network dialog be moved before the partitioning happens ?
21:40:58 <pjones> look, there's no way we're going to radically re-design anaconda for htis.
21:41:38 <jlk> also, that's not why this was proposed as a blocker
21:41:40 * dgilmore thinks at best its a documentation issue
21:41:45 <adamw> so...what this tracks down to is we don't consider 'dd the DVD ISO to a USB stick' to be a supported install method
21:41:46 <pjones> we bring up the network when we need to hit repos if there are no local repos configured.  In this case, there aren't.
21:41:55 <jlk> you're playing move the goalposts a bit here.
21:42:02 <adamw> it's somewhat unfortunate that what happens is it kinda works but fails quite late on, which can potentially leave you a little in the soup.
21:42:04 <jlk> adamw: it's supported, if you use the network
21:42:09 <pjones> adamw: it isn't in the criteria.
21:42:15 <pjones> it doesn't fail.
21:42:17 <pjones> it's working.
21:42:21 <tflink> it sounds like you could use askmethod, too
21:42:22 <pjones> there's no failure.
21:42:26 <dgilmore> adamw: but with the right documentation it could be made to work
21:42:27 <jlk> adamw: what's not supported, is attempting an install type that requires the network, without having functional network.
21:42:28 <dgilmore> i believe
21:42:35 <adamw> jlk: moving goalposts is fine. it's not a Moral Rectitude Contest, we're establishing whether or not bugs are blockers. if a bug is proposed under one rationale but we discover another valid rationale, that's fine.
21:42:36 <tflink> it's just the autodetection that isn't a feature of anaconda for usb
21:43:22 <adamw> jlk: well, the thing is, if you're installing from a 'complete' installer image you're not necessarily expecting to need a network connection.
21:43:32 <Viking_Alpha> does it require radical redesign move that network check before partitioning ?
21:43:34 <pjones> We're not saying we won't take patches to make it detect this, but currently there is no failure here.
21:43:35 <jlk> adamw: except Anaconda hasn't supported this.  Ever.
21:43:42 <pjones> Viking_Alpha: yes
21:43:47 <jlk> adamw: so making it release criteria seems… less than useful.
21:44:02 <adamw> jlk: sure. as i said, it's fine for it to be unsupported. it's a bit unfortunate how exactly that pans out in the present situation...
21:44:09 <pjones> Viking_Alpha: also it's pretty questionable - loading repos before setting up swap changes our memory requirements.
21:44:11 <adamw> why does dding the installer image to a USB stick work at all, btw?
21:44:25 <adamw> it needs to be intentionally made a hybrid ISO for that to work, right?
21:44:29 <jlk> yes
21:44:35 <jlk> the compose process makes them hybrid
21:44:35 <adamw> could we 'fix' this simply by making it *not* a hybrid ISO?
21:44:40 <adamw> so you can't dd it at all?
21:44:48 <Viking_Alpha> that would solve this
21:44:54 <clumens> or by mangling the bootloader config to add "askmethod"
21:45:02 <adamw> to me, if you're not supposed to do this, an ISO which makes it not possible is better than one which makes it possible
21:45:04 <jlk> clumens: ngggh
21:45:09 <dgilmore> adamw: the isohyrid run is brand new in f16
21:45:10 <Viking_Alpha> adamw, agreed
21:45:15 <jlk> clumens: that would require re-calling mkisofs before the isohybrid
21:45:17 <nirik> I suppose...
21:45:24 <adamw> obviously we want the live images to be hybrid, but if anaconda isn't interesting in supporting hybrid functionality, why not just...make it not hybrid?
21:45:29 <jlk> clumens: or rather it'd mean that the DVD would always ask method
21:45:35 * nirik notes many people have tried to dd the dvd iso and had it fail anyhow in the past.
21:45:38 <pjones> so we could call this a bug if that's intended to work from here forward, but I'm very much against making new requirements a blocker.
21:45:45 <pjones> certainly not an *alpha* blocker.
21:46:09 <pjones> adamw: nobody said we're not interested - but it's exactly that, a feature request.
21:46:20 <Viking_Alpha> In my books this is far more serious issue than users not being able report to bugzilla
21:46:34 <pjones> Viking_Alpha: that's completely unreasonable.
21:46:38 <adamw> pjones: i'm working towards a resolution here, gimme a minute =)
21:46:48 <jlk> if you make it a blocker, the fix is to remove this method from documentation.
21:46:54 <adamw> so...how complex would it be to make the ISO not hybrid?
21:47:00 <clumens> jlk: yeah, and having the DVD always askmethod kind of defeats the entire purpose
21:47:02 <adamw> is it something we could easily change for rc4?
21:47:06 <nirik> adamw: not very.
21:47:08 <pjones> adamw: one character in lorax, I suspect.
21:47:09 <dgilmore> jlk: i dont think this method is in the documentation
21:47:15 <jlk> dgilmore: it is, I checked
21:47:15 <adamw> clumens: yeah, i don't like the 'always askmethod' idea either.
21:47:23 <dgilmore> jlk: huh ok
21:47:30 <jlk> http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/Making_USB_Media-UNIX_Linux.html
21:47:33 <jlk> toward the bottom
21:47:42 <nirik> jlk: except it never worked in f15. ;)
21:47:43 <dgilmore> jlk: we only added the call to isohybrid  to pungi after f15 ga
21:47:43 <jlk> however the docs don't mention that you'll have to use the network or askmethod
21:47:45 <jlk> d
21:47:50 <jlk> however the docs don't mention that you'll have to use the network or askmethod
21:48:00 <nirik> and that it won't work at all. ;)
21:48:03 <dgilmore> jlk: so in f15 using dd wont work
21:48:05 <jlk> dgilmore: the boot.iso was hybrid for f14
21:48:12 <clumens> documentation is README encrypted, though
21:48:16 <clumens> unbreakable
21:48:18 <nirik> yeah, boot iso has been, not dvd
21:48:21 <pjones> right, and boot.iso is effectively always network
21:48:24 <dgilmore> jlk: yeah but the dvd is not hybrid
21:48:25 <adamw> so...proposal
21:48:33 <jlk> dgilmore: the docs don't distinguish
21:48:48 <jlk> actually
21:48:51 <Viking_Alpha> if doable drop the support to dd the iso to usb
21:48:54 <dgilmore> jlk: they should because using dd on a dvd wont work in f15 and earlier
21:48:56 <jlk> the docs seem to be written for Live CDs, not other media
21:48:56 <adamw> proposal: accept this as NTH for alpha, and 'fix' it by making the rc4 DVD image not hybrid. and adjust the documentation
21:48:57 <nirik> anyhow, I'd suggest not a alpha blocker, see if anaconda folks can come up with a way to support this for beta, update docs accordingly?
21:49:07 <pjones> adamw: that sucks.
21:49:11 <dgilmore> jlk: anyways. seems thats a bug in the docs
21:49:14 <pjones> adamw: at the very least, we have to fix the docs
21:49:25 <pjones> adamw: I propose we fix the docs for alpha and get clumens to evaluate this for later in f16.
21:49:26 <jlk> that's my counter proposal as well
21:49:35 <clumens> pjones: how generous of you.
21:49:37 <jlk> pjones: +1
21:49:40 * nirik +1 to pjones suggestion
21:49:54 <adamw> to clarify: that is, don't change anything in the software for alpha?
21:49:58 <tflink> +1 to adamw's proposal
21:50:11 <Viking_Alpha> +1 adamw proposal
21:50:12 <pjones> tflink: to leave the docs saying something is supported when it isn't?
21:50:15 <dgilmore> +1 to pjones proposal
21:50:22 <adamw> pjones: my proposal included a docs change.
21:50:26 <tflink> pjones: adamw's proposal says to update docs
21:50:27 <adamw> pjones: my proposal is a superset of yours.
21:50:37 <pjones> oh, indeed.
21:50:46 <pjones> still, NTH is a bit of an overstep.
21:50:48 <tflink> at the minimum, we need to modify docs
21:50:55 <jlk> also, it is useful for the isos to be hybrid
21:50:55 <nirik> the only difference is that someone will dd it and it will fail to boot vs appear to start installing then fail.
21:51:02 <dgilmore> adamw: id rather not change pungi for this if we end up having it supported in the future.  id rathe jut document the need to add a boot option
21:51:03 <jlk> so I don't see the point in making them non-hybrid
21:51:09 <jlk> you can still use ask method and use the media IIRC
21:51:14 <jlk> or do a network install
21:51:14 <pjones> jlk: yes
21:51:15 <jlk> or rescue
21:51:17 <adamw> jlk: my proposal was to make only the DVD iso non-hybrid
21:51:19 <Viking_Alpha> nirik, leaving the current installed systemd intact for the user
21:51:25 <adamw> boot.iso and lives would still be hybrid
21:51:26 <clumens> ugh.
21:51:31 <nirik> Viking_Alpha: ah, good point...
21:51:32 <jlk> adamw: see avobe, it's useful to have the dvd iso hybrid
21:51:36 <adamw> okay.
21:51:36 <pjones> nirik: no, it'll appear to start installing and then when they point it at a repo it'll continue to install.
21:51:43 <adamw> well, at least we can say:
21:51:48 <dgilmore> adamw: and its really easy for someone to run isohybrid themselves if we dont
21:51:52 <nirik> release note?
21:52:02 <adamw> #agreed installation documentation should be updated to clarify that dding the DVD ISO to a USB stick is not a supported install mechanism
21:52:12 <jlk> seriously this is all a misunderstanding of what's expected to work when you dd a dvd iso
21:52:16 <adamw> dgilmore: sure, at which they get to keep both halves. (even more so than usual.)
21:52:17 <jlk> clarify the docs, move on
21:52:27 <clumens> just update the documentation to tell the user to add "askmethod" and pick HD ISO
21:52:28 <pjones> jlk: yeah.
21:52:41 <jlk> adamw: I disagree with your proposed doc change.
21:52:46 <adamw> #undo
21:52:46 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x10246ccc>
21:52:49 <jlk> it /is/ supported, if you do it correctly
21:52:50 <adamw> jlk: sorry, i didn't propose
21:52:53 <adamw> jlk: patch?
21:53:19 <adamw> so, just to be clear for the record: you *can* install from a dvd iso dd'ed to a usb stick, without a network connection, with appropriate configuration?
21:53:29 <adamw> (i.e. specifying askmethod and HD ISO)
21:53:33 <jlk> adamw: I believe that to be correct.
21:53:38 <clumens> adamw: yes
21:53:39 <jlk> I don't have the means to test that right this moment.
21:53:45 <adamw> okay. so it's a retrievable situation, too.
21:53:55 <clumens> you could either use "askmethod" and follow the menu, or "method=hd:blahblahblah"
21:54:10 <Viking_Alpha> then slap a warning and proper guidelines in docs would suffice
21:54:15 <pjones> or you could use the network.
21:54:21 <adamw> okay...with all that in consideration, i agree with not changing code for alpha
21:54:29 <adamw> so:
21:54:38 <nirik> and release note for alpha? do we still do one page or other notes?
21:55:04 <tflink> nirik: we did wiki page for F15 alpha, I assume we'll do the same for F16
21:55:13 <adamw> propose #agreed not blocker or nth, installing from a dd'ed DVD iso is expected to require extra configuration. documentation should be improved to outline the steps required.
21:55:24 <Viking_Alpha> ack
21:55:26 <jlk> +1
21:55:28 <adamw> nirik: yeah, there sohuld be alpha release notes
21:55:29 * nirik nods. sounds good. ack
21:55:30 <tflink> is this an acceptable solution for final, then?
21:55:43 <clumens> good with me
21:55:50 <tflink> or just alpha and may be re-visited later?
21:55:54 <pjones> tflink: it may still be worth revisiting if we can make this not need those steps, but that's way off in blue-sky land.
21:56:05 <nirik> well, if something else changes in anaconda we should update based on that...
21:56:09 <nirik> yeah
21:56:09 <pjones> right.
21:56:23 <tflink> I'm fine with this for alpha but I'm not crazy about just docs for final
21:56:27 <adamw> #agreed 729600 not blocker or nth, installing from a dd'ed DVD iso is expected to require extra configuration. documentation should be improved to outline the steps required
21:56:30 <dgilmore> adamw: +1 to your proposal
21:56:40 <nirik> tflink: we can revisit if needed.
21:56:46 <adamw> (i counted sufficient consensus on this one)
21:56:59 <adamw> okay, glad we got that one thrashed out in the end :)
21:57:28 <adamw> it's worth visiting one last bug
21:57:30 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728863
21:57:30 <pjones> since this is my proposal from 8 minutes ago, I'm totally coll with it.
21:57:46 <adamw> pjones: yeah, i think it was worth the extra clarification we got to later though :)
21:58:01 <adamw> so, we skipped this as it was ON_QA, but it's important to note this is not fixed in rc3
21:58:23 <adamw> rc3 live images fail to boot due to this bug, and other installs would have a few issues if we didn't have the 'selinux is disabled by default' bug =)
21:58:25 <pjones> Well, there's a workaround for this, but it's a bit tedious.
21:58:42 <adamw> yeah, you have to boot with selinux off, and if you want it on, do a relabel.
21:59:08 <adamw> so we think we finally identified a fix for it, but it needs testing and, again, isn't in rc3. so for the purposes of this meeting, it's another strike against go.
21:59:10 <pjones> it's a bit worse than the disabled by default bug - it actually prevents systems from booting by default
21:59:27 <adamw> soo...just wanted to flag it up for the record and all.
21:59:46 * nirik waits for bugzilla.
22:00:25 <adamw> so, i think we can go (back) to the formal vote, which should be a bit of a no-brainer
22:00:30 <adamw> #topic go/no-go vote
22:00:31 <pjones> so, we're all still no-go.
22:00:39 <Viking_Alpha> yup
22:00:47 <adamw> yup. again, qa is no-go, there are open, confirmed blockers unresolved in rc3.
22:00:49 <nirik> yeah, sadly, another alpha, another slip. ;(
22:01:12 <dgilmore> releng isn no-go  again for the record
22:01:16 <athmane> and another testing fun
22:01:21 <adamw> so, we have -1s from qa, releng and devel
22:01:32 <adamw> #agreed Fedora 16 Alpha is no-go at this time
22:01:42 <dgilmore> review again in a week?
22:01:52 <adamw> yeah, procedure is to push everything out a week
22:02:04 <adamw> #action rbergeron will take care of updating the schedules
22:02:07 <adamw> (she'll love me for that)
22:02:23 <tk009> final release everything everyting?
22:02:23 <tflink> hey, she left early :-D
22:02:25 * nirik considers a scheduling change to the schedule, but thats out of scope of this meeting.
22:02:28 <adamw> so we'll get an rc4 spun once we identify fixes for all the open blockers, we have another blocker review on friday, and we'll do this again next week
22:02:47 <adamw> tk009: that's the process, yeah, we push *everytihng* a week
22:03:08 <adamw> as was noted in the announcement email for this meeting, the readiness meeting tomorrow is going ahead *even though we're no-go*
22:03:17 <adamw> so if you're supposed to be at the readiness meeting...you're still supposed to be at it
22:03:23 <adamw> i dunno what'll happen in it, but hey! we'll find out
22:03:40 <adamw> #topic open floor
22:03:50 <adamw> any other business for the meeting? i figure we can skip nth review and stuff, leave that for friday.
22:03:52 <pjones> So we're done then, right?  And I can eat vindaloo?
22:04:00 <adamw> unless anyone has anything to bring up, yup
22:04:23 <adamw> going once...
22:04:33 <dgilmore> pjones: enjoy the vindaloo
22:04:41 <adamw> twice...
22:05:04 <rbergeron> lol
22:05:04 <adamw> thanks all!
22:05:08 <adamw> #endmeeting