Here is the initial concept on
https://github.com/fedoradesign/backgrounds

So to combine and summarize my ideas:

* There should be just one, unversioned, source package for the actual images (what goes in the versioned source packages currently). Let's call it, for argument's sake, 'fedora-backgrounds'.

* There is a single subpackage of that source package which contains the artwork that is *always* used for Rawhide. This artwork should *never* be the same as the artwork for any stable release, and it should clearly indicate that you're running something unstable (a jokey image, like something with Beefy, would be a good idea). Let's call it 'fedora-backgrounds-rawhide'.

* For each new release, soon after branching, we add a new subpackage to the source package containing the artwork for that release. Let's call these 'fedora-26-backgrounds', 'fedora-27-backgrounds', etc. (To be clear, I'm not stuck on these names, they're just ones I'm using for the purpose of this proposal). We also change the 'desktop-backgrounds' package on the branch to require the new release versioned 'fedora-backgrounds' subpackages. The Rawhide 'desktop-backgrounds' package should always require 'fedora-backgrounds-rawhide', and at branch point it should be rebuilt so it is higher versioned than the version on the branch. Any necessary changes to kickstarts and comps should also be made at this time. Ideally we should go through how all the desktops implement their backgrounds and try to harmonize them as much as possible, to reduce the amount of stuff that needs to be done.

* There should be an SOP documenting all these actions, and it should be a specific team's responsibility to do it by a certain point for every release, and the FPM's responsibility to check and make sure it gets done by that point.

That's basically my proposal. If anyone can think of a better way to finesse the packaging bits so less work is required at each branch point, please do suggest it, that's the best I could do. Also yell if you can think of a part of the process I didn't consider.

Swapping emails to the one I use for bugzilla. :) 

My idea is basically a single source package, 'desktop-backgrounds' that replaces making a new fN one each cycle. Then, at branching, we rebuild the rawhide one (to keep upgrade path) and the branched one (to move the 'current' backgrounds to a new fN subpackage and point the current ones at the same 'placeholder' ones as rawhide. Then when artwork is ready, branched is just updated to point the current subpackages at the new artwork and we are done. 

So basically similar to what adam suggests with less detail. ;) 

We could either just keep around the old subpackages (in case someone wants to install / use them) or just drop them at branch time too if we don't want them packaged anymore. 

I'll try and dig into this at some point, but not sure when...

Oh, Nice to haves: 

* Can we make it so there's no changes to comps/spin-kickstarts needed?

* Can we make it so no other packages need to change? wasn't there a kde package that needs to have the number hard coded or something?

* If we are doing a bunch of things at branching, perhaps we could get releng to do these things when they update fedora-release and fedora-repos?

"Can we make it so there's no changes to comps/spin-kickstarts needed?"

IIRC (I'll have to refresh my memory on this), this is basically what the current desktop-backgrounds package is intended for: the idea is that comps groups and kickstart files should include desktop-backgrounds subpackages, and the desktop-backgrounds subpackages should require the appropriate fXX-backgrounds package. The problem is, again IIRC, that some desktops don't actually bother using this system, and just list fXX-backgrounds directly in comps/kickstarts.

So today I got to figure out the KDE wrinkles :/

For F26, KDE didn't get the correct appearance even after:

1) f26-backgrounds is created
2) desktop-backgrounds is bumped
3) comps and kickstarts are updated

It seems two changes are needed to the kde-settings package. Firstly, the kde-settings-plasma subpackage has a direct dependency on fXX-backgrounds that has to be incremented (from f25-backgrounds to f26-backgrounds, in the F26 case). Secondly, there's a file in the package *source* that has to be changed: usr/share/kde-settings/kde-profile/default/xdg/plasmarc . It specifies the name of the default Plasma theme (I think), and that name is versioned - so for the F26 case, I had to bump it from 'F25' to 'F26'.

So obviously if we want to make this not suck, we need to rejig the KDE/Plasma bits so no-one has to change this stuff in kde-settings every cycle.

If I recall, during f25 development, I made efforts to make the wallpaper setup for kde spin much simpler.

One last snag I ran into Adam highlighted in comment #5... I would've liked to make the Plasma theme unversioned, but that would also mean the background name, files, and/or themename it provides needs to be unversioned or static too (ie, it likely requires changes on both sides).

So, no response to my comment #6 yet, so I'll be more specific to address item 2 "nice to have" from comment #3:

If there is a desire to make new wallpaper/backgrounds 'just work' in kde spin without making further changes, then the default wallpaper theme name needs to be the same between fedora releases too.

for example, there's this,
/usr/share/backgrounds/default.png
(provided by desktop-backgrounds-compat)

which is used already in several places.  A downside to this is that it's a single image (and doesn't support varying resolutions/form-factors).

What I'd like, is there to be something like:
/usr/share/backgrounds/fedora
or
/usr/share/backgrounds/default
or 
whatever (I don't care what it's called, can bikeshed that later), and matching plasma-styled items under /usr/share/wallpapers, which always points to whatever is the default wallpaper for any particular fedora release.

Implementing this introduces one extra complication to new fedora releases: When and how to flip whatever provides this new static wallpaper (ie, only one package can and should provide it at any given time).  For example, when f26-backgrounds is introduced, then f25-backgrounds will need to be modified to drop providing the default one.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

*** Bug 1319865 has been marked as a duplicate of this bug. ***

FEDORA-2021-efd2ac9517 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-efd2ac9517

FEDORA-2021-efd2ac9517 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-efd2ac9517`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-efd2ac9517

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-efd2ac9517 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Reopening