17:00:22 <jkurik> #startmeeting F25 Beta Go/No-Go meeting
17:00:22 <zodbot> Meeting started Thu Oct  6 17:00:22 2016 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:22 <zodbot> The meeting name has been set to 'f25_beta_go/no-go_meeting'
17:00:26 <jkurik> #meetingname F25-Beta-Go_No_Go-meeting
17:00:26 <zodbot> The meeting name has been set to 'f25-beta-go_no_go-meeting'
17:00:35 <jkurik> #topic Roll Call
17:00:41 <jkurik> .hello jkurik
17:00:42 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:00:46 <coremodule> .hello coremodule
17:00:47 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:00:48 <nirik> morning
17:00:59 <mboddu> .hello mohanboddu
17:01:00 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:01:05 <nmilosev> .hello nmilosev
17:01:08 <zodbot> nmilosev: nmilosev 'Nemanja Milosevic' <nmilosevnm@gmail.com>
17:01:36 * kparal lurks
17:01:40 <jkurik> Hi everybody
17:01:47 <coremodule> Morning!
17:02:11 <dgilmore> hi
17:02:54 <jkurik> #chair dgilmore adamw nirik mboddu
17:02:54 <zodbot> Current chairs: adamw dgilmore jkurik mboddu nirik
17:02:59 <sgallagh> .hello sgallagh
17:03:00 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:03:08 <jkurik> #chair sgallagh
17:03:08 <zodbot> Current chairs: adamw dgilmore jkurik mboddu nirik sgallagh
17:03:15 <adamw> .hello adamwill
17:03:15 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:03:43 <jkurik> ok, so looks like we have the minimal set of people to start
17:03:46 <jkurik> #topic Purpose of this meeting
17:03:54 <jkurik> #info Purpose of this meeting is to check whether or not F25 Beta is ready for shipment, according to the release criteria.
17:04:06 <jkurik> #info This is determined in a few ways:
17:04:07 <jkurik> #info No remaining blocker bugs
17:04:08 <jkurik> #info Test matrices are fully completed
17:04:10 <jkurik> #info Release candidate compose is available
17:04:17 <jkurik> #topic Current status
17:04:33 <jkurik> #info The F25 Beta RC is available:
17:04:35 <jkurik> #link https://fedorahosted.org/rel-eng/ticket/6484
17:04:36 <jkurik> #link  http://dl.fedoraproject.org/pub/alt/stage/25_Beta-1.1/
17:04:47 <jkurik> #info Test results for F25 Beta are available:
17:05:00 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Summary
17:05:02 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Installation
17:05:03 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Base
17:05:05 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Server
17:05:06 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Cloud
17:05:08 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Desktop
17:05:09 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Security_Lab
17:05:25 <jkurik> We have 5 accepted blockers and 2 proposed blockers. I guess all of the fixes for the 5 blockers are already in the compose. Am I correct ?
17:05:39 <jkurik> adamw, mboddu, dgilmore ^^ ?
17:06:02 * nirik nods. should be yes.
17:06:14 <jkurik> ok, thanks for the confirmation
17:06:17 <adamw> yes.
17:06:24 <Kohane|2> Hi
17:06:33 <Kohane|2> .fas lailah
17:06:33 <zodbot> Kohane|2: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
17:06:47 <jkurik> #info We have 5 accepted blockers and 2 proposed blockers. The fixes for the 5 accepted blockers are already in the compose.
17:07:05 <jkurik> Let's start with Mini-blocker review
17:07:16 <jkurik> adamw: may I ask you please to chair the mini-blocker review ?
17:09:02 <adamw> sure
17:09:54 <sgallagh> I'm a little wary that those are all ON_QA rather than VERIFIED.
17:10:02 <sgallagh> Is that just reporting lagging reality?
17:10:43 <adamw> sgallagh: well, we haven't technically verified each one with Beta-1.1
17:10:48 <adamw> though they've all been verified some other way
17:10:57 <adamw> i'll go through and check them as we go along with the meeting
17:10:58 <adamw> #topic (1381996) TypeError: SynchronizedABCMeta object argument after ** must be a mapping, not NoneType (Intel firmware RAID discovery fails when RAID set is 'migrating')
17:10:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1381996
17:10:59 <adamw> #info Proposed Blocker, anaconda, NEW
17:11:01 <sgallagh> ack
17:11:25 <adamw> so the upshot of this one is that anaconda will choke on mdraid sets that are in a 'migrating' state
17:11:44 <adamw> various things are considered to be 'migrating' states, including the initial resync of a freshly-created set
17:12:04 <adamw> so if you create a brand new RAID>0 set then try and install to it immediately, anaconda will fall over
17:12:10 <dgilmore> -1 blocker based on the weird state the array was in
17:12:12 <adamw> but if you wait for the initial resync to be done it'll work OK
17:12:17 * nirik is -1 blocker for this one. Corner case. Documentable
17:12:21 <adamw> dgilmore: it's not actually a weird state, it's fairly normal
17:12:30 <kparal> why does it sync anything when the raid is completely empty?
17:12:34 <adamw> but i'm OK with -1 for Beta. we should probably fix it for Final though, in fact I'm +1 Final blocker.
17:12:39 <jkurik> I agree to have this in CommonBugs, as already proposed. I am -1 to block on this
17:12:44 <adamw> kparal: i dunno, something about how RAID works. but it's apparently standard.
17:12:50 <dgilmore> adamw: well its weird to install in raid0 then reinstall after changing the raid type
17:13:01 <adamw> dgilmore: that's not actually necessary, that was an early guess
17:13:08 <sgallagh> -1 Beta blocker, +1 final blocker
17:13:09 <dgilmore> at least I think its not a typical use case
17:13:13 <adamw> dgilmore: just 'create brand new RAID-1 set, immediately try to install' is a sufficient reproducer
17:13:14 <Kohane|2> -1
17:13:21 <Kohane|2> I mean...
17:13:36 <Kohane|2> -1 Beta blocker, +1 Final blocker
17:13:41 <nirik> I guess a fix for some of it would be good for final. That case at least
17:14:01 <adamw> nirik: we can fix it, it's not too difficult, just requires teaching libblockdev to understand the mdadm output for migrating sets.
17:14:42 * adamw counts
17:14:45 <mboddu> -1 Beta Blocker
17:14:50 <nirik> adamw: in some of those cases you probibly don't want to install tho? guess it can be handed in bug since you asked that very thing
17:14:55 <kparal> pschindl will be available in 5 minutes, if you need any details from him
17:15:15 <adamw> nirik: yeah, waiting to hear on that. but at least the initial resync i think we should just silently accept, it sounds like.
17:15:23 <nirik> yep
17:15:30 <adamw> kparal: i'm *pretty* sure we understand this one...next one we might need him
17:15:39 <adamw> anyone opposed to Final blocker for this?
17:15:56 <coremodule> +1 final here.
17:15:59 <nirik> I guess not.
17:16:12 <Kohane|2> Apparently.... no...
17:17:33 <kparal> -1 beta, and I'm not sure about final, depends on what anaconda/dmraid people say, but anaconda could at least say "raid initialization in progress, try later"
17:17:36 <adamw> proposed #agreed 1381996 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this affects one fairly common case (immediate install to a freshly-created RAID>0 set), but we believe a commonbugs note is sufficient for Beta. For Final the 'initial sync' case at least should be properly handled
17:17:50 <nirik> ack
17:17:52 <adamw> kparal: i think everyone's pretty much on board with fixing it for Final.
17:17:56 <kparal> ack
17:18:04 <mboddu> ack
17:18:16 <coremodule> ack
17:18:23 <adamw> #agreed 1381996 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this affects one fairly common case (immediate install to a freshly-created RAID>0 set), but we believe a commonbugs note is sufficient for Beta. For Final the 'initial sync' case at least should be properly handled
17:18:28 <jkurik> ack
17:18:34 <adamw> #topic (1382274) gi.overrides.BlockDev.DMError: Failed to group_set
17:18:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1382274
17:18:35 <adamw> #info Proposed Blocker, dmraid, NEW
17:18:57 <adamw> so this is another firmware RAID case, in this case Promise fwraid rather than Intel. it uses dmraid, which is a path we had not tested at all for F25 (I don't think) until today.
17:19:13 <kparal> I actually saw this one, the board is Asus M5A97 Pro I believe, AMD board
17:19:16 <adamw> however, the data in the bug kinda suggests this may be some kind of hardware issue...
17:19:17 * nirik wishes we knew how common these things are anymore.
17:19:23 <kparal> adamw: not nvidia raid
17:19:27 <adamw> kparal: ah, k.
17:19:50 <adamw> just for the record, non-Intel firmware RAID controllers are mostly supported by dmraid not mdraid.
17:20:12 <moto-timo> +1
17:20:14 <adamw> so dlehman says it looks like dmraid doesn't assemble the set on boot at all, which of course means anaconda can't find it to install to
17:20:31 <adamw> we don't know why that is, yet; it may be a dmraid bug or it may be failing hardware or something
17:21:07 <adamw> if pschindl's coming back soon, we can maybe try to figure out why
17:21:25 <sgallagh> We've so far only seen this on a single piece of hardware?
17:21:40 <kparal> sgallagh: yes
17:21:50 * pschindl is here.
17:21:51 <nirik> and it also happens on f24 there FWIW right?
17:21:57 <adamw> sgallagh: yeah. if anyone else has a non-Intel firmware RAID controller and can do an install to it, now would be a great time to try
17:21:58 <kparal> nirik: yes
17:22:15 <adamw> yeah, which is the other suspicious thing; like pschindl, I vaguely recall that he tested F24 on this same hw at release time and it worked
17:22:21 <adamw> but...I wouldn't swear to it in a court of law :)
17:22:29 <Kohane|2> LOL
17:22:43 <sgallagh> If it's also an issue on F24, I'm inclined to vote -1
17:22:59 <adamw> kparal: will pschindl have the affected box handy when he comes back?
17:23:08 <sgallagh> Simply because if it was affecting a significant portion of users, we'd have had a report before now
17:23:10 <kparal> adamw: see above, he's here now
17:23:16 <kparal> and no, we're not in the office
17:23:18 <pschindl> Hi all.
17:23:24 <adamw> ah, okay.
17:23:29 <adamw> so can't do much to diagnose it at this point
17:23:30 <pschindl> I will be back in the office on Monday
17:23:43 <adamw> okay, so we're gonna have to basically guess at this one.
17:23:48 <adamw> unless anyone else has the hardware to test.
17:23:51 <pschindl> but if someone will be in office tomorrow he can test it
17:23:59 <Kohane|2> I haven't, sorry.
17:24:04 <pschindl> it's just about booting to anaconda.
17:24:18 <jkurik> if the dmraid was tested on F24 and it worked on other hardware, and the F24 fails on this HW, then I am -1 to block on this
17:24:44 <Kohane|2> Agree. I'm -1 Beta blocker.
17:24:48 <mboddu> if it is just one hardware and also an issue in F24, I am inclined towards -1
17:24:59 <sgallagh> pschindl: It was asserted that you also tried running F24 on this same hardware and it failed there, is that true?
17:25:05 <sgallagh> /me just wants the confirmation
17:25:11 <kparal> sgallagh: yes
17:25:26 <nirik> sgallagh: yes, it's noted in the bug
17:25:35 <sgallagh> Sorry, missed that in the BZ
17:25:40 <sgallagh> OK, then I'm -1 blocker
17:25:50 <sgallagh> (for the reasons I cited earlier)
17:26:02 <pschindl> Yes, I tried to boot F24 installer and it failed today on the same computer.
17:26:14 <adamw> i can go with -1 on the grounds that we at least *suspect* this is something up with the hardware, and we tested this kinda too late anyway. if it turns out that all non-intel fwraid is really broken we should take that as a final blocker of course.
17:26:31 <jkurik> sure
17:26:41 <adamw> i'm just gonna dig around my archives for a minute to see if i actually can confirm whether pschindl tested this same box for f24 release
17:26:54 <kparal> I seem to vaguely remember that
17:27:04 <kparal> maybe it's again somehow related to raid initialization?
17:27:09 <pschindl> I'm -1 right now too. If we find what's the problem with that machine I'll repropose it (for final).
17:27:15 * nirik is -1 also
17:28:34 <pschindl> adamw: We have two machines with firmware raid. This one is next to Kamil, so I don't test on it so often. I have another next to me. But I think that I tested it on both.
17:29:33 <adamw> kparal: well, if it is it'd just be a coincidence, as the codepaths are totally different (obviously we're not parsing mdadm output for dmraid sets)
17:29:44 <pschindl> Strange thing about this problem is that there isn't any md* device even though the fw says that raid was created.
17:30:06 <adamw> welp, that's enough -1s, anyhow
17:30:29 <adamw> pschindl: well, that's basically what dlehman said too, it looks like dmraid never actually constructs the array, so of course anaconda can't find it
17:30:59 <nirik> further debugging of this probibly needs dmraid commands run on the affected machine to figure out what it thinks is going on
17:31:56 <adamw> proposed #agreed 1382274 - RejectedBlocker (Beta) - this was reported very late and without sufficient information to be sure if it's a real bug or some kind of hardware/setup issue. It's rejected for Beta, but we will investigate further and may accept it for Final if it turns out to be a genuine and serious bug.
17:32:12 <jkurik> ack
17:32:14 <coremodule> ack
17:32:19 <kparal> ack
17:32:24 <adamw> pschindl: for the future - Intel firmware RAID and Promise firmware RAID hit *very* different codepaths, so it's always good to test both, and test them early enough that we can fix bugs
17:32:25 <sgallagh> ack
17:32:30 <mboddu> ack
17:32:34 <adamw> pschindl: one passing doesn't give a very strong indication at all that the other will also pass
17:32:56 <pschindl> ack
17:32:57 <adamw> pschindl: i can test intel fwraid too (as you know) but i don't have any non-intel fwraid hardware, you're our only hope for that :)
17:33:05 <adamw> #agreed 1382274 - RejectedBlocker (Beta) - this was reported very late and without sufficient information to be sure if it's a real bug or some kind of hardware/setup issue. It's rejected for Beta, but we will investigate further and may accept it for Final if it turns out to be a genuine and serious bug.
17:35:01 <adamw> that's all the proposed blockers, i believe
17:35:09 <adamw> does anyone have any last-minute proposals? speak now or forever hold your peace
17:35:42 <jkurik> ... looks like we can move on :)
17:36:24 <Kohane|2> No, I have nothing to propose.
17:36:35 <Kohane|2> Yes, we can move on
17:39:29 * nirik is good to move on. jkurik ?
17:40:22 <jkurik> ah, sorry
17:40:42 <jkurik> #topic Test Matrices coverage
17:40:59 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_Beta_1.1_Summary
17:41:09 <adamw> coverage is pretty strong
17:41:37 <adamw> the only significant omissions are a few of the real media default_boot_and_install tests, and cloud on ec2 or openstack (cloud tests have only been run locally)
17:42:21 <adamw> for those who don't know - coconut's results in the 'Default boot and install' table are kind of a lie, as those tests are really supposed to be run with real shiny optical discs on a bare metal system, while openQA tests in vms
17:42:34 <adamw> i'm gonna propose some changes to the wiki layout there after Beta
17:42:44 <nirik> I could do a openstack test real quick if people wanted to wait...
17:42:51 <adamw> so only the human results in that table can be considered fully valid
17:42:51 <nirik> but if it worked locally it's probibly ok
17:42:53 <adamw> nirik: sure
17:42:59 <jkurik> adamw: ok, thanks.
17:42:59 <adamw> if you can at least just boot it up and make sure
17:43:21 <adamw> i think for beta we don't need to be super strict about testing literally every single image in every single way, though. we have covered each major image type.
17:43:32 <adamw> for final i'd like to see a full set of human results in that table.
17:43:51 <jkurik> so lets wait for nirik to run the test
17:44:05 <jkurik> otherwise I am fine with the coverage
17:44:23 <jkurik> QE team: good job
17:44:24 <kparal> adamw: to be clear, we've never done that
17:44:29 <sgallagh> adamw: Maybe as a stopgap you should make coconut not report successes there, only failures?
17:45:04 <sgallagh> I know I mostly just scan pages for empty spots; not sure who else does that, but coconut's results make it look skippable
17:45:06 <adamw> kparal: whenever i put a human result in that table it's always with a real disc on bare metal
17:45:14 <kparal> sgallagh: we don't report failures with openqa at all into wiki, too many false negatives
17:45:25 <adamw> sgallagh: nah, what i'd like to do is have a table with a lot more columns, covering virt, optical media, and usb (and kill the separate usb table)
17:45:30 <adamw> that's gonna be my proposal anyway
17:45:31 <kparal> adamw: ok, I mostly use usb for that table
17:45:31 <sgallagh> ok
17:45:37 <adamw> kparal: zoiks, ok, that's bad :P
17:45:43 <adamw> clearly we need a better table
17:46:28 <adamw> kparal: i'm actually thinking about setting up reporting of failures from openqa, but that's a side track...
17:48:15 * adamw wonders if it's still possible to buy CD-Rs
17:48:37 <mboddu> adamw: you might need to add ostree testing results to wiki as well
17:48:53 <nirik> ok, came up fine.
17:48:56 <nirik> $ uname -a
17:48:56 <nirik> Linux kevintest1.novalocal 4.8.0-0.rc7.git0.1.fc25.x86_64 #1 SMP Mon Sep 19 15:24:06 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
17:48:56 <adamw> mboddu: yes, it's planned.
17:49:00 <adamw> nirik: yaay
17:49:14 <jkurik> nirik: thanks
17:49:15 <adamw> nirik: did resize work? (if that applies to openstack, /me doesn't know the clouds)
17:49:24 <moto-timo> adamw: amazon says yes :)
17:49:36 <nirik> yes
17:49:40 <nirik> [   25.944074] EXT4-fs (vda1): resizing filesystem from 786176 to 10485504 blocks
17:49:40 <nirik> [   32.236772] EXT4-fs (vda1): resized filesystem to 10485504
17:49:48 <adamw> awesome
17:49:52 <nirik> and it's got the full 40G for /
17:49:57 <adamw> so, i'm gonna say we're good for coverage, anyone disagree?
17:50:00 <nirik> /dev/vda1        40G  529M   38G   2% /
17:50:12 <nb> adamw, yes, it is possible to buy CD-R
17:50:17 <jkurik> proposed #info Test Matrices coverage for the Beta release is pretty strong and sufficient
17:50:34 <nb> people still use them for burning music cds sometimes
17:50:54 <jkurik> nb: yeah, I still do so :)
17:51:16 <adamw> oh good, cos i'm about to run out
17:51:21 <adamw> ack
17:51:22 * moto-timo is surprised that my new car still has cd player
17:51:25 * nirik isnt sure he has a cdrom drive anymore. ;)
17:51:34 <jkurik> #info Test Matrices coverage for the Beta release is pretty strong and sufficient
17:51:36 <jkurik> #topic Go/No-Go decision
17:52:06 <jkurik> so we need QE, RelEng and FESCo representatives to vote whether we are Go or No-Go
17:52:15 <jkurik> I am personaly Go
17:52:26 <adamw> per qa policy, we vote go - coverage is sufficient and there are no unaddressed blockers
17:52:35 <nirik> go for me (fesco, releng, whatever I am)
17:52:44 * adamw just trying to verify the remaining accepted blockers
17:52:53 <dgilmore> adamw: I have 100 cd-r you can have :D
17:53:02 <dgilmore> releng is go
17:53:37 <kparal> adamw: all of them should be verified already
17:53:43 <sgallagh> /me lost connection; we're voting on go/no-go?
17:53:52 <jkurik> sgallagh: yes, we do
17:53:58 <sgallagh> Go!
17:54:06 <adamw> kparal: they haven't all been verified *with Beta-1.1* though
17:54:15 <adamw> kparal: they've been verified with updates or nightlies or whatever
17:54:20 <kparal> hm
17:54:24 <adamw> i just like to double check they're OK in the release
17:54:28 <adamw> i think they're all fine though.
17:54:30 <kparal> ok, thanks
17:54:44 <jkurik> adamw: shall we wait ?
17:55:00 <adamw> eh, nah
17:55:04 <adamw> i'm sure it'll be fine
17:55:08 <adamw> if it's not i'll just pretend it is
17:55:14 <jkurik> :)
17:55:15 <jkurik> ok
17:55:27 <jkurik> #agreed The status of the F25 Beta 1.1 compose is GO
17:55:37 <jkurik> #action jkurik to publish the Go/No-Go result
17:55:47 <jkurik> #topic Open floor
17:55:57 <jkurik> anything else to discuss today on this meeting ?
17:56:23 <adamw> are we gonna be trying to make FMW the 'default download' for Workstation for Beta?
17:56:25 <adamw> or is that final stuff
17:57:09 <mboddu> default download?
17:57:25 <sgallagh> mboddu: The thing listed on getfedora.org
17:57:30 <adamw> aiui the idea is that for F25 when you go to getfedora and click 'Download' you'll get FMW, not a .iso image
17:57:33 <sgallagh> Rather than sending people directly to the ISO
17:58:09 <mboddu> sgallagh: I know about FMW but I dont know we are having plans to make it default
17:58:33 * nirik doesn't know the timeline for that
17:58:34 <kparal> one further question is whether we should keep workstation dvd in the tree, when we know it's untested and also something else than people would expect (ostree image)
17:58:39 <sgallagh> mboddu: We have been for about 18 months
17:58:40 <jkurik> AFAIK the websites for Beta were reworked to support FMW
17:59:01 <sgallagh> kparal: Is it working at all yet? It wasn't yesterday.
17:59:04 <mboddu> sgallagh: I always used dl.fp.org
17:59:23 <kparal> sgallagh: I didn't try it, I just read you and dgilmore reporting it's broken
17:59:25 <sgallagh> I've been told by walters that the nightlies work but they aren't paying attention to Fedora...
17:59:49 <jkurik> from the conversation I had yesterday with sticker: <stickster> jkurik: Also, just in case robyduck isn't able to attend... I can't speak for him as lead, but I can say that one of the websites items, to get mediawriter web content available for Beta, is in good shape thanks to his excellent work
18:00:18 <nirik> huh. ok.
18:00:25 <jkurik> so I believe the FMW is the "default download" already for Beta
18:01:01 <nirik> https://stg.getfedora.org/en/workstation/prerelease/
18:01:11 <nirik> well, as always depends on what you mean by 'default' ;)
18:01:58 <jkurik> nirik: the download button points to the Alpha image
18:02:21 <dgilmore> kparal: we know the beta version does not work
18:02:30 <dgilmore> kparal: and we do not have a good way to remove it
18:02:33 <nirik> well, yes, how could it point to beta when we haven't released it yet. ;) but sure we need to make sure thats right before release day
18:02:42 <dgilmore> we would have to munge a lot of metadata and data in pdc
18:02:57 <nirik> dgilmore: how about just chmod 000 it
18:03:05 <jkurik> I will check with robyduck during the readiness meeting later today
18:03:09 <dgilmore> nirik: sure
18:03:22 <adamw> dgilmore: don't you strip the metadata from the release tree already?
18:03:34 <adamw> dgilmore: since it gets split and some of the images listed in it aren't there in the final location
18:03:50 <adamw> but PDC, yeahg.
18:04:12 <adamw> still, the metadata in PDC is already kind of a lie, for releases that get split into the 'main' chunk and the 'alt' chunk and sent to the mirrors.
18:04:36 <dgilmore> adamw: it is in pdc
18:05:39 <jkurik> ok, anything else ?
18:05:41 <adamw> for the record, future ostree installer images will have -ostree- in their filename rather than -dvd- (after https://pagure.io/pungi/pull-request/420 is landed and starts being used for Fedora composes)
18:07:00 <adamw> that includes the 'Atomic host' installer image as well as the Workstation one
18:07:20 <mboddu> adamw: nice :)
18:08:06 <dgilmore> adamw: it is merged, just needs built and deployed
18:08:42 <adamw> well, it wasn't until like 30 seconds ago :P
18:09:09 <jkurik> thanks folks for the meeting and see most of you on the readiness meeting in less then one hour
18:09:31 * moto-timo waves
18:09:47 <jkurik> #endmeeting