Right now, we have two main criteria around the default background/wallpaper for Fedora releases:
Basic Criterion: "The default desktop background must be different from that of the last two stable releases."
Final Criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
The reason for the Basic Criterion is largely to ensure that people have a simple visual reminder that they are not using a stable release. I don't agree with the exact phrasing there.
Proposal 1: Basic Criterion: "The default visual experience of Fedora pre-releases must be sufficiently differentiated from stable releases so as to avoid easy confusion." We can then expand on that to use the current criterion as an example of how that may be accomplished (but it need not be the only way). [1]
The reason for the Final criterion is a fit-and-polish one. We want to ensure that the final product is as clean as we can make it. However, I don't think we necessarily should block the release just for the background.
Proposal 2: Final Criterion: "Fedora may not ship release-blocking desktops with visibly[2] unfinished artwork."
We would then add the following to the list of Automatic Freeze Exceptions[3] : "Changes that modify only the aesthetic of Fedora, such as the default wallpaper or window manager themes." This would allow us to get late fixes in for the wallpaper and similar artwork, but not require us to slip for it.
[1] I envision a world where we could theoretically have the "Background Logo" GNOME extension display a "pre-release" notation or something similar.
[2] Defining "visibly" as "an average user would consider it out of place, such as UI elements being completely missing".
[3] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Automatic...
On Wed, 2020-04-15 at 17:14 -0400, Stephen Gallagher wrote:
Right now, we have two main criteria around the default background/wallpaper for Fedora releases:
Basic Criterion: "The default desktop background must be different from that of the last two stable releases."
Final Criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
The reason for the Basic Criterion is largely to ensure that people have a simple visual reminder that they are not using a stable release. I don't agree with the exact phrasing there.
Proposal 1: Basic Criterion: "The default visual experience of Fedora pre-releases must be sufficiently differentiated from stable releases so as to avoid easy confusion." We can then expand on that to use the current criterion as an example of how that may be accomplished (but it need not be the only way). [1]
The reason for the Final criterion is a fit-and-polish one. We want to ensure that the final product is as clean as we can make it. However, I don't think we necessarily should block the release just for the background.
Proposal 2: Final Criterion: "Fedora may not ship release-blocking desktops with visibly[2] unfinished artwork."
We would then add the following to the list of Automatic Freeze Exceptions[3] : "Changes that modify only the aesthetic of Fedora, such as the default wallpaper or window manager themes." This would allow us to get late fixes in for the wallpaper and similar artwork, but not require us to slip for it.
[1] I envision a world where we could theoretically have the "Background Logo" GNOME extension display a "pre-release" notation or something similar.
[2] Defining "visibly" as "an average user would consider it out of place, such as UI elements being completely missing".
Honestly, I don't really like...any of these. I kinda get the intent but they all feel icky, mushy and squishy. We give an automatic FE to *anything* that can be claimed to only modify "the aesthetic of Fedora"? That seems like a loophole big enough to drive a truck through. Proposal 2 seems very vague and suggests that if we accidentally put in artwork that's completely wrong or incredibly ugly, but not "unfinished", we're stuck with it...
I honestly think the main problem we have with this stuff is not the criteria. It's the process: the fact that the packages are kind of complex and involve a bunch of moving parts, and the fact that it seems like there's really only poor finalzone maintaining this stuff and he doesn't necessarily have the bandwidth to keep it all up to date promptly given how complicated it all is.
The criteria that currently exist were actually specifically written to enable a particular plan for improving the packages that we developed at one point, and which Kevin was going to work on in his copious spare time. Entirely inexplicably, given all those reams and reams of spare time he has, this hasn't happened yet. That's the real problem here. Re-arranging the release criteria deckchairs isn't going to help, I don't think. Fundamentally, the things the criteria is covering should not be *difficult* things, we just kind of suck at doing them.
On Wed, Apr 15, 2020 at 11:46 PM Adam Williamson adamwill@fedoraproject.org wrote:
Honestly, I don't really like...any of these. I kinda get the intent but they all feel icky, mushy and squishy.
It also feels too vague to me. Even our existing sentence "All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." is too vague and I can't *currently* say what it means exactly. And the proposed changes are even more vague. They seem to be driven by future-proofing, but I'd rather keep clearer criteria now and adjust them only when needed. (If I misunderstood the motivation, please provide a longer explanation). Are there any existing issues that triggered these proposals?
[1] I envision a world where we could theoretically have the
"Background Logo" GNOME extension display a "pre-release" notation or something similar.
So using the same background as the last stable release, but adding a "pre-release" watermark would be satisfactory for you? I'd find that utterly confusing. That looks like a criterion downgrade.
On Thu, 2020-04-16 at 13:23 +0200, Kamil Paral wrote:
On Wed, Apr 15, 2020 at 11:46 PM Adam Williamson adamwill@fedoraproject.org wrote:
Honestly, I don't really like...any of these. I kinda get the intent but they all feel icky, mushy and squishy.
It also feels too vague to me. Even our existing sentence "All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." is too vague and I can't *currently* say what it means exactly.
It kinda harks back to a time where we had more custom artwork, I think - like boot splashes and stuff? I don't totally remember, but that was basically it, at the time artwork was more than 'just' the desktop background. These days it's really pretty much that...
And the proposed changes are even more vague. They seem to be driven by future-proofing, but I'd rather keep clearer criteria now and adjust them only when needed. (If I misunderstood the motivation, please provide a longer explanation). Are there any existing issues that triggered these proposals?
[1] I envision a world where we could theoretically have the
"Background Logo" GNOME extension display a "pre-release" notation or something similar.
So using the same background as the last stable release, but adding a "pre-release" watermark would be satisfactory for you? I'd find that utterly confusing. That looks like a criterion downgrade.
yeah, I wasn't quite sure what the scenario was but if it's this I agree that seems awkward.
The approach the current criteria were intended to back was one where we would have something like rawhide-backgrounds or development- backgrounds which contained a background image that was very obviously a WORK IN PROGRESS kind of thing - picture of Beefy with "PRE RELEASE" written on it, or something like that - and this would be the *permanent* default background for Rawhide. 'Final' backgrounds would then be introduced for each release after it branched from Rawhide. This would have the happy side effect that if we didn't get around to doing anything by the Beta release, the Beta release would come out with the 'development' background, which we figured would be OK for a Beta, rather than with the same background as the previous release, which isn't.
Aside from that one, the other advantage of this approach is that it means you only have to do work in each release branch, you don't also have to keep changing things in Rawhide.
The approach the current criteria were intended to back was one where we would have something like rawhide-backgrounds or development- backgrounds which contained a background image that was very obviously a WORK IN PROGRESS kind of thing - picture of Beefy with "PRE RELEASE" written on it, or something like that - and this would be the *permanent* default background for Rawhide. 'Final' backgrounds would then be introduced for each release after it branched from Rawhide. This would have the happy side effect that if we didn't get around to doing anything by the Beta release, the Beta release would come out with the 'development' background, which we figured would be OK for a Beta, rather than with the same background as the previous release, which isn't.
Aside from that one, the other advantage of this approach is that it means you only have to do work in each release branch, you don't also have to keep changing things in Rawhide.
That sounds good to me. I always found it confusing to have the prior release background in the pre-release of the next version. Rawhide deserves its own background and as you say it will make it obvious that it's a pre-release version.
Stay Safe Stay Well
Pat (tablepc)
On Thu, Apr 16, 2020 at 08:18:27AM -0700, Adam Williamson wrote:
It kinda harks back to a time where we had more custom artwork, I think
- like boot splashes and stuff? I don't totally remember, but that was
basically it, at the time artwork was more than 'just' the desktop background. These days it's really pretty much that...
Yeah, boot splashes, and custom login theme.
I don't know if this has been mentioned (thread parachute drop wheee!) but the plan going forward for the wallpaper is to land the next release's background in Rawhide right after the branch -- so, a Fedora 34 wallpaper should land mid-August.
I love the idea of updating the logo extension to indicate Rawhide. It'd be nice for it also to indicate beta but I don't know how it could magically do that without without problematic gymnastics (or having it check something online, which has its own problems).
On Thu, Apr 16, 2020 at 12:25 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 16, 2020 at 08:18:27AM -0700, Adam Williamson wrote:
It kinda harks back to a time where we had more custom artwork, I think
- like boot splashes and stuff? I don't totally remember, but that was
basically it, at the time artwork was more than 'just' the desktop background. These days it's really pretty much that...
Yeah, boot splashes, and custom login theme.
I miss all those things...
I don't know if this has been mentioned (thread parachute drop wheee!) but the plan going forward for the wallpaper is to land the next release's background in Rawhide right after the branch -- so, a Fedora 34 wallpaper should land mid-August.
I love the idea of updating the logo extension to indicate Rawhide. It'd be nice for it also to indicate beta but I don't know how it could magically do that without without problematic gymnastics (or having it check something online, which has its own problems).
Well, you could check based on EVR of fedora-release. Stable release is always has Release field bumped to 1, and unstable is below 1.
On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote:
Well, you could check based on EVR of fedora-release. Stable release is always has Release field bumped to 1, and unstable is below 1.
True -- as long as people don't get the idea that this means that release candidates are final.
On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote:
Well, you could check based on EVR of fedora-release. Stable release is always has Release field bumped to 1, and unstable is below 1.
True -- as long as people don't get the idea that this means that release candidates are final.
Considering that we just upload a given RC as "Final" if the Go/No-Go decision goes in that RC's favor, I think that's fine.
On Thu, Apr 16, 2020 at 12:43 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote:
Well, you could check based on EVR of fedora-release. Stable release is always has Release field bumped to 1, and unstable is below 1.
True -- as long as people don't get the idea that this means that release candidates are final.
Considering that we just upload a given RC as "Final" if the Go/No-Go decision goes in that RC's favor, I think that's fine.
Presumably, this extension is going to need to be revised for the new logo sometime soon anyway; where should I file a feature request to have it also include the "prerelease" information?
If the extension can just include some text read from /usr/lib/os-release, that would be easiest, as we could then just have it display PRETTY_NAME and set up the fedora-release package to have PRETTY_NAME be "Fedora 32 (Workstation Edition Pre-release)" until RC (we change other things at that time anyway, such as disabling the -testing repos, so we can add this tweak to the process).
On Mon, Apr 20, 2020 at 10:26 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, Apr 16, 2020 at 12:43 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote:
Well, you could check based on EVR of fedora-release. Stable release is always has Release field bumped to 1, and unstable is below 1.
True -- as long as people don't get the idea that this means that release candidates are final.
Considering that we just upload a given RC as "Final" if the Go/No-Go decision goes in that RC's favor, I think that's fine.
Presumably, this extension is going to need to be revised for the new logo sometime soon anyway; where should I file a feature request to have it also include the "prerelease" information?
If the extension can just include some text read from /usr/lib/os-release, that would be easiest, as we could then just have it display PRETTY_NAME and set up the fedora-release package to have PRETTY_NAME be "Fedora 32 (Workstation Edition Pre-release)" until RC (we change other things at that time anyway, such as disabling the -testing repos, so we can add this tweak to the process).
FYI: https://src.fedoraproject.org/rpms/fedora-release/pull-request/122
The approach the current criteria were intended to back was one where we would have something like rawhide-backgrounds or development- backgrounds which contained a background image that was very obviously a WORK IN PROGRESS kind of thing - picture of Beefy with "PRE RELEASE" written on it, or something like that - and this would be the *permanent* default background for Rawhide. 'Final' backgrounds would then be introduced for each release after it branched from Rawhide. This would have the happy side effect that if we didn't get around to doing anything by the Beta release, the Beta release would come out with the 'development' background, which we figured would be OK for a Beta, rather than with the same background as the previous release, which isn't.
Yes, I would totally support this approach, because I find it the most logical one.
Alternatively, we could introduce the development version of the background in Rawhide, just when Beta is branched, so that it would be clear that there is something new going on. Beta would keep the Rawhide version until Final.
Example: Beta 32 => Wallpaper A and Rawhide 33 => Wallpaper B Beta 33 => Wallpaper B and Rawhide 34 => Wallpaper C
Another possibility, which is probably very difficult for the graphic team, however interesting: Rawhide: Early development version of the Wallpaper with the chosen motif - clearly visible that it has the draft quality Beta: Development version of the Wallpaper with the same motif, but much more precisely worked out. Final: Final version of Wallpaper with the same motif. The status of the Wallpaper would reflect the quality stages of Fedora.
Aside from that one, the other advantage of this approach is that it means you only have to do work in each release branch, you don't also have to keep changing things in Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
-
Adam Williamson -
Kamil Paral -
Lukas Ruzicka -
Matthew Miller -
Neal Gompa -
pmkellly＠frontier.com -
Stephen Gallagher