21:00:26 #startmeeting F16 Alpha Go/No-Go Meeting 21:00:26 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:31 thanks everybody for somint 21:00:40 #meetingname F16 Alpha Go/No-Go Meeting 21:00:40 The meeting name has been set to 'f16_alpha_go/no-go_meeting' 21:01:19 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 rbergeron: hola 21:02:40 hai. 21:02:44 * rbergeron looks for QA lovin' 21:02:57 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 yo 21:03:42 #info present: spot, codeblock, dgilmore, pjones, athmane, cebbert, jsmith-mobile, adamw 21:03:46 * adamw was making a smoothie 21:03:58 ooh. 21:03:59 I hope you're sharing. 21:04:07 #topic Go/No-Go Meeting 21:04:08 hello everyone 21:04:28 i'm present too, just in case a voice of installation sanity is needed. 21:04:47 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 rbergeron: i tried a /dsc send but you didn't respond 21:05:05 rbergeron: that's the Fedora spirit we know and love. 21:05:07 are you not set up for Direct Smoothie Connection? 21:05:28 #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 pjones: :) 21:05:43 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 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 nope 21:06:17 well, we have documentation! 21:06:17 https://fedoraproject.org/wiki/Go_No_Go_Meeting 21:06:24 Yeah. 21:06:32 to which a little bit has been added since last time 21:06:32 Well, firefox is working up its courage to restart here on my end of life. 21:06:42 #link https://fedoraproject.org/wiki/Current_Release_Blockers <-- that one I know by heart, though. 21:06:46 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 Awesome. 21:07:03 so...since there are accepted blocker bugs that are unaddressed in the candidate compose...QA votes no-go 21:07:14 So I don't even need to ask. ;) 21:07:16 Yeah. 21:07:38 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 adamw: presumably we discuss those bugs and if it's still true at the *end* of the meeting, QA votes no? ;) 21:07:53 releng votes no-go 21:08:09 or are we just going to skip that part and assume it's done? 21:08:20 (I'm actually fine with that) 21:08:21 pjones: we do normally go over the bugs 21:08:38 Yup. Let's do that. 21:09:01 Do we want to skip the ones in on_qa/verified, or cover those as well? 21:09:06 skip 21:09:06 pjones: usually we're closer to a determination and we can knock off a few blockers in the meeting, yeah 21:09:17 #chair adamw 21:09:17 Current chairs: adamw rbergeron 21:09:21 #chair tflink 21:09:21 Current chairs: adamw rbergeron tflink 21:09:21 pjones: but it's pretty cut and dried for this one unfortunately :/ 21:09:46 alrighty. 21:09:50 #topic Proposed Blockers 21:09:54 there are very definitely already reviewed and accepted blockers that are very definitely not fixed in rc3. le sigh. 21:10:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=729563 21:10:25 i have an updates image out for that if anyone would like to test. 21:10:27 This is the "F16Alpha install does not have selinux enabled!" bug. 21:10:44 We don't have specific release criteria for alpha about selinux needing to be enabled. 21:11:22 we probably should add that 21:11:26 Thoughts? adamw, you mentioned in the bz that we could discuss adding it. 21:11:31 And i agree, as does cebbert. 21:11:34 i thought we had a selinux must always work criteria 21:11:41 for alpha? 21:11:48 or the system should boot without any audit alerts or some such 21:11:50 for Final, yes. 21:11:54 Not for alpha, that i saw. 21:11:55 honestly I'm not convinced it's worth the trouble for alpha 21:12:00 ok 21:12:25 You can manually turn it on after install and relabel. 21:12:33 it doesn't prevent installation, nor even using selinux. 21:12:33 #info clumens has an updates image (linked in BZ) for people to try out. 21:12:42 we have a criterion that says there should be no selinux alerts (i think it's beta or final) 21:12:49 but of course, if selinux is disabled, you won't get any alerts. =) 21:12:52 adamw: its final 21:12:54 it is kind of embarassingly lame, but alright. 21:12:55 adamw: thatd good enough for mr 21:12:59 left hand, right hand 21:13:03 there isn't any criterion for 'selinux must be enabled by default' 21:13:09 not a bug 21:13:15 it probably makes sense to add one, question is whether alpha, beta or final 21:13:18 We could flag it as NTH 21:13:34 yup btw dont we have beta criteria for seliniux 21:13:37 ? 21:13:38 yeah, i'd vote +1 nth for sure 21:13:38 Viking_Alpha: that's not exactly constructive help you've got here. 21:13:41 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 okay. 21:13:54 pjones, what do you mean? 21:14:01 it most certainly is a bug. 21:14:03 if anyone really wants this to be an alpha blocker, we'd need to discuss the criterion issue now 21:14:03 +1 alpha NTH 21:14:11 if everyone's happy with NTH for alpha, we can discuss the criterion issue later 21:14:16 ack 21:14:18 * pjones also +1 on NTH 21:14:20 Propose: #729563, NTH Alpha, consider adding criterion for selinux must be enabled by default later. 21:14:24 yes? 21:14:25 ack 21:14:26 I think everyone's kosher with that. 21:14:26 ack 21:14:28 yess. 21:14:33 ack 21:14:39 #agreed : #729563, NTH Alpha, consider adding criterion for selinux must be enabled by default later. 21:15:04 #topic http://bugzilla.redhat.com/show_bug.cgi?id=729500 21:15:20 #info Error while installing updates on Fedora 16 Alpha RC3 21:15:28 this is one i found while doing some desktop validation last night 21:15:39 is someone playing secretary for the bug updates? 21:15:43 hughesie will look into it, it'd be good if others can test and see if they hit it 21:15:45 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 wow, I got volunteered :-D 21:16:01 tflink: i htink you just got hit by the bus. :) 21:16:08 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 Taking proposals.... 21:16:31 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 is anyone else hitting it? 21:16:38 but i'd probably want to see if other people hit it first before voting 21:16:42 i don't know if anyone's tried really 21:16:51 we've been pretty hung up on all these anaconda / live boot bugs most of the time 21:16:55 Do we want to hold on it and advertise that we need some tsting on it to duplicate the issue? 21:17:07 yeah, i think friday's meeting would be a good time to evaluate this one 21:17:09 and revisit at blocker meeting friday which we'll presumably have? 21:17:11 the only updates I've done were yum from command line 21:17:11 yeah 21:17:11 hum arent upgrades test beta as well ? 21:17:17 Viking-Ice: no, it's alpha 21:17:34 #agreed revisit #729563 at Blocker meeting friday, try to get more testers. PLEASE TEST THIS ONE AND TRY TO DUPLICATE, FOLKS! 21:17:39 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 #topic https://bugzilla.redhat.com/show_bug.cgi?id=729528 21:18:09 #info #729528 - Unable to configure events in reporter to forward in anaconda for F-16-Alpha-RC3 21:18:45 Anyone want to volunteer criterion this one is hitting? 21:18:49 criterion here is "The installer must be able to report failures to Bugzilla, with appropriate information included " 21:18:54 Thank you, sir. 21:18:55 it's a pretty straightforward case 21:18:58 * rbergeron nods 21:19:05 rc3 can't report crashes in any way at all, really 21:19:18 good. 21:19:23 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 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 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 Propose: #729528 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included. 21:20:12 pjones: IOW, it's a Nothing Could Possibly Stop Me Now 21:20:45 heh 21:20:49 +1 blocker 21:20:55 ack 21:21:01 for consistency I nack that one 21:21:09 Viking-Ice: note that you actually can't save crashes *at all* 21:21:17 Viking-Ice: it's not just bugzilla - you can't save it to a usb key or anything 21:21:29 Viking_Alpha: the consistency is that you're -1'ing everything that actually meets the criteria? 21:21:44 pjones: viking doesn't agree this should be an alpha criterion 21:21:54 adamw: yes, I gathered that. 21:21:55 pjones your first meeting? 21:22:01 +1 to blocker from me 21:22:07 Viking_Alpha: no, I just usually ignore you. 21:22:19 #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 pjones, then ignore me somewhere else please 21:22:39 wow, that's kinda metaphysical. 21:22:53 #topic http://bugzilla.redhat.com/show_bug.cgi?id=729537 21:23:10 so, yeah, same deal, in text mode 21:23:14 #info 729537 - Anaconda cannot report crashes in text mode in F16 Alpha RC3 due to missing report-cli 21:23:24 it may be that these are essentially dupes, kinda depends how you want to look at it 21:23:35 yeah 21:23:36 Propose: #729537 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included. 21:23:43 I thought we had talked about not requiring this in text mode 21:23:47 or was that firstboot 21:23:53 nvm, I'm getting my bugs mixed up 21:23:53 tflink: that was firstboot 21:23:57 they seem like two different bugs to me, though i have not researched the cause of the first one 21:23:58 yup that was firstboot 21:24:21 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 adamw: ahh 21:24:37 this really is a dupe then. 21:24:45 clumens: is the firstone likely due to dropping off of report* and only having libreport* available? 21:24:46 but yeah, +1 blocker, and if it gets made a dupe, fine...we can sort that out outside of the meeting 21:24:48 guh, i should have caught this at the same time as i did the same for rhel6. 21:24:50 ack/nack? 21:24:51 my mistake. 21:24:53 dgilmore: no, that's not it 21:25:01 adamw: ok just a thought 21:25:02 +1 blocker 21:25:08 +1 to blocker 21:25:16 just flag it as dupe 21:25:19 dgilmore: i thought the same thing, and checked it :) 21:25:32 #agreed 729537 Alpha Blocker, per criterion of installer must be able to report failures to BZ, with appropriate info included. 21:25:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=728707 21:26:02 #info 728707 - on package upgrade RPM is removing empty directories accidentally 21:26:11 this is an interesting one... 21:26:38 somewhat terrifying. 21:26:39 I'd say this could fall under not properly applying updates 21:26:43 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 yeah, we could put it in the updates criteria 21:26:55 Well, it means upgrades trash the system 21:27:01 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 never says has to /instal/ them… :) 21:27:22 or we could use the get-out clause 21:27:28 "A bug in a Critical Path package that: 21:27:28 Cannot be fixed with a future stable update 21:27:28 Has a severity rating of high or greater and no reasonable workaround (see definition of severity and priority) " 21:27:43 rpm is certainly critical path, and this bug certainly counts as high/urgent 21:28:01 do we have any idea what is causing the problem and/or what would need to be fixed? 21:28:03 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 tflink: current thinking is it's a bug in rpm, i believe 21:28:23 adamw: and "Cannot be fixed with a future stable update" probably also applies, yes. 21:28:32 adamw: point. poorly worded question 21:28:54 any idea how long we would be waiting for a fix in rpm or would we downgrade? 21:28:59 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 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 true. 21:29:13 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 (unless we fix the anaconda upgrade bugs for rc4) 21:29:32 we really don't want to make isos that will cause this bug to affect people, though 21:29:32 I thought that this was a problem with updates, too - not just upgrade 21:29:44 tflink: both, yes. 21:29:46 tflink: yes, but think about it like this 21:29:59 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 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 so you don't get bitten 21:30:18 yeah, that would work 21:30:23 assuming we have a fix by then 21:30:42 adamw: uh, pretty sure that's not how it works 21:30:42 seems like a bit assumption at this point. 21:30:50 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 spot: yeah, it's a bit fragile 21:30:54 * rbergeron bets for a helper. 21:30:55 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 begs, even 21:31:05 it would mean that rpm was available before any other updates go out. 21:31:10 unless something changed recently, yum doesn't force rpm before anything else. 21:31:10 jlk: i'm pretty sure it is, i remember talking to hughsie about it 21:31:23 jlk: mmf...maybe it's only PK that does that 21:31:24 oh right 21:31:27 maybe PK does something, but yum doesn't. 21:31:38 can cause some interesting ordering issues too 21:31:45 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 if say your rpm upgrade needs a glibc upgrade 21:31:48 and well... 21:31:49 but i think you're right and yum doesn't do it 21:31:56 so yeah, we would need to fix this on the ISOs 21:32:19 in that case...+1 blocker, under whichever criteria wiggle :) 21:32:22 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 me too 21:32:44 +1 blocker 21:32:49 * dgilmore is +1 blocker 21:32:49 yes, blocker 21:32:51 +1 blocker 21:33:03 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 (since robyn left) 21:33:19 tflink: let's go with that 21:33:36 #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 right 21:34:25 i think that's all the proposed blockers 21:34:36 nope missing mine 21:34:42 but i just wnat to check the wiki page is in line with current bugzilla 21:34:43 thanks. sorry, guys. 21:34:43 adamw: ok, so we definetly have new blockers 21:34:44 ah, i guess it isn't =) 21:34:52 just a sec then, let me pull out what we've missed 21:34:54 yeah, it's a no-go from here too. :\ 21:34:54 adamw: that exist in rc3 21:34:55 conveniently maybe 21:35:05 adamw: releng is nogo 21:35:16 yeah, so everybody thinks it's no-go. 21:35:25 pjones: i think so 21:35:42 pjones: whats your thoughts? 21:35:46 so it looks like i need to do yet another anaconda build whilst waiting on selinux results 21:35:54 Viking-Ice: where's yours? it doesn't show up in the f16alpha list 21:36:12 729600 21:36:21 dgilmore: definitely no-go from here. 21:36:52 * jsmith is back online 21:36:57 Viking-Ice: ah. clumens took it off the list. 21:37:10 because it doesn't meet any of the criteria. 21:37:15 well. 21:37:22 that's what blocker review meetings are supposed to decide. 21:37:30 it's rather bad form to un-propose a blocker someone else proposed. 21:37:37 #topic https://bugzilla.redhat.com/show_bug.cgi?id=729600 21:37:54 a bug that's blocking f16alpha (or whatever) but not marked AcceptedBlocker is a *proposed* blocker, not an accepted one. 21:38:17 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 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 so 21:38:59 what's the exact impact of this bug? 21:39:04 I'm very tempted to NOTABUG it, honestly. 21:39:07 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 i don't even consider it yeah 21:39:09 the bug should have just been closed 21:39:12 it's not a bug. 21:39:22 installs from the DVD ISO dd'ed to a USB stick fail? 21:39:29 i do think the impact viking mentions above is a rather icky one. 21:39:39 adamw: see my most recent comment. 21:39:39 Viking-Ice: it errored out because you didn't let it get on the network when it asked. 21:39:48 adamw: read the bug again. 21:39:50 there was no network 21:40:09 and it asked for the network connection after it had finished the partitioning setup 21:40:11 not before 21:40:11 * nirik arrives, thought meeting was in 20min. ;( 21:40:23 nirik: heh, np 21:40:28 it was advertised to start 22:00 some one changed it 21:40:34 utc that is 21:40:41 Viking-Ice: i think someone got UTC wrong 21:40:51 Viking-Ice: we started at the eastern time listed in the announce 21:40:53 can that network dialog be moved before the partitioning happens ? 21:40:58 look, there's no way we're going to radically re-design anaconda for htis. 21:41:38 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 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 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 you're playing move the goalposts a bit here. 21:42:02 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 adamw: it's supported, if you use the network 21:42:09 adamw: it isn't in the criteria. 21:42:15 it doesn't fail. 21:42:17 it's working. 21:42:21 it sounds like you could use askmethod, too 21:42:22 there's no failure. 21:42:26 adamw: but with the right documentation it could be made to work 21:42:27 adamw: what's not supported, is attempting an install type that requires the network, without having functional network. 21:42:28 i believe 21:42:35 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 it's just the autodetection that isn't a feature of anaconda for usb 21:43:22 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 does it require radical redesign move that network check before partitioning ? 21:43:34 We're not saying we won't take patches to make it detect this, but currently there is no failure here. 21:43:35 adamw: except Anaconda hasn't supported this. Ever. 21:43:42 Viking_Alpha: yes 21:43:47 adamw: so making it release criteria seems… less than useful. 21:44:02 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 Viking_Alpha: also it's pretty questionable - loading repos before setting up swap changes our memory requirements. 21:44:11 why does dding the installer image to a USB stick work at all, btw? 21:44:25 it needs to be intentionally made a hybrid ISO for that to work, right? 21:44:29 yes 21:44:35 the compose process makes them hybrid 21:44:35 could we 'fix' this simply by making it *not* a hybrid ISO? 21:44:40 so you can't dd it at all? 21:44:48 that would solve this 21:44:54 or by mangling the bootloader config to add "askmethod" 21:45:02 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 clumens: ngggh 21:45:09 adamw: the isohyrid run is brand new in f16 21:45:10 adamw, agreed 21:45:15 clumens: that would require re-calling mkisofs before the isohybrid 21:45:17 I suppose... 21:45:24 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 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 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 certainly not an *alpha* blocker. 21:46:09 adamw: nobody said we're not interested - but it's exactly that, a feature request. 21:46:20 In my books this is far more serious issue than users not being able report to bugzilla 21:46:34 Viking_Alpha: that's completely unreasonable. 21:46:38 pjones: i'm working towards a resolution here, gimme a minute =) 21:46:48 if you make it a blocker, the fix is to remove this method from documentation. 21:46:54 so...how complex would it be to make the ISO not hybrid? 21:47:00 jlk: yeah, and having the DVD always askmethod kind of defeats the entire purpose 21:47:02 is it something we could easily change for rc4? 21:47:06 adamw: not very. 21:47:08 adamw: one character in lorax, I suspect. 21:47:09 jlk: i dont think this method is in the documentation 21:47:15 dgilmore: it is, I checked 21:47:15 clumens: yeah, i don't like the 'always askmethod' idea either. 21:47:23 jlk: huh ok 21:47:30 http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/Making_USB_Media-UNIX_Linux.html 21:47:33 toward the bottom 21:47:42 jlk: except it never worked in f15. ;) 21:47:43 jlk: we only added the call to isohybrid to pungi after f15 ga 21:47:43 however the docs don't mention that you'll have to use the network or askmethod 21:47:45 d 21:47:50 however the docs don't mention that you'll have to use the network or askmethod 21:48:00 and that it won't work at all. ;) 21:48:03 jlk: so in f15 using dd wont work 21:48:05 dgilmore: the boot.iso was hybrid for f14 21:48:12 documentation is README encrypted, though 21:48:16 unbreakable 21:48:18 yeah, boot iso has been, not dvd 21:48:21 right, and boot.iso is effectively always network 21:48:24 jlk: yeah but the dvd is not hybrid 21:48:25 so...proposal 21:48:33 dgilmore: the docs don't distinguish 21:48:48 actually 21:48:51 if doable drop the support to dd the iso to usb 21:48:54 jlk: they should because using dd on a dvd wont work in f15 and earlier 21:48:56 the docs seem to be written for Live CDs, not other media 21:48:56 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 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 adamw: that sucks. 21:49:11 jlk: anyways. seems thats a bug in the docs 21:49:14 adamw: at the very least, we have to fix the docs 21:49:25 adamw: I propose we fix the docs for alpha and get clumens to evaluate this for later in f16. 21:49:26 that's my counter proposal as well 21:49:35 pjones: how generous of you. 21:49:37 pjones: +1 21:49:40 * nirik +1 to pjones suggestion 21:49:54 to clarify: that is, don't change anything in the software for alpha? 21:49:58 +1 to adamw's proposal 21:50:11 +1 adamw proposal 21:50:12 tflink: to leave the docs saying something is supported when it isn't? 21:50:15 +1 to pjones proposal 21:50:22 pjones: my proposal included a docs change. 21:50:26 pjones: adamw's proposal says to update docs 21:50:27 pjones: my proposal is a superset of yours. 21:50:37 oh, indeed. 21:50:46 still, NTH is a bit of an overstep. 21:50:48 at the minimum, we need to modify docs 21:50:55 also, it is useful for the isos to be hybrid 21:50:55 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 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 so I don't see the point in making them non-hybrid 21:51:09 you can still use ask method and use the media IIRC 21:51:14 or do a network install 21:51:14 jlk: yes 21:51:15 or rescue 21:51:17 jlk: my proposal was to make only the DVD iso non-hybrid 21:51:19