17:00:13 #startmeeting F26 Alpha Go/No-Go meeting the 2nd round 17:00:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:13 The meeting name has been set to 'f26_alpha_go/no-go_meeting_the_2nd_round' 17:00:20 #meetingname F26-Alpha-Go-No-Go-meeting-2nd 17:00:20 The meeting name has been set to 'f26-alpha-go-no-go-meeting-2nd' 17:00:23 #topic Roll Call 17:00:28 .hello jkurik 17:00:28 jkurik: jkurik 'Jan Kurik' 17:00:31 welcome no-goers. ;) 17:00:36 #chair dgilmore nirik adamw sgallagh roshi mboddu 17:00:36 Current chairs: adamw dgilmore jkurik mboddu nirik roshi sgallagh 17:00:53 nirik: hi 17:01:03 .hello roshi 17:01:04 roshi: roshi 'Mike Ruckman' 17:01:19 .hello adamwill 17:01:20 adamw: adamwill 'Adam Williamson' 17:01:26 .hello sgallagh 17:01:27 sgallagh: sgallagh 'Stephen Gallagher' 17:01:32 hi adamw, roshi, sgallagh 17:02:10 we need someone from releng 17:02:12 dgilmore, mboddu are you available for the meeting ? 17:02:20 jkurik: I am around 17:02:25 great 17:02:33 #topic Purpose of this meeting 17:02:37 #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 #info This is determined in a few ways: 17:02:44 #info No remaining blocker bugs 17:02:48 #link https://qa.fedoraproject.org/blockerbugs/milestone/26/alpha/buglist 17:02:53 #info Release candidate compose is available 17:02:57 #link https://pagure.io/releng/issue/6701 17:03:01 #info Test matrices for Alpha are fully completed 17:03:04 #link https://fedoraproject.org/wiki/Test_Results:Fedora_26_Alpha_1.2_Summary 17:03:08 #topic Current status 17:03:13 #info F26 Alpha RC Compose 1.2 is available 17:03:17 #link https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170321.1/compose/ 17:03:22 #info We have 4 proposed and 2 accepted blockers for F26 Alpha. 17:03:32 Let's start with Mini-blocker review 17:03:41 roshi, adamw: may I ask you please to chair the mini-blocker review ? 17:03:44 sure. 17:03:46 did i get a chair? 17:03:53 yes 17:03:56 #topic Mini-Blocker Review 17:03:59 you got it adamw ? 17:04:04 sure 17:04:12 #info 4 Proposed Blockers 17:04:12 #info 2 Accepted Blockers 17:04:16 #info 3 Proposed Freeze Exceptions 17:04:16 #info 8 Accepted Freeze Exceptions 17:04:17 * roshi relaxes then 17:04:22 that's what we have for Alpha. i guess we can ignore the FEs. 17:04:32 ack 17:04:42 #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 #topic (1434977) Fedora 26 backgrounds are the same as Fedora 25 17:05:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=1434977 17:05:03 #info Proposed Blocker, distribution, NEW 17:05:08 so, this one makes me quite sad... 17:05:14 yeah 17:05:18 in fact 17:05:21 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 as i suspect discussion of it will go differently depending on whether we accept the other proposals 17:05:51 sound OK? 17:05:55 sure 17:05:57 +1 from me 17:05:58 ack 17:06:02 #info we'll circle back to this one later 17:06:14 #topic (1433899) Workstation Live panics during boot 17:06:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1433899 17:06:14 #info Proposed Blocker, kernel, NEW 17:06:30 just a quick note - this one and the next one (#1434462) are likely the same bug 17:06:46 lemme see if labbott is around 17:08:19 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 AFAIK, no-one has yet seen this happen on bare metal 17:08:51 does that sound about right to everyone? 17:09:01 * jkurik has the same understanding 17:09:02 almost 17:09:10 what it looks like from whats in the bug 17:09:11 I have seen the early boot hang once on bare metal 17:09:18 I suspect that's a different issue 17:09:27 And the hang resolves itself in three minutes, so I wouldn't block on it 17:09:39 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 https://bugzilla.redhat.com/show_bug.cgi?id=1434462 is very likely the same bug 17:10:32 cloud works fine 17:10:37 https://bugzilla.kernel.org/show_bug.cgi?id=194911 may well be the same bug 17:11:10 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 i think there has to be at least some use of virtio in the VM config 17:11:30 but that's the default for libvirt 17:12:30 https://bugzilla.redhat.com/show_bug.cgi?id=1430297 is also likely the same bug 17:13:25 so, this is obviously pretty bad 17:13:42 yeah. 17:13:52 one key thing here is that we explicitly make VM functionality part of the *beta* criteria 17:13:52 I think this is probably show-stopper bad 17:13:54 pertty much 17:14:14 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 Because realistically, who besides Fedora QA would install an alpha on physical hardware these days? 17:14:25 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 do we have a fix? there was a test kernel? 17:15:48 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 Yeah, looks like the test kernel fixed things, but it was a scratch 17:16:07 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 sgallagh: makes sense for me 17:16:41 was discussed in #fedora-kernel: 17:16:44 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 ah, i see it now. 17:17:01 [17:23:37] okay I have a scratch build with roughly the entire virtio tree that was merged reverted 17:17:01 [17:23:40] 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507 17:17:01 [17:23:45] https://koji.fedoraproject.org/koji/taskinfo?taskID=18529971 17:17:14 right 17:17:28 * dgilmore holds jforbes responsible :D 17:17:40 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 jforbes: whats the confidence in the revert fixing things? 17:17:58 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 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 dgilmore: no clue, I only know what was posted in #fedora-kernel 17:18:28 adamw: That draft is likely useless, since this is our last-ever Alpha 17:18:30 adamw: I would think a large number of alpha users do so in virt 17:18:31 02:45:10> labbott: https://bugzilla.redhat.com/show_bug.cgi?id=1430297#c7 .. yes it's better 17:18:33 didn't we have a rule for not changing the critera on the fly like that? ;) 17:18:54 sgallagh: not really, since the idea of 'no more alphas' is that we're *always* at alpha quality 17:19:09 nirik: no, we had viking_ice who was extremely against it. fortunately, he's bugging suse people instead now. :P 17:19:12 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 we have done this same kind of thing a few times before, there's precedent. 17:19:44 alright. 17:20:13 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 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 nirik: exactly 17:20:59 Yes, agreed 17:21:04 basically we would be saying: alpha critera should always be met/blocked if they break, etc. 17:21:05 well, it kinda should be already 17:21:17 the openqa tests should run into it 17:21:25 BTW, I am curious: when did this kernel virtio change land? Before or after Freeze? 17:21:29 adamw: have they? 17:21:35 Well, remember, this is only certain VMs. It has been booting in our test VMs just fine 17:21:52 dgilmore: i tweaked the openqa tests when we found https://bugzilla.redhat.com/show_bug.cgi?id=1430043 17:22:05 jforbes: Then you probably need to add some virtio configs to your test suite :) 17:22:08 i changed them to use IDE optical drives instead of virtio 17:22:20 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 sgallagh: We don't use optical at all 17:22:40 jforbes: i don't think optical is necessarily involved, i don't think rwmjones' reproducer attaches an optical drive 17:22:44 sgallagh: though we do use virtio HDs, booting ISOs doesn't make sense when we only want to test kernels 17:22:59 i don't think we quite nailed down precisely what hardware config is necessary to run into this one 17:23:05 only that default virt-manager and boxes VMs have whatever it is 17:23:11 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 nirik: yeah, we should actually probably have something like that. anyhoo 17:23:40 right, sorry, weeds. 17:23:42 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 17:23:53 So, on the topic at hand: does anyone *disagree* that this should be a blocker? 17:24:07 ...and thus that we should move some or all of the virt requirements from beta to alpha? 17:24:11 i'm fine with that. 17:24:32 what are all of them? 17:24:33 * nirik looks 17:24:44 finaly I am +1 to block 17:24:49 i'm just being vague to cover my ass 17:24:50 dord it naturally recover ? not had a chance to screw with work 26 17:24:58 linuxmodder: no, if you hit this, boot fails 17:25:01 you just have to try again 17:25:20 then +1 block from me 17:25:25 ok, it's only 2 things... 17:25:26 as to the 'did this show up before or after freeze?' question - i haven't established that yet 17:25:37 the *other* bug complicates that a bit 17:25:40 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 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 jforbes: there's a smaller fix upstream now. 17:25:59 there is? 17:26:01 I'd say we don't need the first one (hosting a VM) 17:26:03 but needs a build/tested 17:26:06 nirik: where? 17:26:10 For Alpha, I mean 17:26:24 sgallagh: the criterion is quite...efficient, it's intended to be read as covering both host and guest functionality 17:26:30 nirik: much better. I haven't looked this morning 17:26:40 https://lkml.org/lkml/2017/3/23/38 17:26:42 but i guess we could split it up 17:26:51 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 I'm reluctantly +1 after following the discussion 17:26:58 sgallagh: fair enough, we can do that. 17:27:23 and rwmjones and thl said it fixed things for them 17:27:37 oh, they tested it already? awesome 17:27:54 you mean some people were working this morning while i was fiddling around with flashing bootloaders on my tablet? jeez 17:28:11 jforbes: so could we get a kernel build with that patch, then? 17:28:15 slacker. ;) 17:28:37 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 sgallagh: I'm ok with that too... host seems a bit much all the time... 17:28:50 jforbes: well, we're gonna wind up slipping a week most likely 17:28:51 adamw: sure, do you also want the crda fix in there? 17:28:58 +1 to guest moving to Alpha and Host staying at Beta 17:29:02 jforbes: i'd actually be inclined just to take the 'better' fix rather than the revert, given that 17:29:03 wdyt? 17:29:15 jforbes: crda fix? 17:29:51 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 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 ack 17:30:28 ack 17:30:29 it is a simple math error, ++n was changed to n++ 17:30:41 ack 17:30:44 ack 17:30:46 ack 17:30:50 jforbes: d'oh. um. sure, yeah, submarine that in there. technically we should nominate and accept the bug as an FE... 17:31:00 #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 #topic (1434462) frequent kernel panic during VM boot 17:31:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1434462 17:31:19 #info Proposed Blocker, kernel, NEW 17:31:21 adamw: is working wifi an alpha requirement? 17:31:31 so i'm gonna propose we assume for now that this is the same as the previous bug 17:31:41 adamw: +11 17:31:43 err, + 17:31:45 gah! 17:31:49 you get the idea 17:31:52 don't think so, at least not in the sense that setting regulatory country is 17:31:58 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 roshi: adamw it is quite common actually for people outside of NA 17:32:32 #info we're going to assume for now that this is the same as the previous bug (#1433899) 17:32:40 #info we'll do bugzilla bureaucracy later 17:32:55 +1 FE on the wifi part 17:33:08 jforbes: what is the CRDA bug #? 17:33:09 #topic (1435010) GNOME fails to start without modesetting (Fedora 'basic graphics') mode 17:33:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1435010 17:33:09 #info Proposed Blocker, mutter, NEW 17:33:19 sigh 17:33:32 * roshi didn't think something like this would slip through 17:33:32 adamw: https://bugzilla.redhat.com/show_bug.cgi?id=1422247 17:34:01 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 I saw this yesterday on one of my systems 17:34:27 I'm not really sure how common this is though. 17:34:49 Though if it's one of the selectable boot options, I suppose we should make it work. 17:34:56 this is a big nostra culpa for qa, sorry 17:35:02 Though I'd also accept "remove that boot option" as a valid way to unblock this. 17:35:03 I am frequent vesa user, so for me this is blocking 17:35:18 nirik: we've never put it in openQA because the test specifies it must be done on bare metal 17:35:27 but we really should have an openQA test for it *anyway*, just not mark it as a wiki pass 17:35:30 ha, fair enough I guess. 17:35:33 at least then we'd catch cases where it *does* fail in virt 17:35:47 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 it happens 100% of the time on my macbook. 17:36:08 i spend so much time herding the robots these days I never got around to the manual tests :/ 17:36:20 yeah, it seemed pretty reproducible to me too, i tried it several times 17:36:34 I hit it both times I tried it 17:36:36 sgallagh: the criteria actually state that the boot option must be there 17:36:50 of course it does :-| 17:36:58 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 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 nirik: In my case it was an nVidia GeForce 1070, which is waiting for kernel 4.12 to have nouveau suppotr 17:37:29 not just a 'vague feeling' 17:37:32 nirik: I am not sure atm, that is a set of old HW I have at home 17:37:44 alright. 17:37:59 So it isn't just about old hardware. Sometimes it's "too new" hardware 17:38:12 anyhow, I am +1 blocker for it 17:38:23 Yes, +1 blocker 17:38:32 +1 to block 17:38:44 +1 17:39:12 hopefully it won't be too bad to fix... 17:39:17 +1 17:39:18 i hope not 17:39:46 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 jforbes: ok, i'll do a quick FE review for that next 17:40:04 ack 17:40:07 ack 17:40:14 ack 17:40:29 ack 17:40:36 #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 so that's all the proposed blockers 17:40:53 but we're gonna do a quick review of the wifi bug jforbes wanted FE status for 17:41:00 #info we're doing one quick FE review 17:41:36 #topic (1422247) Can't set crda with 4.10 kernel 17:41:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1422247 17:41:55 #info Proposed Freeze Exception, kernel, MODIFIED 17:42:31 So, we know the fix, one liner, very simple and low risk 17:42:36 +1 17:42:45 +1 FE 17:42:51 +1 FE, obviously it's bad for people not to be able to get online from the lives and netinsts 17:43:09 any objections? 17:43:16 +1 FE 17:43:16 speak now or forever hold your mouse 17:43:21 +1 FE 17:43:30 *SQUEEK* 17:43:45 +1 FE 17:44:19 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 ack 17:44:34 ack 17:44:34 Cool, will get a kernel going with those 2 patches in 17:44:36 ack 17:44:36 ack 17:45:16 jforbes, lmk when its built I'll tst and karma today for you 17:45:47 linuxmodder: will do, probably be 7 hours or so 17:46:22 no prob I have kernel alerts in bodhi but not yours in particular just the kernel itself :P 17:46:46 I'm utc -4 so no biggie and I keep long hours 17:47:29 #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 i'll just see if any other proposed FE looks super urgent 17:48:15 we still need to rant about backgrounds too right? 17:48:26 yup 17:48:34 oh, yes. 17:48:37 thanks for the reminder 17:48:57 #topic (1434977) Fedora 26 backgrounds are the same as Fedora 25 17:48:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1434977 17:48:57 #info Proposed Blocker, distribution, NEW 17:49:07 but seriously, I can have a script generate a background so this doesn't happen 17:49:22 then the autogenerated one can be replaced when the real ones are ready 17:49:39 any eta on the real ones roshi 17:49:50 I think we may want to rethink this criterion in the new no-Alpha world as well 17:49:57 or is that a design team thing still 17:50:01 mizmo: any update? 17:50:04 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 the problem is co-ordinating all the packages 17:50:25 adamw, lost me 17:50:34 how many packages are we talking about? 17:50:36 co-oordinating what packages 17:50:43 we have a ludicrously over-complicated mess of packaging bits for the basic job of 'provide a default desktop background' 17:50:55 well, there's desktop-backgrounds 17:51:01 those packages yeah i agree 17:51:06 then for some reason we decided to have a new source package containing the backgrounds for each release 17:51:11 so for *every* release we have to do a new package review 17:51:36 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 yeah, just doing one and subpackages might save a lot of pain 17:51:42 adamw: for just a single image its super complicated yes 17:51:44 :( 17:51:44 adamw, thought that the vintage backgrounds packages were non block tho 17:51:57 nirik: i think the reason we dont do just one is that the size would be super large? 17:52:04 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 well, looking at other packages... I can't imagine it would be close to very large 17:52:25 we have texlive 17:52:29 and 0a-data 17:52:31 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 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 at least 17:53:06 adamw, I know I see the janky rewrite workarounds in the spin-kickstarts ks files 17:53:10 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 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 mizmo: well, you don't have to install all the subpackages 17:53:49 and for me it's always about number 37 on the todo list, sigh 17:53:50 same 17:54:13 I can debug tracebacks decently but the packaging bit on the front end is an abyss for me 17:54:32 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 it should surely at least be possible to get rid of the ridiculous 'new source package every cycle' thing 17:54:43 i think the desktop specific ones ship xml or config 17:54:51 while the base pkg has the binary files 17:54:54 and just generate subpackages from one or two source packages 17:55:09 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 mizmo: iirc, the desktops don't all do things the same, which is part of the problem 17:55:23 mizmo, does it look like a weak dep setup could work for that ? 17:55:27 so many snowflakes :( 17:55:37 right, so you have 1 source package that stays the same always 17:55:38 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 linuxmodder: i dont know enough about packaging / rpm to be able to answer that :( 17:55:53 in rawhide you have a desktop-backgrounds-current that has some placeholder stuff. 17:56:01 but i was thinking more about having, say 'fedora-current-backgrounds' and 'fedora-legacy-backgrounds' source packages 17:56:07 and just changing the *subpackages* of each 17:56:08 adamw: i thought the config changes per release 17:56:13 adamw: oh thats smart 17:56:14 after branch you make that have the current release stuff and move the previous one to desktop-backgrounds-f25 subpackage 17:56:18 or something along those lines 17:56:27 * nirik is thinking the same as adamw 17:56:34 ++ 17:56:37 maybe just one source package is OK, it'd have a lot of subpackages but hey 17:56:41 maybe post GSoC I will work with a packager to school myself on that craziness and help more there 17:56:44 rpm can cope with that 17:56:45 but I was thinking you could just keep them around for as long as you want. 17:57:11 and the subpackages should have virtual provides 17:57:18 right 17:57:24 Do we actually need to *solve* this in this meeting? 17:57:26 so whichever is the 'current' release package should provide current-backgrounds or whatever 17:57:27 this may be an unpopular sentiment 17:57:29 no, not really, sorry 17:57:35 but why not just have one source package 17:57:37 and then no new review, no changes to comps, no desktop changes (except didn't kde need something?) 17:57:39 and just change the artwork per release 17:57:45 and if you want the old wallpapers - well, we maintain a wiki page for that 17:58:11 let's go with 'we don't have to solve this in the meeting' :) 17:58:15 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 (copyright (c) sgallagh) 17:58:22 heh 17:58:23 true enough 17:58:28 i personally find it more convenient / intuitive to grab old ones online and install that way anyway 17:58:28 okay 17:58:29 but... we should solve it somewhere 17:58:30 :) 17:58:33 for sure 17:58:37 so 17:58:43 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 (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 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 (the pkg mess, i wont take responsibliity for :) ) 17:59:03 so depending on how much appetite everyone has for argument, we can have that debate 17:59:11 please dump it 17:59:14 or we can just say 'eh, we have other blockers anyway, let's accept it and move on' 17:59:16 i think its better for beta 17:59:20 not alpha 17:59:29 i don't think moving it to beta alone would solve anything 17:59:37 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 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 Which I think is pretty weak 17:59:50 adamw: then we push it to final 18:00:00 well, thats worse then. we need something for beta or we risk a poor quality wallpaper 18:00:01 and when we get to final, we push it to N+1 18:00:09 and at that point it never is an issue again 18:00:14 * roshi believes we can do it 18:00:15 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 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 (imho) 18:00:54 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 sounds dumb, but it happened. 18:01:10 * linuxmodder with nirik on this 18:01:28