17:00:13 <jkurik> #startmeeting F26 Alpha Go/No-Go meeting the 2nd round
17:00:13 <zodbot> Meeting started Thu Mar 23 17:00:13 2017 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:13 <zodbot> The meeting name has been set to 'f26_alpha_go/no-go_meeting_the_2nd_round'
17:00:20 <jkurik> #meetingname F26-Alpha-Go-No-Go-meeting-2nd
17:00:20 <zodbot> The meeting name has been set to 'f26-alpha-go-no-go-meeting-2nd'
17:00:23 <jkurik> #topic Roll Call
17:00:28 <jkurik> .hello jkurik
17:00:28 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:00:31 <nirik> welcome no-goers. ;)
17:00:36 <jkurik> #chair dgilmore nirik adamw sgallagh roshi mboddu
17:00:36 <zodbot> Current chairs: adamw dgilmore jkurik mboddu nirik roshi sgallagh
17:00:53 <jkurik> nirik: hi
17:01:03 <roshi> .hello roshi
17:01:04 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:01:19 <adamw> .hello adamwill
17:01:20 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:01:26 <sgallagh> .hello sgallagh
17:01:27 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:32 <jkurik> hi adamw, roshi, sgallagh
17:02:10 <jkurik> we need someone from releng
17:02:12 <jkurik> dgilmore, mboddu are you available for the meeting ?
17:02:20 <dgilmore> jkurik: I am around
17:02:25 <jkurik> great
17:02:33 <jkurik> #topic Purpose of this meeting
17:02:37 <jkurik> #info Purpose of this meeting is to check whether or not F26 Alpha is ready for shipment, according to the release criteria.
17:02:41 <jkurik> #info This is determined in a few ways:
17:02:44 <jkurik> #info No remaining blocker bugs
17:02:48 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/26/alpha/buglist
17:02:53 <jkurik> #info Release candidate compose is available
17:02:57 <jkurik> #link https://pagure.io/releng/issue/6701
17:03:01 <jkurik> #info Test matrices for Alpha are fully completed
17:03:04 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_26_Alpha_1.2_Summary
17:03:08 <jkurik> #topic Current status
17:03:13 <jkurik> #info F26 Alpha RC Compose 1.2 is available
17:03:17 <jkurik> #link https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170321.1/compose/
17:03:22 <jkurik> #info We have 4 proposed and 2 accepted blockers for F26 Alpha.
17:03:32 <jkurik> Let's start with Mini-blocker review
17:03:41 <jkurik> roshi, adamw: may I ask you please to chair the mini-blocker review ?
17:03:44 <adamw> sure.
17:03:46 <adamw> did i get a chair?
17:03:53 <jkurik> yes
17:03:56 <jkurik> #topic Mini-Blocker Review
17:03:59 <roshi> you got it adamw ?
17:04:04 <adamw> sure
17:04:12 <adamw> #info 4 Proposed Blockers
17:04:12 <adamw> #info 2 Accepted Blockers
17:04:16 <adamw> #info 3 Proposed Freeze Exceptions
17:04:16 <adamw> #info 8 Accepted Freeze Exceptions
17:04:17 * roshi relaxes then
17:04:22 <adamw> that's what we have for Alpha. i guess we can ignore the FEs.
17:04:32 <jkurik> ack
17:04:42 <adamw> #info for the record, both the accepted blockers are verified fixed in RC2, which means we only have to worry about the proposed
17:05:02 <adamw> #topic (1434977) Fedora 26 backgrounds are the same as Fedora 25
17:05:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1434977
17:05:03 <adamw> #info Proposed Blocker, distribution, NEW
17:05:08 <adamw> so, this one makes me quite sad...
17:05:14 <roshi> yeah
17:05:18 <adamw> in fact
17:05:21 <adamw> i'm gonna propose we take this one later
17:05:34 * roshi is going to write a script that generates backgrounds with a fedora logo and we can just use that :p
17:05:41 <adamw> as i suspect discussion of it will go differently depending on whether we accept the other proposals
17:05:51 <adamw> sound OK?
17:05:55 <dgilmore> sure
17:05:57 <roshi> +1 from me
17:05:58 <sgallagh> ack
17:06:02 <adamw> #info we'll circle back to this one later
17:06:14 <adamw> #topic (1433899) Workstation Live panics during boot
17:06:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1433899
17:06:14 <adamw> #info Proposed Blocker, kernel, NEW
17:06:30 <adamw> just a quick note - this one and the next one (#1434462) are likely the same bug
17:06:46 <adamw> lemme see if labbott is around
17:08:19 <adamw> so this is my best summary of my current understanding here: many different people have reported that booting the current F26 kernel (4.11 rc2.git2) in a qemu VM often crashes or hangs early in boot, with a GPF (general protection fault) error and a kernel stack trace. we've seen many different stack traces, but still strongly suspect these are all ultimately the same bug
17:08:26 <adamw> AFAIK, no-one has yet seen this happen on bare metal
17:08:51 <adamw> does that sound about right to everyone?
17:09:01 * jkurik has the same understanding
17:09:02 <sgallagh> almost
17:09:10 <dgilmore> what it looks like from whats in the bug
17:09:11 <sgallagh> I have seen the early boot hang once on bare metal
17:09:18 <sgallagh> I suspect that's a different issue
17:09:27 <sgallagh> And the hang resolves itself in three minutes, so I wouldn't block on it
17:09:39 <adamw> sgallagh: yeah, if it eventually manages to boot, i think that's not the same thing
17:09:58 * roshi hasn't seen it in his bare metal installs
17:10:17 * nirik hasn't seen it here on bare metal... or cloud come to think of it.
17:10:24 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1434462 is very likely the same bug
17:10:32 <roshi> cloud works fine
17:10:37 <adamw> https://bugzilla.kernel.org/show_bug.cgi?id=194911 may well be the same bug
17:11:10 <adamw> i think it depends on the VM configuration to some extent also; iirc, labbott couldn't hit it with a simple qemu command (using mostly qemu defaults)
17:11:27 <adamw> i think there has to be at least some use of virtio in the VM config
17:11:30 <adamw> but that's the default for libvirt
17:12:30 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1430297 is also likely the same bug
17:13:25 <adamw> so, this is obviously pretty bad
17:13:42 <nirik> yeah.
17:13:52 <adamw> one key thing here is that we explicitly make VM functionality part of the *beta* criteria
17:13:52 <sgallagh> I think this is probably show-stopper bad
17:13:54 <roshi> pertty much
17:14:14 <adamw> and the intent at the time of writing those criteria, and the way we've interpreted them in the past, was that vm-only bugs cannot block alpha
17:14:15 <sgallagh> Because realistically, who besides Fedora QA would install an alpha on physical hardware these days?
17:14:25 <adamw> i do think it's reasonable to revisit that these days, though, as use of virt is much more common than it was
17:14:51 * roshi is torn
17:14:51 * nirik was going to ask the criteria here.
17:15:38 <nirik> do we have a fix? there was a test kernel?
17:15:48 <sgallagh> I'm of the opinion that even if the criteria say "beta", we should probably slip to fix this anyway. The Alpha will be mostly useless if it doesn't work consistently on a VM
17:15:52 <jforbes> Yeah, looks like the test kernel fixed things, but it was a scratch
17:16:07 <adamw> jforbes: where's the 'test kernel' discussed? i don't think i have that link
17:16:16 * roshi hasn't seen it eithre
17:16:33 <jkurik> sgallagh: makes sense for me
17:16:41 <nirik> was discussed in #fedora-kernel:
17:16:44 <adamw> i knew rwmjones and thorsten both bisected to the same commit, and labbott was trying to get some kind of revert of that commit (it doesn't revert simply, apparently)
17:16:49 <adamw> ah, i see it now.
17:17:01 <nirik> [17:23:37]  <labbott> okay I have a scratch build with roughly the entire virtio tree that was merged reverted
17:17:01 <nirik> [17:23:40]  <labbott> 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507
17:17:01 <nirik> [17:23:45]  <labbott> https://koji.fedoraproject.org/koji/taskinfo?taskID=18529971
17:17:14 <jforbes> right
17:17:28 * dgilmore holds jforbes responsible :D
17:17:40 <adamw> as the designated criteria wrangler, i can say it'd be pretty easy to change the criteria so we can block alpha on virt showstoppers, if that's what we want to do
17:17:47 <dgilmore> jforbes: whats the confidence in the revert fixing things?
17:17:58 <adamw> so this meeting can certainly choose to agree that in principle, and i can draft the implementation later, as we've done before.
17:18:21 <adamw> dgilmore: rwmjones had a very good reproducer for the bug and he tested the scratch build and said it was good, so i'd say that's a good sign
17:18:21 <jforbes> dgilmore: no clue, I only know what was posted in #fedora-kernel
17:18:28 <sgallagh> adamw: That draft is likely useless, since this is our last-ever Alpha
17:18:30 <dgilmore> adamw: I would think a large number of alpha users do so in virt
17:18:31 <adamw> <rwmjones> 02:45:10> labbott: https://bugzilla.redhat.com/show_bug.cgi?id=1430297#c7 .. yes it's better
17:18:33 <nirik> didn't we have a rule for not changing the critera on the fly like that? ;)
17:18:54 <adamw> sgallagh: not really, since the idea of 'no more alphas' is that we're *always* at alpha quality
17:19:09 <adamw> nirik: no, we had viking_ice who was extremely against it. fortunately, he's bugging suse people instead now. :P
17:19:12 <sgallagh> nirik: The rule was to not remove criteria on the fly. I think "deciding that something really SHOULD be a show-stopper" is fair game
17:19:24 <adamw> we have done this same kind of thing a few times before, there's precedent.
17:19:44 <nirik> alright.
17:20:13 <adamw> sgallagh: to continue my thought - so even if we're not actually releasing Alphas, part of the no-more-Alphas thing will likely involve just taking the existing Alpha criteria and renaming the page or something - fundamentally, we'll still want those criteria in some way.
17:20:28 <nirik> Anyhow, I think that many people would use an alpha in a vm, so this is important to fix. Since we won't hopefully have an alpha next cycle we could make it a rawhide test/gate.
17:20:51 <dgilmore> nirik: exactly
17:20:59 <sgallagh> Yes, agreed
17:21:04 <nirik> basically we would be saying: alpha critera should always be met/blocked if they break, etc.
17:21:05 <adamw> well, it kinda should be already
17:21:17 <adamw> the openqa tests should run into it
17:21:25 <sgallagh> BTW, I am curious: when did this kernel virtio change land? Before or after Freeze?
17:21:29 <dgilmore> adamw: have they?
17:21:35 <jforbes> Well, remember, this is only certain VMs. It has been booting in our test VMs just fine
17:21:52 <adamw> dgilmore: i tweaked the openqa tests when we found https://bugzilla.redhat.com/show_bug.cgi?id=1430043
17:22:05 <sgallagh> jforbes: Then you probably need to add some virtio configs to your test suite :)
17:22:08 <adamw> i changed them to use IDE optical drives instead of virtio
17:22:20 <adamw> i think that tweak must also be  helping them to avoid this bug, as they almost never seem to run into it
17:22:22 <jforbes> sgallagh: We don't use optical at all
17:22:40 <adamw> jforbes: i don't think optical is necessarily involved, i don't think rwmjones' reproducer attaches an optical drive
17:22:44 <jforbes> sgallagh: though we do use virtio HDs, booting ISOs doesn't make sense when we only want to test kernels
17:22:59 <adamw> i don't think we quite nailed down precisely what hardware config is necessary to run into this one
17:23:05 <adamw> only that default virt-manager and boxes VMs have whatever it is
17:23:11 <nirik> if we want them to always work in libvirt, we could have a openqa worker boot and run libvirt and make a vm and confirm it works. ;)
17:23:33 <adamw> nirik: yeah, we should actually probably have something like that. anyhoo
17:23:40 <nirik> right, sorry, weeds.
17:23:42 <jforbes> -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
17:23:53 <sgallagh> So, on the topic at hand: does anyone *disagree* that this should be a blocker?
17:24:07 <adamw> ...and thus that we should move some or all of the virt requirements from beta to alpha?
17:24:11 <adamw> i'm fine with that.
17:24:32 <nirik> what are all of them?
17:24:33 * nirik looks
17:24:44 <jkurik> finaly I am +1 to block
17:24:49 <adamw> i'm just being vague to cover my ass
17:24:50 <linuxmodder> dord it naturally recover ?  not had a chance to screw with work 26
17:24:58 <adamw> linuxmodder: no, if you hit this, boot fails
17:25:01 <adamw> you just have to try again
17:25:20 <linuxmodder> then +1 block from me
17:25:25 <nirik> ok, it's only 2 things...
17:25:26 <adamw> as to the 'did this show up before or after freeze?' question - i haven't established that yet
17:25:37 <adamw> the *other* bug complicates that a bit
17:25:40 <nirik> The release must be able host virtual guest instances of the same release.  and The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release. The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release.
17:25:45 <jforbes> So here's the thing though, the "fix" is reverting almost the entire virtio merge from 4.11, which means we don't actually know the cause
17:25:55 <nirik> jforbes: there's a smaller fix upstream now.
17:25:59 <adamw> there is?
17:26:01 <sgallagh> I'd say we don't need the first one (hosting a VM)
17:26:03 <nirik> but needs a build/tested
17:26:06 <adamw> nirik: where?
17:26:10 <sgallagh> For Alpha, I mean
17:26:24 <adamw> sgallagh: the criterion is quite...efficient, it's intended to be read as covering both host and guest functionality
17:26:30 <jforbes> nirik: much better. I haven't looked this morning
17:26:40 <nirik> https://lkml.org/lkml/2017/3/23/38
17:26:42 <adamw> but i guess we could split it up
17:26:51 <sgallagh> Right, but I'm saying that guest functionality makes sense at Alpha, but host I could be fine with leaving at Beta
17:26:53 <roshi> I'm reluctantly +1 after following the discussion
17:26:58 <adamw> sgallagh: fair enough, we can do that.
17:27:23 <nirik> and rwmjones and thl said it fixed things for them
17:27:37 <adamw> oh, they tested it already? awesome
17:27:54 <adamw> you mean some people were working this morning while i was fiddling around with flashing bootloaders on my tablet? jeez
17:28:11 <adamw> jforbes: so could we get a kernel build with that patch, then?
17:28:15 <nirik> slacker. ;)
17:28:37 <jforbes> Okay, so we ship alpha with the virtio merge revert that Laura did yesterday, and then get some testing on the other fix so that we aren't carrying the full revert for long
17:28:44 <nirik> sgallagh: I'm ok with that too... host seems a bit much all the time...
17:28:50 <adamw> jforbes: well, we're gonna wind up slipping a week most likely
17:28:51 <jforbes> adamw: sure, do you also want the crda fix in there?
17:28:58 <roshi> +1 to guest moving to Alpha and Host staying at Beta
17:29:02 <adamw> jforbes: i'd actually be inclined just to take the 'better' fix rather than the revert, given that
17:29:03 <adamw> wdyt?
17:29:15 <adamw> jforbes: crda fix?
17:29:51 <jforbes> adamw: 4.10 update on f25 breaks wifi for anyone who needs to set regulatory country. We have the fix, verified, f26 will also need it
17:30:17 <adamw> proposed #agreed The group agrees in principle to move at least default virt guest requirements from Beta to Alpha criteria, and accepts this bug as a blocker as it often prevents the Alpha booting on default virt-manager / Boxes VMs
17:30:27 <nirik> ack
17:30:28 <roshi> ack
17:30:29 <jforbes> it is a simple math error, ++n was changed to n++
17:30:41 <linuxmodder> ack
17:30:44 <jkurik> ack
17:30:46 <sgallagh> ack
17:30:50 <adamw> jforbes: d'oh. um. sure, yeah, submarine that in there. technically we should nominate and accept the bug as an FE...
17:31:00 <adamw> #agreed The group agrees in principle to move at least default virt guest requirements from Beta to Alpha criteria, and accepts this bug as a blocker as it often prevents the Alpha booting on default virt-manager / Boxes VMs
17:31:19 <adamw> #topic (1434462) frequent kernel panic during VM boot
17:31:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1434462
17:31:19 <adamw> #info Proposed Blocker, kernel, NEW
17:31:21 <jforbes> adamw: is working wifi an alpha requirement?
17:31:31 <adamw> so i'm gonna propose we assume for now that this is the same as the previous bug
17:31:41 <sgallagh> adamw: +11
17:31:43 <sgallagh> err, +
17:31:45 <sgallagh> gah!
17:31:49 <sgallagh> you get the idea
17:31:52 <roshi> don't think so, at least not in the sense that setting regulatory country is
17:31:58 <adamw> jforbes: well, working networking is by implication. i suspect that wouldn't get through as a blocker on the basis that needing to set regulatory requirements isn't that common, but it'd almost certainly make it as an FE
17:32:16 * roshi would +1 FE for that
17:32:29 <jforbes> roshi: adamw it is quite common actually for people outside of NA
17:32:32 <adamw> #info we're going to assume for now that this is the same as the previous bug (#1433899)
17:32:40 <adamw> #info we'll do bugzilla bureaucracy later
17:32:55 <linuxmodder> +1 FE on the wifi part
17:33:08 <adamw> jforbes: what is the CRDA bug #?
17:33:09 <adamw> #topic (1435010) GNOME fails to start without modesetting (Fedora 'basic graphics') mode
17:33:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1435010
17:33:09 <adamw> #info Proposed Blocker, mutter, NEW
17:33:19 <roshi> sigh
17:33:32 * roshi didn't think something like this would slip through
17:33:32 <jforbes> adamw: https://bugzilla.redhat.com/show_bug.cgi?id=1422247
17:34:01 <nirik> here again our robot overlords failed us. ;) But of course finding the time to add tests for all these things is not easy either.
17:34:04 <sgallagh> I saw this yesterday on one of my systems
17:34:27 <sgallagh> I'm not really sure how common this is though.
17:34:49 <sgallagh> Though if it's one of the selectable boot options, I suppose we should make it work.
17:34:56 <adamw> this is a big nostra culpa for qa, sorry
17:35:02 <sgallagh> Though I'd also accept "remove that boot option" as a valid way to unblock this.
17:35:03 <jkurik> I am frequent vesa user, so for me this is blocking
17:35:18 <adamw> nirik: we've never put it in openQA because the test specifies it must be done on bare metal
17:35:27 <adamw> but we really should have an openQA test for it *anyway*, just not mark it as a wiki pass
17:35:30 <nirik> ha, fair enough I guess.
17:35:33 <adamw> at least then we'd catch cases where it *does* fail in virt
17:35:47 <adamw> so a) we really should have a robot test this and b) we should've had a human test it much earlier
17:36:01 <nirik> it happens 100% of the time on my macbook.
17:36:08 <adamw> i spend so much time herding the robots these days I never got around to the manual tests :/
17:36:20 <adamw> yeah, it seemed pretty reproducible to me too, i tried it several times
17:36:34 <sgallagh> I hit it both times I tried it
17:36:36 <adamw> sgallagh: the criteria actually state that the boot option must be there
17:36:50 <sgallagh> of course it does :-|
17:36:58 <nirik> jkurik: out of curiosity what video hw do you have that you need it now?
17:37:11 * nirik suspects its less needed than it was long ago
17:37:22 <adamw> we could *possibly* revisit it on the basis that graphics support is rather better than it used to be and maybe 'basic mode' isn't as important any more, but i'd want someone to gather some solid data to support that idea
17:37:26 <sgallagh> nirik: In my case it was an nVidia GeForce 1070, which is waiting for kernel 4.12 to have nouveau suppotr
17:37:29 <adamw> not just a 'vague feeling'
17:37:32 <jkurik> nirik: I am not sure atm, that is a set of old HW I have at home
17:37:44 <nirik> alright.
17:37:59 <sgallagh> So it isn't just about old hardware. Sometimes it's "too new" hardware
17:38:12 <nirik> anyhow, I am +1 blocker for it
17:38:23 <sgallagh> Yes, +1 blocker
17:38:32 <jkurik> +1 to block
17:38:44 <linuxmodder> +1
17:39:12 <nirik> hopefully it won't be too bad to fix...
17:39:17 <roshi> +1
17:39:18 <adamw> i hope not
17:39:46 <adamw> proposed #agreed 1435010 - AcceptedBlocker - this is a clear violation of Alpha requirement "The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver."
17:39:54 <adamw> jforbes: ok, i'll do a quick FE review for that next
17:40:04 <roshi> ack
17:40:07 <jkurik> ack
17:40:14 <sgallagh> ack
17:40:29 <nirik> ack
17:40:36 <adamw> #agreed 1435010 - AcceptedBlocker - this is a clear violation of Alpha requirement "The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver."
17:40:44 <adamw> so that's all the proposed blockers
17:40:53 <adamw> but we're gonna do a quick review of the wifi bug jforbes wanted FE status for
17:41:00 <adamw> #info we're doing one quick FE review
17:41:36 <adamw> #topic (1422247) Can't set crda with 4.10 kernel
17:41:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1422247
17:41:55 <adamw> #info Proposed Freeze Exception, kernel, MODIFIED
17:42:31 <jforbes> So, we know the fix, one liner, very simple and low risk
17:42:36 <roshi> +1
17:42:45 <nirik> +1 FE
17:42:51 <adamw> +1 FE, obviously it's bad for people not to be able to get online from the lives and netinsts
17:43:09 <adamw> any objections?
17:43:16 <sgallagh> +1 FE
17:43:16 <adamw> speak now or forever hold your mouse
17:43:21 <jkurik> +1 FE
17:43:30 <sgallagh> *SQUEEK*
17:43:45 <linuxmodder> +1 FE
17:44:19 <adamw> proposed #agreed 1422247 - AcceptedFreezeException (Alpha) - the fix for this is safe and tested, and obviously it's bad for some folks not to be able to get on the network from netinst / live images
17:44:31 <nirik> ack
17:44:34 <jkurik> ack
17:44:34 <jforbes> Cool, will get a kernel going with those 2 patches in
17:44:36 <linuxmodder> ack
17:44:36 <roshi> ack
17:45:16 <linuxmodder> jforbes, lmk when its built I'll tst and karma today for you
17:45:47 <jforbes> linuxmodder: will do, probably be 7 hours or so
17:46:22 <linuxmodder> no prob I have kernel alerts in bodhi but not yours in particular just the kernel itself :P
17:46:46 <linuxmodder> I'm utc -4 so no biggie and I keep long hours
17:47:29 <adamw> #agreed 1422247 - AcceptedFreezeException (Alpha) - the fix for this is safe and tested, and obviously it's bad for some folks not to be able to get on the network from netinst / live images
17:47:54 <adamw> i'll just see if any other proposed FE looks super urgent
17:48:15 <nirik> we still need to rant about backgrounds too right?
17:48:26 <roshi> yup
17:48:34 <adamw> oh, yes.
17:48:37 <adamw> thanks for the reminder
17:48:57 <adamw> #topic (1434977) Fedora 26 backgrounds are the same as Fedora 25
17:48:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1434977
17:48:57 <adamw> #info Proposed Blocker, distribution, NEW
17:49:07 <roshi> but seriously, I can have a script generate a background so this doesn't happen
17:49:22 <roshi> then the autogenerated one can be replaced when the real ones are ready
17:49:39 <linuxmodder> any eta on the real ones roshi
17:49:50 <sgallagh> I think we may want to rethink this criterion in the new no-Alpha world as well
17:49:57 <linuxmodder> or is that a design team thing still
17:50:01 <roshi> mizmo: any update?
17:50:04 <adamw> roshi: the problem isn't getting the actual *images*
17:50:06 * jkurik was on the Design team meeting today trying to come up with something for the future to avoid it
17:50:10 <adamw> the problem is co-ordinating all the packages
17:50:25 <linuxmodder> adamw,  lost me
17:50:34 <roshi> how many packages are we talking about?
17:50:36 <linuxmodder> co-oordinating what packages
17:50:43 <adamw> we have a ludicrously over-complicated mess of packaging bits for the basic job of 'provide a default desktop background'
17:50:55 <adamw> well, there's desktop-backgrounds
17:51:01 <linuxmodder> those packages yeah i agree
17:51:06 <adamw> then for some reason we decided to have a new source package containing the backgrounds for each release
17:51:11 <adamw> so for *every* release we have to do a new package review
17:51:36 <adamw> and then for some desktops, iirc, we have to adjust stuff in comps / spin-kickstarts, only *after* the new package has been created
17:51:38 <nirik> yeah, just doing one and subpackages might save a lot of pain
17:51:42 <mizmo> adamw: for just a single image its super complicated yes
17:51:44 <mizmo> :(
17:51:44 <linuxmodder> adamw,  thought that the vintage backgrounds packages were non block tho
17:51:57 <mizmo> nirik: i think the reason we dont do just one is that the size would be super large?
17:52:04 <adamw> every release i wind up looking at this stuff because we inevitably mess it up somehow yet again, and i think 'man, this is shonky', and then i forget about all the details again until the next time
17:52:17 <nirik> well, looking at other packages... I can't imagine it would be close to very large
17:52:25 <nirik> we have texlive
17:52:29 <nirik> and 0a-data
17:52:31 <adamw> linuxmodder: sure, but the point is, we have to go through the work of creating a new package and adjusting a bunch of other packages to the new name, *every cycle*
17:52:53 <mizmo> for alpha we dont worry about it so much but for final we have multiple sizes we ship each one is a few megs, so you're looking at 20-30 mb / release
17:52:59 <mizmo> at least
17:53:06 <linuxmodder> adamw,  I know I see the janky rewrite workarounds in the spin-kickstarts ks files
17:53:10 <adamw> there is actually a legitimate amount of complexity involved, i think, but if someone sat down and thought about all the contingencies i'm sure they could come up with a *better* approach than the one we've wound up with
17:53:33 <mizmo> i wish i was in a better place to be able to do that adamw, but packaging is a bit of a dark art to me :(
17:53:48 <nirik> mizmo: well, you don't have to install all the subpackages
17:53:49 <adamw> and for me it's always about number  37 on the todo list, sigh
17:53:50 <linuxmodder> same
17:54:13 <linuxmodder> I can debug tracebacks decently but the packaging bit on the front end is an abyss for me
17:54:32 <mizmo> nirik: we already have subpackages now and i think the way its set now you have to install subpackages you dont even need. like there's fxx-backgrounds, then fxx-gnome-backgrounds, then fxx-kde-backgrounds, then fxx-$desktop-dujour-backgrunds... ad nauseum. per release
17:54:43 <adamw> it should surely at least be possible to get rid of the ridiculous 'new source package every cycle' thing
17:54:43 <mizmo> i think the desktop specific ones ship xml or config
17:54:51 <mizmo> while the base pkg has the binary files
17:54:54 <adamw> and just generate subpackages from one or two source packages
17:55:09 <mizmo> so you'd have subpackages that are desktop config subpackages and then have subpackages that were actually wallpaper art per release packages?
17:55:15 <adamw> mizmo: iirc, the desktops don't all do things the same, which is part of the problem
17:55:23 <linuxmodder> mizmo,  does it look like a weak dep setup could work for that ?
17:55:27 <mizmo> so many snowflakes :(
17:55:37 <nirik> right, so you have 1 source package that stays the same always
17:55:38 <adamw> mizmo: we already *have* that in desktop-backgrounds and fXX-backgrounds (the images are in fXX-backgrounds, teh config is in desktop-backgrounds)
17:55:44 <mizmo> linuxmodder: i dont know enough about packaging / rpm to be able to answer that :(
17:55:53 <nirik> in rawhide you have a desktop-backgrounds-current that has some placeholder stuff.
17:56:01 <adamw> but i was thinking more about having, say 'fedora-current-backgrounds' and 'fedora-legacy-backgrounds' source packages
17:56:07 <adamw> and just changing the *subpackages* of each
17:56:08 <mizmo> adamw: i thought the config changes per release
17:56:13 <mizmo> adamw: oh thats smart
17:56:14 <nirik> after branch you make that have the current release stuff and move the previous one to desktop-backgrounds-f25 subpackage
17:56:18 <adamw> or something along those lines
17:56:27 * nirik is thinking the same as adamw
17:56:34 <mizmo> ++
17:56:37 <adamw> maybe just one source package is OK, it'd have a lot of subpackages but hey
17:56:41 <linuxmodder> maybe post GSoC I will work with a packager to school myself on that craziness and help more there
17:56:44 <adamw> rpm can cope with that
17:56:45 <nirik> but I was thinking you could just keep them around for as long as you want.
17:57:11 <adamw> and the subpackages should have virtual provides
17:57:18 <nirik> right
17:57:24 <sgallagh> Do we actually need to *solve* this in this meeting?
17:57:26 <adamw> so whichever is the 'current' release package should provide current-backgrounds or whatever
17:57:27 <mizmo> this may be an unpopular sentiment
17:57:29 <adamw> no, not really, sorry
17:57:35 <mizmo> but why not just have one source package
17:57:37 <nirik> and then no new review, no changes to comps, no desktop changes (except didn't kde need something?)
17:57:39 <mizmo> and just change the artwork per release
17:57:45 <mizmo> and if you want the old wallpapers - well, we maintain a wiki page for that
17:58:11 <adamw> let's go with 'we don't have to solve this in the meeting' :)
17:58:15 <nirik> sure that could be fine too. I do know people who prefer older ones and want to easily install/use them, but I admit thats probibly a corner case.
17:58:18 <adamw> (copyright (c) sgallagh)
17:58:22 <sgallagh> heh
17:58:23 <nirik> true enough
17:58:28 <mizmo> i personally find it more convenient / intuitive to grab old ones online and install that way anyway
17:58:28 <mizmo> okay
17:58:29 <nirik> but... we should solve it somewhere
17:58:30 <mizmo> :)
17:58:33 <adamw> for sure
17:58:37 <adamw> so
17:58:43 <mizmo> also i am very sorry, this is my fault, if you feel the need to flog someone aim the sentiment at me.
17:58:49 <mizmo> (in terms of alpha's wallpaper being late)
17:58:53 * nirik has most things full screen anyhow, so I never really see the background. ;)
17:58:53 <adamw> i suspect that, if push ultimately came to shove and this was the last blocker, there'd be a strong 'dump the criterion' sentiment
17:58:56 <mizmo> (the pkg mess, i wont take responsibliity for :) )
17:59:03 <adamw> so depending on how much appetite everyone has for argument, we can have that debate
17:59:11 <mizmo> please dump it
17:59:14 <adamw> or we can just say 'eh, we have other blockers anyway, let's accept it and move on'
17:59:16 <mizmo> i think its better for beta
17:59:20 <mizmo> not alpha
17:59:29 <adamw> i don't think moving it to beta alone would solve anything
17:59:37 <adamw> it'd just mean we'd have this mess at beta instead of alpha
17:59:41 * nirik is fine with +1 blocker, make better next tme, move on
17:59:44 <sgallagh> The only real reason for it, IIRC is so that it's clear at a glance to someone that they are not on the stable release.
17:59:50 <sgallagh> Which I think is pretty weak
17:59:50 <roshi> adamw: then we push it to final
18:00:00 <mizmo> well, thats worse then. we need something for beta or we risk a poor quality wallpaper
18:00:01 <roshi> and when we get to final, we push it to N+1
18:00:09 <roshi> and at that point it never is an issue again
18:00:14 * roshi believes we can do it
18:00:15 <adamw> the real problem we have here is a) there's far too much unnecessary work to do each cycle to actually meet the requirements and b) no-one seems to have taken responsibility for making sure all that work gets done every cycle, even though it's completely predictable and plannable-for
18:00:21 <mizmo> for alpha its really a matter of having a placeholder to differentiate alpha imgs from the release before. for beta, it's actually testing out the wallpaper
18:00:24 <mizmo> (imho)
18:00:54 <adamw> sgallagh: the reason it got added is that we had actual people write mailing list posts or forum posts (i forget which) that said "i got this thing i thought was the alpha and installed it but it looks exactly like the stable release, did i get the wrong thing? is it broken?"
18:00:59 <adamw> sounds dumb, but it happened.
18:01:10 * linuxmodder with nirik on this
18:01:28 <jkurik> I am +1 to accept it as one of blockers and move on
18:01:32 <sgallagh> adamw: I think that qualifies as optimizing for the wrong audience
18:01:38 <adamw> roshi: heh...should I create a "Fedora Jam Tomorrow Release Criteria"?
18:01:51 <adamw> "bugs that violate these criteria are always blockers for the *next* release"
18:01:52 <roshi> :D
18:01:53 <sgallagh> And we still have to address how this will play with the no-Alphas piece.
18:02:04 <sgallagh> Do we now have to move the placeholder wallpaper up to the branch date?
18:02:42 <adamw> well, i *think* the placeholder wallpaper should just always be in rawhide
18:02:50 <nirik> that's what I think too
18:02:58 <adamw> and it should be someone's job as soon as possible after branching to put in the 'real' wallpaper for the release
18:03:00 <sgallagh> The same placeholder every time?
18:03:02 <nirik> and when we branch the package is updated to the new one
18:03:03 <adamw> sure
18:03:06 <jkurik> the generated one by roshi's script ?
18:03:08 <sgallagh> Seems reasonable
18:03:25 <adamw> the neat thing about doing it that way is that as long as the real wallpaper gets in *some time* before release, we're good
18:03:26 <nirik> same one or some new one or... design could change it as they like
18:03:27 <sgallagh> Maybe just a mid-90s animated wallpaper of the release number :-D
18:03:39 <adamw> because then all pre-release builds would kinda 'automatically' have different wallpaper from all final releases
18:03:53 <roshi> yeah
18:03:58 <adamw> right, the placeholder wallpaper can always stay the same or just be changed when someone gets bored of it
18:04:11 <adamw> it doesn't really matter so long as it's never the same as any final release wallpaper
18:04:11 <nirik> dancing hotdogs for everyone!
18:04:25 <adamw> and yes it should *obviously* be beefy. this is the only correct answer
18:04:27 <mizmo> i have the perfect one
18:04:33 <roshi> ship it
18:05:23 <mizmo> https://duffy.fedorapeople.org/hotdog/hotdogs-wallpaper.png
18:05:43 <adamw> BINGO
18:05:57 <nirik> nice
18:06:00 <jkurik> it is not vegetarian friendly
18:06:09 <adamw> one of them could be a tofu dog!
18:06:10 <roshi> mizmo drops the mic...
18:06:21 <adamw> anyhoo
18:06:24 <mizmo> YOURE WELCOME
18:06:33 <roshi> lol
18:06:33 <adamw> are we just taking this as a blocker or having the 'change the criteria' debate now?
18:06:36 <nirik> so, +1 blocker, move on?
18:06:38 <mizmo> jkurik: that's ok. i'm a vegetarian so i have the power to say it's ok.
18:06:40 <adamw> i'm all for +1 and move on
18:06:48 <jkurik> ack
18:06:50 <mizmo> thank you and sorry again
18:06:52 <roshi> +1 move on
18:07:06 <dgilmore> mizmo: :D
18:07:13 <sgallagh> 0 blocker, move on
18:09:30 <jkurik> adamw: any "proposed #agreed" ?
18:09:36 <adamw> working on it
18:09:42 <jkurik> ah, sorry
18:09:43 <adamw> proposed #agreed 1434977 - AcceptedBlocker (Alpha) - this is clearly a violation of "The default desktop background must be different from that of the last two stable releases." there is some sentiment to adjust the criteria here, but as we have other blockers, we don't want to thrash that out in this meeting
18:09:58 <sgallagh> ack
18:09:59 <jkurik> ack :)
18:11:20 <adamw> one more ack?
18:11:23 <roshi> ack
18:11:30 <dgilmore> ack
18:12:18 <adamw> #agreed 1434977 - AcceptedBlocker (Alpha) - this is clearly a violation of "The default desktop background must be different from that of the last two stable releases." there is some sentiment to adjust the criteria here, but as we have other blockers, we don't want to thrash that out in this meeting
18:12:22 <jkurik> adamw: thanks for the blocker review
18:12:25 <adamw> ok, that took quite a bit of time, so let's skip the proposed FEs
18:12:31 <adamw> nothing there needs doing right now i don't think
18:12:37 <jkurik> adamw++
18:12:37 <zodbot> jkurik: Karma for adamwill changed to 25 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:12:38 <adamw> but if people could vote in-bug on the LLVM one that'd be helpful
18:13:06 <jkurik> moving on ...
18:13:11 <jkurik> #topic Test Matrices coverage
18:13:15 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_26_Alpha_1.2_Summary
18:13:20 <jkurik> IMO the Test Matrices have quite good coverage, however some parts are missing.
18:13:23 <jkurik> i.e.: FreeIPA, Active Directory
18:13:27 <jkurik> just stating as we are no-go either
18:13:31 <jkurik> IMO we might skip this part
18:13:35 <jkurik> ack ?
18:14:06 <sgallagh> I thought the FreeIPA stuff was automated these days, adamw?
18:14:31 <roshi> ack
18:14:52 <roshi> coverage does look pretty good though, all in all (freeipa, ad not withstanding)
18:15:11 <adamw> sgallagh: yeah, it is, i'll have to check why those tests aren't reporting as passes
18:15:15 <adamw> too much to do :L/
18:15:36 <adamw> openqa doesn't report failures, so if an expected spot is empty, it could mean the test didn't run or that it failedf.
18:15:58 <jkurik> ok, so lets go to the final part
18:16:02 <jkurik> #topic Go/No-Go decision
18:16:23 <jkurik> QE, FESCo, RelEng: we need your votes
18:16:34 <sgallagh> No-Go with my FESCo hat on
18:16:35 <jkurik> I am +1 to slip and delay for one week
18:16:41 <roshi> No-Go, QA
18:16:42 <nirik> no go
18:16:47 <dgilmore> no go
18:16:49 <nirik> (whoever I am for)
18:17:03 <jkurik> ok, thanks
18:17:11 <jkurik> #action jkurik to publish the Go/No-Go result
18:17:23 <dgilmore> nirik: you are for the people oppresed by the man :D
18:17:44 <nirik> down with the man!
18:17:45 <jkurik> #info The result of this meeting is No-Go due to present blockers. The whole release slips for one week
18:17:56 <sgallagh> Wait, does that make me "the man"?
18:17:59 <jforbes> no go
18:18:24 <jkurik> #info There will be one more Go/No-Go meetin the next Thursday at the same time
18:18:45 <jkurik> #undo
18:18:45 <zodbot> Removing item from minutes: INFO by jkurik at 18:18:24 : There will be one more Go/No-Go meetin the next Thursday at the same time
18:18:57 <jkurik> #info There will be one more Go/No-Go meeting the next Thursday at the same time
18:19:04 <jkurik> #topic Open floor
18:19:09 <sgallagh> will it be the same time?
18:19:10 <jkurik> anything else to discuss today on this meeting ?
18:19:16 <jkurik> sgallagh: yes
18:19:18 <sgallagh> What with Europe DST change?
18:19:34 <ignatenkobrain> sgallagh: it will happen :P
18:19:37 <jkurik> I guess I am the only one affected in this group
18:20:28 <jkurik> anyone has any problem having the next meeting at the same time (UTC) ?
18:21:23 <jkurik> probably not...
18:21:32 <jkurik> so thanks for comming
18:21:36 * roshi has no issue with that
18:21:39 <sgallagh> WFM
18:21:48 * jkurik waits
18:24:36 <adamw> fine by me
18:25:52 <jkurik> sgallagh: shall we still wait for you ?
18:28:50 <jkurik> sgallagh: actually WFM means "Wait For a Moment" or "Works For Me" ?
18:29:21 <roshi> I always mean works for me when I say WFM
18:29:33 <roshi> have I been doing it wrong?
18:30:32 <jkurik> hmmm.. these abbreviations ... then lets end this meeting
18:30:37 <jkurik> #endmeeting