Re: Proposal to adjust final criterion for backgrounds

[Lukas Ruzicka]

>
> 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-le...@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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Stephen Gallagher]

On Mon, Apr 20, 2020 at 10:26 AM Stephen Gallagher  wrote:
>
> On Thu, Apr 16, 2020 at 12:43 PM Neal Gompa  wrote:
> >
> > On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller
> >  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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Stephen Gallagher]

On Thu, Apr 16, 2020 at 12:43 PM Neal Gompa  wrote:
>
> On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller
>  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).
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Neal Gompa]

On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller
 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Neal Gompa]

On Thu, Apr 16, 2020 at 12:25 PM Matthew Miller
 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Matthew Miller]

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).



-- 
Matthew Miller

Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[pmkel...@frontier.com]

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)
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Adam Williamson]

On Thu, 2020-04-16 at 13:23 +0200, Kamil Paral wrote:
> On Wed, Apr 15, 2020 at 11:46 PM Adam Williamson 
> 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.
-- 
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-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Kamil Paral]

On Wed, Apr 15, 2020 at 11:46 PM Adam Williamson 
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.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to adjust final criterion for backgrounds

[Adam Williamson]

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.
-- 
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-le...@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

Proposal to adjust final criterion for backgrounds

[Stephen Gallagher]

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_freeze_exceptions
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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