Proposal to improve the background packaging process

Project Discussion
1

We have a kinda recurring problem where the backgrounds for new Fedora releases aren’t done in time. This has happened again for Fedora 39: the “F39 wallpaper deadline” was 2023-07-25, but we branched Fedora 39 on 2023-08-08 and the backgrounds were not ready.

This causes problems for the quality-team , because we have an automated test that checks whether an appropriate background is being used for the release. If there is no background associated with the release, this test kinda has to fail - every day (on the compose), and multiple times a day (on updates). I also have to tweak the update gating policy to not gate updates on this test, since it always fails.

It also causes problems for the release process, particularly if the problem stretches into the Beta freeze, because whenever the backgrounds finally arrive, we have to get the new fXX-backgrounds package through the review process, then make changes to other packages (desktop-backgrounds and kde-settings) to use it. If we’re in freeze, this all becomes harder because everything needs freeze exceptions and karma.

I have two ideas to improve on this. Both of them involve a common base. We should create a script which produces an fXX-backgrounds package with a placeholder background image, perhaps generated via GraphicsMagick or something similar - just a plain blue background (in some recognizably ‘Fedora’ blue, I guess) with “Fedora XX Placeholder Background” written on it (edit: I guess it could show a URL to a design team landing page for helping to create the real background?)

Idea 1: the blunderbuss approach. We write this script and then we mass-create and mass-approve packages for f39-backgrounds all the way through to f99-backgrounds. Benefits: it’s simple, we only have to do this part once. Drawbacks: if we ever change the layout of the fXX-backgrounds package, we would probably have to mass-update all the remaining ‘future’ packages. If we at any point abandon Fedora or change the name scheme or revise the whole way we do backgrounds or give up on backgrounds entirely or upload ourselves to the singularity, we will wind up with a bunch of ‘odd’ pre-approved packages which exist for no real reason.

Idea 2: at each branch point, we create and review the package for the next release. So at F39 branching, we create f40-backgrounds and land it in Rawhide (then we can immediately adjust desktop-backgrounds and kde-settings and comps for it). Benefits: we only create the package when we need it, and if we want to change the layout of the package, we can update the script before creating the package. Drawbacks: it’s a bit of work someone has to do every cycle (we’d probably want to put it in the branching SOP).

Either way, the big benefit is we can get all the packaging work out of the way very early in the cycle, at a time when there definitely isn’t a freeze and karma requirements aren’t in place. I can pre-create the needles for the openQA tests so they aren’t disrupted by the changeovers.

When the real artwork is done, all we have to do is update the fXX-backgrounds package with the new image files. We don’t need to go through the package review process and update another two packages and the comps file, all probably in a hurry and maybe having to deal with freezes and karma.

Thoughts? Thanks!

@kevin @luya

7 Likes
2

sorry, forgot one more benefit: the release criteria for backgrounds say that the Beta release only needs to have “a background that is different from the previous two releases”. Only the Final release actually needs to have the correct intended artwork.

So, technically, the placeholder backgrounds would satisfy the Beta release criteria, and with this system we would never need to jump through the release blocker process hoops unless the real background wasn’t ready for Final. With the current process, we often wind up needing a blocker bug for Beta, because the Beta using the same background as the previous release (which is what happens with the current process) is against the criteria.

4 Likes
3

We did a variant of idea 2 in Release engineering for signing keys. We
were always scambling to make the new key and get it pushed out and hope
that everyone updated in time. So, we just moved ahead a release. When
we branched f39 this time, we made the f41 keys and added them to
packages. That way in 6 months, we are sure everyone has them, we don’t
have to scramble, etc.

I think doing this for the backgrounds is a great idea. Either as
suggested with just a placeholder, or do the f40 ones now and stay a
release ahead.

3 Likes
4

