On Mon, 2025-05-26 at 17:46 +0200, Kamil Paral wrote:
> On Wed, May 21, 2025 at 9:34 AM Kamil Paral wrote:
>
> > Thanks everyone for your feedback. I'll wait a few more days and then
> > implement it.
> >
>
> Implemented now:
> https://fedoraproject.org/w/index.php?title=Fedora_43_Beta_Release_
On Wed, May 21, 2025 at 9:34 AM Kamil Paral wrote:
> Thanks everyone for your feedback. I'll wait a few more days and then
> implement it.
>
Implemented now:
https://fedoraproject.org/w/index.php?title=Fedora_43_Beta_Release_Criteria&diff=740088&oldid=740085
https://fedoraproject.org/w/index.php
On Tue, May 20, 2025 at 5:52 PM Adam Williamson
wrote:
> Another +1, this makes perfect sense.
>
Thanks everyone for your feedback. I'll wait a few more days and then
implement it.
> While we're on the topic, we should also consider bumping the netinst
> limit generally to 1.2G. Several netins
On Mon, 2025-05-19 at 15:13 +0200, Kamil Paral wrote:
> Hi,
> in the F42 cycle, we had a bug blocking Beta because one image was oversize
> [1], and realized [2] that it might be time to revisit this criterion [3].
> The criterion targets Beta historically, because with optical media, there
> was n
Agreed. Target final.
On Mon, May 19, 2025 at 6:13 AM Kamil Paral wrote:
> Hi,
> in the F42 cycle, we had a bug blocking Beta because one image was
> oversize [1], and realized [2] that it might be time to revisit this
> criterion [3]. The criterion targets Beta historically, because with
> opti
On 5/19/25 8:13 AM, Kamil Paral wrote:
Hi,
in the F42 cycle, we had a bug blocking Beta because one image was
oversize [1], and realized [2] that it might be time to revisit this
criterion [3]. The criterion targets Beta historically, because with
optical media, there was no way of using a "la
Kamil,
I agree. This is the right thing to do.
Pat - tablepc
On Mon, May 19, 2025 at 9:13 AM Kamil Paral wrote:
> Hi,
> in the F42 cycle, we had a bug blocking Beta because one image was
> oversize [1], and realized [2] that it might be time to revisit this
> criterion [3]. The criterion targe
On Tue, May 28, 2024 at 6:40 PM Kamil Paral wrote:
> On Tue, May 28, 2024 at 7:24 AM Sumantro Mukherjee
> wrote:
>
>> Hello Testers,
>>
>
> Hi Sumantro. Just a note, I'd send proposals to the test list only. (And
> even after it is decided, I don't think wiki categories are something that
> most
On Tue, May 28, 2024 at 7:24 AM Sumantro Mukherjee
wrote:
> Hello Testers,
>
Hi Sumantro. Just a note, I'd send proposals to the test list only. (And
even after it is decided, I don't think wiki categories are something that
most subscribers are that interested in ;-)).
> Fedora QA has been ho
I have removed everything, however, sometimes a "git revert" tends to cause
conflicts, but you are right, this should be fine with the files.
Lukas
On Wed, Jul 19, 2023 at 9:13 PM Adam Williamson
wrote:
> On Wed, 2023-07-19 at 13:37 +0200, Lukas Ruzicka wrote:
> > Ok, thanks for the confirmatio
On Wed, 2023-07-19 at 13:37 +0200, Lukas Ruzicka wrote:
> Ok, thanks for the confirmation.
> I will remove the modularity tests from the scheduling templates, but will
> keep the scripts in the repository in case, we want to start testing it any
> time soon. When modularity is fully retired, I will
Ok, thanks for the confirmation.
I will remove the modularity tests from the scheduling templates, but will
keep the scripts in the repository in case, we want to start testing it any
time soon. When modularity is fully retired, I will remove the scripts as
well.
Lukas
On Mon, Jul 17, 2023 at 5:2
On Mon, 2023-07-17 at 10:47 +0200, Kamil Paral wrote:
> On Mon, Jul 17, 2023 at 10:20 AM Lukas Ruzicka wrote:
>
> > Hello,
> >
> > based on this (
> > https://pagure.io/fedora-comps/c/38890fd54281a3dc2dd64439de8955637ca6f2a7?branch=main),
> > I am proposing to put the Modularity tests on hold fo
On Mon, Jul 17, 2023 at 10:20 AM Lukas Ruzicka wrote:
> Hello,
>
> based on this (
> https://pagure.io/fedora-comps/c/38890fd54281a3dc2dd64439de8955637ca6f2a7?branch=main),
> I am proposing to put the Modularity tests on hold for some time (modular
> features are currently not supported in DNF5 a
It seems to me that in going from single-day testing
to a multiday test season, one has produced a situation
in which the date specifies more than desired.
One possibility is to produce a page named in accordance
with what is being done, rather than when it is done.
Once the date has settled,
a pa
On Mon, 2023-03-06 at 19:33 +0100, Kamil Paral wrote:
>
> On Thu, Mar 2, 2023 at 6:00 PM Adam Williamson
> wrote:
>
> > The wikitcms parser relies on the -MM-DD part of the title,
> > so if we change this I would have to rewrite the parser to handle two
> > different types of test day page,
On Fri, Mar 3, 2023 at 2:28 AM Sumantro Mukherjee
wrote:
> So, I am thinking when the
> test day/week are over. How about then we add the date and pass it through
> the testdays CLI tool.
>
This would be a solution if we don't want to adjust our tooling. The wiki
pages can be created like "TestD
For the record, it was me who nudged Sumantro to send this proposal. It's
my understanding that having the date in the title discourages Sumantro (or
anyone handling it) from creating the wiki page too soon, before the page
is really settled. It makes sense, because any date change (and sometimes
t
On Fri, 2023-03-03 at 06:57 +0530, Sumantro Mukherjee wrote:
> Replying inline
>
>
> On Thu, Mar 2, 2023 at 10:30 PM Adam Williamson
> wrote:
>
> > On Thu, 2023-03-02 at 15:43 +, Ahmed Almeleh wrote:
> > > +1 for the new release + milestone suggestion and dropping the date on
> > test
> > >
Replying inline
On Thu, Mar 2, 2023 at 10:30 PM Adam Williamson
wrote:
> On Thu, 2023-03-02 at 15:43 +, Ahmed Almeleh wrote:
> > +1 for the new release + milestone suggestion and dropping the date on
> test
> > pages
> >
> > On Thu, 2 Mar 2023 at 15:13, Ben Cotton wrote:
> >
> > > I don't
On Thu, 2023-03-02 at 15:43 +, Ahmed Almeleh wrote:
> +1 for the new release + milestone suggestion and dropping the date on test
> pages
>
> On Thu, 2 Mar 2023 at 15:13, Ben Cotton wrote:
>
> > I don't see that including the date in the title adds much value,
> > particularly since it creat
+1 for the new release + milestone suggestion and dropping the date on test
pages
On Thu, 2 Mar 2023 at 15:13, Ben Cotton wrote:
> I don't see that including the date in the title adds much value,
> particularly since it creates the potential for confusion. Using the
> release (e.g. 'F38') or re
I don't see that including the date in the title adds much value,
particularly since it creates the potential for confusion. Using the
release (e.g. 'F38') or release+milestone when there are multiple in a
cycle (e.g. "F38beta") provides uniqueness in a way that's much easier
to manage.
I'm in fav
Have updated my Google Calendar accordingly
On Sat, Nov 19, 2022 at 3:24 AM Adam Williamson
wrote:
>
> On Fri, 2022-10-28 at 17:42 -0700, Adam Williamson wrote:
> > Hey folks!
> >
> > The more attentive among you may have noticed I've had a kinda
> > unofficial policy of holding the QA meetings e
Adam,
On 2022-11-19 13:23, Adam Williamson wrote:
On Fri, 2022-10-28 at 17:42 -0700, Adam Williamson wrote:
Hey folks!
The more attentive among you may have noticed I've had a kinda
unofficial policy of holding the QA meetings every other week for a
while. We just don't seem to have as much t
+1
I agree, we can always meet in between if there is need.
On Mon, Oct 31, 2022 at 8:50 PM Tim Flink wrote:
> +1
>
> I assume that additional meetings would be an option if the need presents
> itself, though.
>
> Tim
>
> On 10/31/22 07:38, Luna Jernberg wrote:
> > +1
> >
> > On Mon, Oct 31, 202
+1
I assume that additional meetings would be an option if the need presents
itself, though.
Tim
On 10/31/22 07:38, Luna Jernberg wrote:
+1
On Mon, Oct 31, 2022 at 11:24 AM Geraldo Simião Kutz
wrote:
+1 for te proposal.
geraldosimiao
Em seg, 31 de out de 2022 07:19, Kamil Paral escrev
+1
On Mon, 31 Oct 2022, 13:39 Luna Jernberg, wrote:
> +1
>
> On Mon, Oct 31, 2022 at 11:24 AM Geraldo Simião Kutz
> wrote:
> >
> > +1 for te proposal.
> >
> >
> > geraldosimiao
> >
> > Em seg, 31 de out de 2022 07:19, Kamil Paral
> escreveu:
> >>
> >> On Sat, Oct 29, 2022 at 2:49 AM Adam Willi
+1
On Mon, Oct 31, 2022 at 11:24 AM Geraldo Simião Kutz
wrote:
>
> +1 for te proposal.
>
>
> geraldosimiao
>
> Em seg, 31 de out de 2022 07:19, Kamil Paral escreveu:
>>
>> On Sat, Oct 29, 2022 at 2:49 AM Adam Williamson
>> wrote:
>>>
>>> Anyway, it seems a bit silly that we still notionally sc
+1 for te proposal.
geraldosimiao
Em seg, 31 de out de 2022 07:19, Kamil Paral escreveu:
> On Sat, Oct 29, 2022 at 2:49 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> Anyway, it seems a bit silly that we still notionally schedule a
>> meeting every week but I almost always canc
On Sat, Oct 29, 2022 at 2:49 AM Adam Williamson
wrote:
> Anyway, it seems a bit silly that we still notionally schedule a
> meeting every week but I almost always cancel half of them. So I'm
> proposing we make it official that we only meet every *other* week.
> This would save sending out cancel
On Fri, May 6, 2022 at 7:29 AM Matthias Clasen wrote:
>
> On Thu, May 5, 2022 at 1:23 PM Matthew Miller
> wrote:
>
> Wading into this discussion pretty late... there's far too much "GNOME does
> this" or "GNOME wants that" in this discussion.
>
> That is really not how it works, neither for GNO
On Thu, May 5, 2022 at 1:23 PM Matthew Miller
wrote:
Wading into this discussion pretty late... there's far too much "GNOME does
this" or "GNOME wants that" in this discussion.
That is really not how it works, neither for GNOME nor for Fedora - its
down to small teams and individual maintainers
On Wed, May 04, 2022 at 05:47:33PM -0700, Adam Williamson wrote:
> > So, um, maybe this is another place we could talk with GNOME upstream.
> > Could we have those upstream tests run on Rawhide?
> >
> > Also: where does GNOME _expect_ the human-based QA to happen? Especially
> > for the applicatio
On Wed, 2022-05-04 at 19:04 -0400, Matthew Miller wrote:
> On Tue, May 03, 2022 at 09:20:35PM -0700, Adam Williamson wrote:
> > We could look at what it would take to upstream the app tests we have
> > already for Fedora. What I'm afraid of is that we'd wind up finding
> > some subtle difference in
On Tue, May 03, 2022 at 09:20:35PM -0700, Adam Williamson wrote:
> We could look at what it would take to upstream the app tests we have
> already for Fedora. What I'm afraid of is that we'd wind up finding
> some subtle difference in theme or font rendering meant we'd have to
> duplicate all the n
On Tue, May 03, 2022 at 05:14:53PM -0700, Adam Williamson wrote:
> but these bugs weren't discovered at that time. This is likely because
> of your idea 2: "basic functionality" is a bit up for debate. You can
> take an extremely minimalist approach to this (run the app, click a
> couple of buttons
On Wed, May 04, 2022 at 02:46:16PM +0200, Kamil Paral wrote:
> > popularity and reviews noting how polished everything is makes us very much
> > want to build on that. So I understand why this is here, including the
> > expanded "all installed applications" Workstation criteria.
> As Adam already n
On Wed, 2022-05-04 at 10:27 +0100, Allan Day wrote:
> Adam Williamson wrote:
> ...
> > Do GNOME users actually use Contacts and Calendar and Photos? I mean,
> > I'm kind of a GNOME ultra, and I don't.
> ...
>
> One of the reasons we need metrics is so we can answer these questions
> using actual
On Wed, May 4, 2022 at 11:35 AM Allan Day wrote:
> That said, my own personal sense is that Calendar is used to some
> extent, and Contacts and Photos are used much less. That is somewhat
> reflected in the app reviews:
>
> Firefox - 7236 reviews, 3.4 average rating
> gedit - 896 reviews, 4.0 ave
On Wed, May 4, 2022 at 2:15 AM Adam Williamson
wrote:
> > 1. I know we have had GNOME Test days, but this
> >stuff didn't come up. Presumably, it would have if someone had
> happened
> >to look at GNOME Photos. Can we formally go through
> >https://www.fedoraproject.org/wiki/QA:Testca
On Wed, May 4, 2022 at 12:13 AM Matthew Miller
wrote:
>
> Time to talk about
>
> https://www.fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality
> again!
>
> Lots of desktop-app-related blockers this time around, and last time too. I
> think we're hitting a s
On Tue, 2022-05-03 at 19:37 -0500, Michael Catanzaro wrote:
> On Tue, May 3 2022 at 05:14:53 PM -0700, Adam Williamson
> wrote:
> > Stable releases of core components of a major desktop should never
> > contain bugs like "deleting contacts sometimes doesn't work" or "you
> > can't add photos to a
On Tue, 2022-05-03 at 18:13 -0400, Matthew Miller wrote:
> Time to talk about
> https://www.fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality
> again!
>
> Lots of desktop-app-related blockers this time around, and last time too. I
> think we're hitting a sym
On Mon, Mar 14, 2022 at 04:46:00PM -0700, Adam Williamson wrote:
> I feel pretty strongly the opposite on that one. Ben pre-empted me on
> IRC by already suggesting this approach (which I'm fine with), but
> before he had sketched out the specific approach, I was going to
> specifically suggest *NO
On Fri, 2022-03-11 at 13:50 -0500, Ben Cotton wrote:
> ## Proposal
>
> Modify the "Edition self-identification" criterion to explicitly give
> the Fedora Council the ability to waive the blocker status of bugs
> that violate this criterion. Specifically, append the following to
> https://fedorapro
On Tue, 2022-03-15 at 08:11 -0400, Ben Cotton wrote:
> On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller
> wrote:
> >
> > FESCo has a "make this a blocker" button... I kind of feel an itch for a
> > generalized "sometimes stuff comes up" lever that goes the _other_
> > direction, rather than a very
On Mon, Mar 14, 2022 at 5:33 PM Matthew Miller wrote:
>
> FESCo has a "make this a blocker" button... I kind of feel an itch for a
> generalized "sometimes stuff comes up" lever that goes the _other_
> direction, rather than a very specific carve-out.
Like Adam, I fear we'd be too tempted to use
On Mon, 2022-03-14 at 17:33 -0400, Matthew Miller wrote:
> On Fri, Mar 11, 2022 at 12:45:05PM -0800, Adam Williamson wrote:
> > I'm +1 to this; it makes sense for me that Council should be able to
> > veto/waive blocker decisions in this specific context, I just wanted
> > there to be a proper mech
On Fri, Mar 11, 2022 at 12:45:05PM -0800, Adam Williamson wrote:
> I'm +1 to this; it makes sense for me that Council should be able to
> veto/waive blocker decisions in this specific context, I just wanted
> there to be a proper mechanism for it. This seems like a reasonable way
> to achieve that.
On Fri, 2022-03-11 at 13:50 -0500, Ben Cotton wrote:
> ## Proposal
>
> Modify the "Edition self-identification" criterion to explicitly give
> the Fedora Council the ability to waive the blocker status of bugs
> that violate this criterion. Specifically, append the following to
> https://fedorapro
On Tue, 2022-02-15 at 13:32 +0100, Kamil Paral wrote:
> On Mon, Feb 7, 2022 at 9:35 PM Adam Williamson
> wrote:
>
> > For all release-blocking desktop / arch combinations, the following
> > applications must start successfully and withstand a basic
> > functionality test:
> >
> > * web browser
>
On Mon, Feb 7, 2022 at 9:35 PM Adam Williamson
wrote:
> For all release-blocking desktop / arch combinations, the following
> applications must start successfully and withstand a basic
> functionality test:
>
> * web browser
> * file manager
> * package manager
>
Now that I've pushed our new pac
On Mon, Feb 7, 2022 at 9:35 PM Adam Williamson
wrote:
> Yes, that's correct. To fix the first problem, and for clarity, here's
> a revised proposal for the entire text:
>
> ===
>
> For all release-blocking desktop / arch combinations, the following
> applications must start successfully and withs
On Fri, 2022-01-21 at 12:09 +0100, Kamil Paral wrote:
> >
> > Thoughts? Is this an improvement? Anyone have a better idea? Thanks!
> >
>
> Fine by me. I was considering just using some bold formatting in the
> original version, but this might be still a bit better.
>
> However, you dropped the
On Thu, Jan 20, 2022 at 7:10 PM Adam Williamson
wrote:
>
> Thoughts? Is this an improvement? Anyone have a better idea? Thanks!
This is a definite improvement. I agree with Kamil's comment about
including the "graphically" wording. It might be unnecessarily
pedantic, but our future selves may app
On 1/20/22 19:08, Adam Williamson wrote:
Hi folks! So I've had this action item at meetings forever now:
"adamw to try and clarify intent of "default application functionality"
criterion regarding arches"
For all release-blocking desktop / arch combinations, the following
applications mu
On Fri, Jan 21, 2022 at 1:11 AM Adam Williamson
wrote:
> Hi folks! So I've had this action item at meetings forever now:
>
> "adamw to try and clarify intent of "default application functionality"
> criterion regarding arches"
>
> That's referring to
>
> https://fedoraproject.org/wiki/Fedora_35_F
On Mon, Nov 29, 2021 at 06:29:37PM -, Marius Schwarz wrote:
> I suggest just to post Booting related Bugs on the Web and implement a
> "F.H.B." tool ( Frequently Hit Bugs )
> in the Distro.
>
> You may ask "Why?"
>
> If the system boots, but i.e. it's a network problem occurs, a local
> Bug
Hi,
I suggest just to post Booting related Bugs on the Web and implement a "F.H.B."
tool ( Frequently Hit Bugs )
in the Distro.
You may ask "Why?"
If the system boots, but i.e. it's a network problem occurs, a local
Bugs-and-theire-Solutions List would help to solve it fast.
How do we get
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
> * More laziness for me (not needing to do steps 1 or 2 of the list above)
Well, forget laziness. I made a script[1] that does these things. And a
bunch of other stuff, some of which is only partly done, but I think well
enough alon
On Sun, 2021-11-21 at 17:18 -0500, Matthew Miller wrote:
> On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
> > * As I understand the semantics now, "CommonBugs" keyword means "maybe
> > common bug?" and "CommonBugs + properly-formatted URL in the whiteboard
> > field" means "act
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
> * As I understand the semantics now, "CommonBugs" keyword means "maybe
> common bug?" and "CommonBugs + properly-formatted URL in the whiteboard
> field" means "actually common bug". Which is... kind of arcane. It seems
> like
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote:
> > 1. The new process needs to make sure that Bugzilla entries with CommonBugs
> >keyword are triaged in a timely manner.
> > 2. When proposed Common Issues* are accepted, the whiteboard field in
> >Bugzilla is updated.
> > 3
On Sat, Nov 13, 2021 at 07:41:53PM -0500, Matthew Miller wrote:
> I created a test topic to play aruond with what this would look like. Take a
> look:
>
> https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18243
>
> In most cases, I think the solution part will be concise e
> > As I'm reviewing some of the previous wiki pages now, I actually am kind of
> > inclined to think that it's better to have stronger problem/solution
> > separation. But I could be convinced either way.
>
> I feel a bit like wasting the reader's time to let them first read through
> a question,
On Thu, 2021-11-11 at 12:20 +0100, Kamil Paral wrote:
> >
> > > 3. Can we easily move a topic (or add a tag to it) into the Proposed
> > Common
> > > Issues category, when it is currently in a completely different one? And
> > > similarly, we can easily move out a topic from Proposed Common Issues
On Wed, Nov 10, 2021 at 1:04 AM Matthew Miller
wrote:
> I think the topic titles will be the same as with Common Bugs now, like
> "Configured repositories in Discover jump around in the list" or "Clipboard
> is not shared with KDE virtual machines".
>
> The site name, "Ask Fedora", makes me _want
On Tue, Nov 09, 2021 at 02:38:59PM +0100, Kamil Paral wrote:
> 1. In the Proposed Common Issues category, how are the topics intended to
> look like? Will the initial topic description be a question ("my sound is
> broken, how do I fix it?") and then somebody will provide a solution which
> will ge
On Thu, Nov 4, 2021 at 4:43 PM Matthew Miller
wrote:
> Specifics
> -
>
> We’d create a new top-level category, “Common Issues”. Posting directly
> in the category would not be allowed. Instead, there would be a
> *subcategory*, “Proposed Common Issues”.
>
> New topics in “Proposed Common
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote:
> That's more or less it, except that it doesn't cover how update-
> commonbugs helps a *lot* with points 5 and 6. Doing that manually is a
> drag.
Ack. I will restate with greater emphasis there.
> > Definitely have people _intere
On Sun, 2021-11-07 at 15:46 -0500, Matthew Miller wrote:
> On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote:
> > * Acknowledged and had a definite plan to replace the existing tooling
> > and practices at least at the same level as currently.
>
> Okay, cool. Can you help me better d
On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote:
> * Acknowledged and had a definite plan to replace the existing tooling
> and practices at least at the same level as currently.
Okay, cool. Can you help me better define the "at the same level" benchmark?
My stab at things that nee
On Sat, 2021-11-06 at 17:09 -0400, Matthew Miller wrote:
>
> Yes, absolutely. My goal is to make it better not worse, and overall less
> work shared among more people.
So instead of going point-by-point, I'll just say this would be fine,
but I'd feel rather better about it if the proposal:
* Ack
On Fri, Nov 05, 2021 at 05:35:03PM -0700, Adam Williamson wrote:
> > - The given solution works for most people, but clearly many are not
> > seeing it.
>
> I suspect this is more of a universal truth than something easily
> improvable. We could fly a plane above every town on Earth and some
On Fri, Nov 5, 2021 at 8:36 PM Adam Williamson
wrote:
>
> On Thu, 2021-11-04 at 11:43 -0400, Matthew Miller wrote:
> > Background
> > --
> >
> > Every release since possibly the dawn of time (or, at least, [Fedora
> > Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where
On Thu, 2021-11-04 at 11:43 -0400, Matthew Miller wrote:
> Background
> --
>
> Every release since possibly the dawn of time (or, at least, [Fedora
> Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where
> we document things that we judge not to be blockers but are concer
I am speaking for myself and not on Fedora QE's behalf, but I believe that
this might work. Maintaining one Common Bug page should not be a problem,
even if it is on another platform.
I also like the idea to make this the support and triage page of the first
instance, as we need to increase the co
Yes, that sounds fine. I wanted to point to a situation where the line
could be misleading to people who do not know about Nautilus having the
archiving function and who would keep looking for a standalone app.
Luk
On Tue, Sep 21, 2021 at 2:06 PM Kamil Paral wrote:
> On Tue, Sep 21, 2021 at 1:1
On Tue, Sep 21, 2021 at 1:10 AM Adam Williamson
wrote:
> Could we perhaps keep the
> line and add a footnote that specifies the "archive manager" role on
> Workstation is fulfilled by Nautilus/"Files"?
>
That sounds like a reasonable solution to me.
__
On Wed, 2021-09-15 at 08:36 +0200, Lukas Ruzicka wrote:
> Answers are here.
>
>
> > 1. Are we sure that dropping file-roller is intentional and not a bug in
> > comps? It might be worth checking with the Workstation SIG.
> >
>
> Yes, it is intentional.
>
> 2. By "removing" the test case, do yo
Answers are here.
> 1. Are we sure that dropping file-roller is intentional and not a bug in
> comps? It might be worth checking with the Workstation SIG.
>
Yes, it is intentional.
2. By "removing" the test case, do you mean the following, or something
> else?
> * graying out the Workstation ce
On Tue, Sep 14, 2021 at 6:09 PM Kamil Paral wrote:
> On Mon, Sep 13, 2021 at 2:55 PM Lukas Ruzicka wrote:
>
>> Hello,
>>
>> I am proposing to remove the $subj from the Desktop matrix (Workstation
>> related) cause the archive manager no longer is an installed application
>> and its functionality
Hi Kamil,
let me get the answer for question 1 at first.
Luk
On Tue, Sep 14, 2021 at 2:40 PM Kamil Paral wrote:
> On Mon, Sep 13, 2021 at 2:55 PM Lukas Ruzicka wrote:
>
>> Hello,
>>
>> I am proposing to remove the $subj from the Desktop matrix (Workstation
>> related) cause the archive manager
On Mon, Sep 13, 2021 at 2:55 PM Lukas Ruzicka wrote:
> Hello,
>
> I am proposing to remove the $subj from the Desktop matrix (Workstation
> related) cause the archive manager no longer is an installed application
> and its functionality has been taken by Nautilus, so it will be tested as
> part o
Sounds good to me
On Mon, Sep 13, 2021 at 2:55 PM Lukas Ruzicka wrote:
> Hello,
>
> I am proposing to remove the $subj from the Desktop matrix (Workstation
> related) cause the archive manager no longer is an installed application
> and its functionality has been taken by Nautilus, so it will be
Hello friends of Fedora,
the Dual Monitor Set-Up criterion is now *LIVE.*
For details, see
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Dual_Monitor_Set-Up
Lukas
On Mon, Apr 26, 2021 at 7:54 PM Chris Murphy
wrote:
> On Wed, Apr 21, 2021 at 2:27 AM Lukas Ruzicka wrote:
> >
On Wed, Apr 21, 2021 at 2:27 AM Lukas Ruzicka wrote:
>
> Hello friends of Fedora,
>
> please see the final version of the dual monitor criterion. This is the last
> chance for you to suggest anything you would like to see inside (or remove
> from it).
>
> "On computers using two monitors (e.g. t
On Wed, Apr 21, 2021 at 2:02 PM Lukas Ruzicka wrote:
> Hello friends of Fedora,
>
> please see the final version of the dual monitor criterion. This is the
> last chance for you to suggest anything you would like to see inside (or
> remove from it).
>
>
>
> *"On computers using two monitors (e.g.
On Wed, Apr 21, 2021 at 4:33 AM Lukas Ruzicka wrote:
> please see the final version of the dual monitor criterion. This is the
> last chance for you to suggest anything you would like to see inside (or
> remove from it).
>
>
>
> *"On computers using two monitors (e.g. two monitors on a desktop, o
LGTM too
On Wed, Apr 21, 2021 at 3:44 PM Geoffrey Marr wrote:
> LGTM! Good work Lukas.
>
> Geoff Marr
> IRC: coremodule
>
>
> On Wed, Apr 21, 2021 at 2:32 AM Lukas Ruzicka wrote:
>
>> Hello friends of Fedora,
>>
>> please see the final version of the dual monitor criterion. This is the
>> last
On Thu, Apr 22, 2021 at 2:32 AM Michel Alexandre Salim <
mic...@michel-slm.name> wrote:
> Do we need to explicitly mention that we do not expect different
> monitors to have the same scaling?
>
I wouldn't complicate it.
___
test mailing list -- test@lis
On Wed, Apr 21, 2021 at 10:32 AM Lukas Ruzicka wrote:
> Hello friends of Fedora,
>
> please see the final version of the dual monitor criterion. This is the
> last chance for you to suggest anything you would like to see inside (or
> remove from it).
>
>
> *"On computers using two monitors (e.g.
On Wed, 2021-04-21 at 10:26 +0200, Lukas Ruzicka wrote:
> Hello friends of Fedora,
>
> please see the final version of the dual monitor criterion. This is
> the last chance for you to suggest anything you would like to see
> inside (or remove from it).
>
> "On computers using two monitors (e.g. t
Works for me, nice and simple. Thanks!
On Wed, Apr 21, 2021 at 3:49 PM Geoffrey Marr wrote:
> LGTM! Good work Lukas.
>
> Geoff Marr
> IRC: coremodule
>
>
> On Wed, Apr 21, 2021 at 2:32 AM Lukas Ruzicka wrote:
>
>> Hello friends of Fedora,
>>
>> please see the final version of the dual monitor c
LGTM! Good work Lukas.
Geoff Marr
IRC: coremodule
On Wed, Apr 21, 2021 at 2:32 AM Lukas Ruzicka wrote:
> Hello friends of Fedora,
>
> please see the final version of the dual monitor criterion. This is the
> last chance for you to suggest anything you would like to see inside (or
> remove from
On Wed, Apr 14, 2021 at 7:42 PM Felix Miata wrote:
> Lukas Ruzicka composed on 2021-04-14 18:02 (UTC+0200):
>
> > *On computers with a possibility to connect an external monitor (e.g. two
> > monitors on a desktop and one external monitor on a laptop)...
>
> "Desktop" to me implies not server, no
Lukas Ruzicka composed on 2021-04-14 18:02 (UTC+0200):
> *On computers with a possibility to connect an external monitor (e.g. two
> monitors on a desktop and one external monitor on a laptop)...
>
"Desktop" to me imp
I like it!
Geoff Marr
IRC: coremodule
On Wed, Apr 14, 2021 at 10:09 AM Lukas Ruzicka wrote:
> Hello friends of Fedora,
>
> I would like to thank you for your reactions to the first draft of the
> dual monitor criterion. There were lots of remarks and suggestions, and I
> would like to present
On Thu, Apr 1, 2021 at 9:17 PM Ben Cotton wrote:
> On Tue, Mar 30, 2021 at 7:27 AM Lukas Ruzicka wrote:
> >
> > I would like to propose a new release covering criterion that was
> suggested on the yesterday's Blocker Review Meeting. Please let me know,
> what you think about it and perhaps sugge
1 - 100 of 604 matches
Mail list logo