well, I think that’s effectively the same here - we don’t need to be so far ahead for backgrounds, because there aren’t any actual requirements for backgrounds in Rawhide. Creating the backgrounds for the new Branched release at branch time would be doing it “just in time”, creating the backgrounds for the new Rawhide release at branch time is doing it six months ahead of when it really needs to be done. We could go two releases ahead, of course, there’d be little harm in doing it, but I’m not sure it’s needed.

1 Like
5

Is there a reason to not have a single ‘fedora-backgrounds’ package and synch version number to Fedora release number?

Rawhide could have its own background which acts as placeholder for branched also, until the final artwork is pushed into branched.

And at branching time, the rawhide branch would be bumped to F+1

6

yes, the reason is that people sometimes like old backgrounds and want to use them.

I have gone down rabbit holes thinking about bigger changes to the background process several times, never got anywhere, and don’t want to make that mistake again. I just want to propose something that’s clearly implementable right now without any fundamental change to how we do things.

2 Likes
7

This is the far less silly way (although idea 1 would get us through to Fedora Linux 99, which is currently targeted for 2053-10-21T05:00:00Z if I do the math correctly). It’s also related to a goal that Matthew and I discussed with the Design team a while back. We wanted to get to the point where not only was the package created for N+1 at the N branch point, but that the artwork was done, too.

Since the artwork takes a while, it was going to take several releases to catch up to that point. And then something came along and derailed that (COVID? Something else? I don’t remember). I think it’s worth trying to achieve that goal again, and from my perspective (since I wouldn’t have to do any of the work) starting with pre-creating the package is a nice incremental improvement until the artwork can catch up.

2 Likes
8

Big +1 from me for Idea 2. This feels like the right place to do it while keeping this open for later changes.

1 Like
9

Quick update - since the feedback was positive I started working on this, but it’s a bit more complex than I expected (I forgot the source for the fXX-backgrounds packages is a whole upstream, not just a couple of files). I’ll keep trucking on it when I have the time.

My current plan is to rejig the upstream so you can run a single make command (or similar) with a release number and image file(s) as arguments to put it in a correct state for that release number with those images, then generate a tarball the package spec can use…still a work in progress, though.

1 Like
10

I have a wild thought, what if for fxx beta you create the package with fxx-1 background images, and then for fxx final you have the actual background intended by the design team?

11

well that’s essentially what this would achieve, only earlier. the placeholder background would essentially always be there, for each release, from the time rawhide ‘becomes’ that release. the design team could replace it with the real background at any time between then and final (but ideally as early as possible).

1 Like
12

+1 to idea 2. Though I would suggest to make one package fedora-backgrounds package and have fXX-backgrounds as a subpackage. This way you do not need to do a package review each 6 months. And the build will be delivered in time.

13

That, again, gets into the topic of ‘wider changes to the process which I don’t want to fall down right now’. The specific problem with just having one source package is it would be a very big source package. Right now it would have to have 40 subpackages, and each six months it grows another. That would result in a very unwieldy spec if maintained manually, or one of those awful specs that’s generated by some kind of tool/script somebody made up and everyone else then has to understand for the next decade.

1 Like
14

How about having a rawhide-backgrounds package that virtually provide fxx-backgrounds (xx = N+1) but with s low version number?

That way when the actual background package is ready it will replace the fake package, and we then bump the virtual provide for the next release

15

I don’t like that, because then we still have to do all the package review and Bodhi stuff when the real backgrounds are ready, which is often at a sufficiently late point that we really don’t want to have to wait for all of that hoop-jumping. part of the point of this proposal is to avoid that.

1 Like
16

Thanks @adamwill for opening this discussion to improve the background process and taking over while I was away due to busy schedule. Idea 2 was a good approach. Also in the future, filing exception for fXX-backgrounds packaging also improved the process as the spec file practically remains unchanged.

17

In addtion of what @adamwill mentioned, previous backgrounds collection were huge in size notably for the time of day effects until at least Fedora 33 where the process were finally simplified. Maybe in a future someone will set up the set of default backgrounds for every 10 previous releases of Fedora, how to effectively do it is another story.