On Thu, Feb 17, 2022 at 10:57 AM Lukas Ruzicka wrote:
>
>> Thanks Kamil! So the next step would be to draft test cases for the
>> additional blocking functionality. Do we have a plan for that?
>>
>
> I can suggest something as I would like to convert it into OpenQA later, so
> I might hit two tar
> Thanks Kamil! So the next step would be to draft test cases for the
> additional blocking functionality. Do we have a plan for that?
>
I can suggest something as I would like to convert it into OpenQA later, so
I might hit two targets with one arrow.
Luk
> --
> Adam Williamson
> Fedora QA
>
On Tue, 2022-02-15 at 13:25 +0100, Kamil Paral wrote:
> On Tue, Feb 8, 2022 at 9:48 AM Kamil Paral wrote:
>
> > OK. I sent out the complete criterion proposal to Workstation and KDE
> > lists:
> >
> > https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/L3QVPHBPHL
On Tue, Feb 8, 2022 at 9:48 AM Kamil Paral wrote:
> OK. I sent out the complete criterion proposal to Workstation and KDE
> lists:
>
> https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/L3QVPHBPHLBT4O2IXHOE5ILCQX4EXXWJ/
>
> https://lists.fedoraproject.org/archive
On Mon, Feb 7, 2022 at 9:05 PM Adam Williamson
wrote:
> That sounds fine to me. Lukas' is shorter, but yours to me is clearer
> about the purpose of the note, so I like it more. Thanks!
>
OK. I sent out the complete criterion proposal to Workstation and KDE lists:
https://lists.fedoraproject.org
On Tue, 2022-01-25 at 11:02 +0100, Kamil Paral wrote:
>
> OK, so what about adding a note like this:
>
> Note: Systems in an inconsistent state
> While the package manager must not be the primary cause for breaking a
> system (unbootable, invalid internal structures, etc), it doesn't have to
> ''
The criteria looks good to me, but I agree that it might be a double edged
sword to say that *The package manager must never make the system enter an
inconsistent or unbootable state* as suggested. An explanatory note is also
a good thing to have. However I am not convinced that the wording needs t
On Tue, Jan 25, 2022 at 3:00 PM John Mellor wrote:
> I'm ok with that or something similar, but it does point out the need to
> fill a large gap in keeping the machine sane when something unexpected
> happens. Perhaps F36 can expedite btrfs gui and cli tools to roll back to
> the last known sane
On 2022-01-25 05:02, Kamil Paral wrote:
On Mon, Jan 24, 2022 at 6:19 PM Adam Williamson
wrote:
On Mon, 2022-01-24 at 15:28 +0100, Kamil Paral wrote:
> If this is about power outages, I don't see any problem here. A
power
> outage is not the package manager's failure, and so tho
On Mon, Jan 24, 2022 at 6:19 PM Adam Williamson
wrote:
> On Mon, 2022-01-24 at 15:28 +0100, Kamil Paral wrote:
> > If this is about power outages, I don't see any problem here. A power
> > outage is not the package manager's failure, and so those criteria don't
> > apply.
>
> I can see someone pr
On Mon, 2022-01-24 at 15:28 +0100, Kamil Paral wrote:
> On Sat, Jan 22, 2022 at 12:36 AM Adam Williamson
> wrote:
>
> > On Fri, 2022-01-21 at 18:20 -0500, John Mellor wrote:
> > >
> > > Ok, so would that allowance not violate 2 of the proposed criteria:
> > >
> > > 1. * The displayed state of
On Sat, Jan 22, 2022 at 12:36 AM Adam Williamson
wrote:
> On Fri, 2022-01-21 at 18:20 -0500, John Mellor wrote:
> >
> > Ok, so would that allowance not violate 2 of the proposed criteria:
> >
> > 1. * The displayed state of software or software sources must not
> > differ from their actual s
On Thu, Jan 20, 2022 at 10:26 PM Kamil Paral wrote:
> This is another attempt at creating a new release criterion specific for
> graphical package managers. We already discussed it in November, but we
> couldn't agree easily on some particular details, and then I was gone for a
> long time:
>
> h
On Fri, Jan 21, 2022 at 3:54 PM Adam Williamson
wrote:
>
> The release criteria aren't design documents. We're not defining the
> intended behavior, exactly; we're defining a certain subset of known
> expected behavior which we require to *work*.
>
> The situations you describe are, essentially, "
On Fri, 2022-01-21 at 18:20 -0500, John Mellor wrote:
>
> Ok, so would that allowance not violate 2 of the proposed criteria:
>
> 1. * The displayed state of software or software sources must not
> differ from their actual state. (E.g. an RPM package must not be
> shown as installed when
On Thu, 2022-01-20 at 14:17 -0500, John Mellor wrote:
> The suggested criteria list is pretty generic, and offhand I can't think
> of a current GUI or CLI installer that does not conform to these
> requirements.
Just before Fedora 35 was released, the KDE package manager did not
conform to sever
On 2022-01-21 5:54 p.m., Adam Williamson wrote:
On Fri, 2022-01-21 at 14:20 -0500, John Mellor wrote:
I am unclear from this proposal on what is supposed to happen if a
package is not completely installed. E.g: a powerdown or other outage
causes the post-install script in an installed rpm to n
On Thu, 2022-01-20 at 17:54 +0100, Kamil Paral wrote:
> This is another attempt at creating a new release criterion specific for
> graphical package managers. We already discussed it in November, but we
> couldn't agree easily on some particular details, and then I was gone for a
> long time:
> htt
On Fri, 2022-01-21 at 14:20 -0500, John Mellor wrote:
> >
> I am unclear from this proposal on what is supposed to happen if a
> package is not completely installed. E.g: a powerdown or other outage
> causes the post-install script in an installed rpm to not be run. A few
> packages like the
On 2022-01-20 11:54 a.m., Kamil Paral wrote:
This is another attempt at creating a new release criterion specific
for graphical package managers. We already discussed it in November,
but we couldn't agree easily on some particular details, and then I
was gone for a long time:
https://lists.fed
Great work, Kamil. I think this addresses most of the concerns. And
while I still don't love the idea of including concurrent actions, the
argument is good enough that I'll live with it. I have some pedantic
arguments about one of the things that must hold true, but that's
something to discuss soci
On Thu, Jan 20, 2022 at 12:18 PM John Mellor wrote:
> I've done generic, app-specific and custom installers and lots of
> install environments on a lot of architectures for about 45 years of my
> 50 years working as a mission-critical developer and maintainer. There
> a lots of people who do not
On 2022-01-20 11:54 a.m., Kamil Paral wrote:
This is another attempt at creating a new release criterion specific
for graphical package managers. We already discussed it in November,
but we couldn't agree easily on some particular details, and then I
was gone for a long time:
https://lists.fed
On Thu, Jan 20, 2022 at 9:55 AM Kamil Paral wrote:
>
> This is another attempt at creating a new release criterion specific for
> graphical package managers. We already discussed it in November, but we
> couldn't agree easily on some particular details, and then I was gone for a
> long time:
>
This is another attempt at creating a new release criterion specific for
graphical package managers. We already discussed it in November, but we
couldn't agree easily on some particular details, and then I was gone for a
long time:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproj
Scenario 1:This is not stated to be a bug, but I think most people, including
me, would see it as a bug. That said this makes a bad impression on the user;
especially a new user. I don't believe this is a blocker, but should be a
Freeze Exception bug and a Priority bug.
Scenario 2: Same as Scen
My personal preference is *works decently* of course. My old self keeps
calling from the history of times something like "I have told you that
Linux kicks ass and Windows kick balls."
On Thu, Nov 11, 2021 at 5:07 PM Kamil Paral wrote:
> On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka
> wrote:
On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka wrote:
> I assume we are talking about a GUI software manager and not DNF.
>
Yes.
> I also assume that we want to deliver a user friendly package manager that
> is a pleasure to work with.
> On that assumption:
>
> *Scenario 1: Blocking*. You do n
I assume we are talking about a GUI software manager and not DNF.
I also assume that we want to deliver a user friendly package manager that
is a pleasure to work with.
On that assumption:
*Scenario 1: Blocking*. You do not want to restart an application any time
you want to start doing another op
On Wed, Nov 10, 2021 at 2:02 PM Chris Murphy wrote:
>
> My take, all except 6 are blocking.
Ooh I like this game where I don't read all the posts, and end up
agreeing with Kamil having not seen the answers first.
--
Chris Murphy
___
test mailing list
On Wed, Nov 10, 2021 at 11:50 AM Kamil Paral wrote:
>
> On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton wrote:
>>
>> So I still disagree with you, but my position is softening. I'd rather
>> we have a clearly-defined and understood set of criteria that I
>> disagree with in some places than to try to m
On Wed, Nov 10, 2021 at 5:49 PM Kamil Paral wrote:
> Hmm, let's try something different first. I'll provide a list of scenarios
> below, and I'd like everyone participating in this discussion to respond
> whether they think that scenario should be blocking or non-blocking (for
> Final), and ideal
On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton wrote:
> So I still disagree with you, but my position is softening. I'd rather
> we have a clearly-defined and understood set of criteria that I
> disagree with in some places than to try to make every criterion match
> my preferences. :-) So while I dis
On Mon, Nov 8, 2021 at 8:37 AM Kamil Paral wrote:
>
> I find it hard to draw the line somewhere between all these cases. So
> aborting a previous operation is not ok, but not even starting a second
> operation is ok? Installing and removing the same package is not blocking?
> What about install
On Tue, Nov 9, 2021 at 4:47 AM Chris Murphy wrote:
> When installing, removing, or updating software? If I click an install
> button, the selected app should be installed or it's a blocking bug.
> Same for removal, same for updating. If it lets you click install for
> multiple programs in sequenc
On Mon, Nov 8, 2021 at 11:39 AM Kamil Paral wrote:
>
> On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy wrote:
>>
>> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality
>>
>> "Basic functionality means that the app must at least be broadly
>> capable of it
On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy wrote:
>
> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality
>
> "Basic functionality means that the app must at least be broadly
> capable of its most basic expected operations, and that it must not
> cra
On Mon, Nov 8, 2021 at 3:26 PM Frantisek Zatloukal
wrote:
>
>
>> "dnf install foo; dnf install bar"
>>
>
> This is equivalent to:
>
> 1. Open Graphical package manager
> 2. Install foo
> 3. Close Graphical package manager
> 4. Open Graphical package manager
> 5. Install bar
> 6. Close Graphical p
On Mon, Nov 8, 2021 at 10:50 AM John Mellor wrote:
>
> On 2021-11-08 9:31 a.m., Neal Gompa wrote:
> > On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal
> > wrote:
> >> On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote:
> >>> "dnf install foo bar"
> >> This is a single operation, comparable to h
On 2021-11-08 9:31 a.m., Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal wrote:
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote:
"dnf install foo bar"
This is a single operation, comparable to having multiple packages installed
via graphical package manager, not schedu
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality
"Basic functionality means that the app must at least be broadly
capable of its most basic expected operations, and that it must not
crash without user intervention or with only basic user interventio
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal wrote:
>
>
>
> On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote:
>>
>> "dnf install foo bar"
>
>
> This is a single operation, comparable to having multiple packages installed
> via graphical package manager, not scheduling multiple operations a
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote:
> "dnf install foo bar"
>
This is a single operation, comparable to having multiple packages
installed via graphical package manager, not scheduling multiple operations
at once. It would be the same If a graphical package manager offered to
selec
On Thu, Nov 4, 2021 at 3:02 PM Frantisek Zatloukal
wrote:
> On Thu, Nov 4, 2021, 11:40 Kamil Paral wrote:
>
>> I'm not sure if you understood it correctly (or if I even expressed it
>> correctly). The operations are of course executed sequentially, always
>> (that's how our package managers work
On Thu, Nov 4, 2021 at 2:19 PM Ben Cotton wrote:
> On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral wrote:
> >
> > "Multiple operations" is one of the reasons for proposing this
> criterion. In this release, and previous releases, we often had a bug that
> you can install a package, but then you can't
On Thu, Nov 4, 2021, 11:40 Kamil Paral wrote:
> I'm not sure if you understood it correctly (or if I even expressed it
> correctly). The operations are of course executed sequentially, always
> (that's how our package managers work). But they can be *scheduled*
> concurrently, i.e. you can instal
On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral wrote:
>
> "Multiple operations" is one of the reasons for proposing this criterion. In
> this release, and previous releases, we often had a bug that you can install
> a package, but then you can't remove it. But if you restarted the package
> manager
On Wed, Nov 3, 2021 at 5:15 PM Frantisek Zatloukal
wrote:
> On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral wrote:
>
>> ~~
>> The default graphical package manager for a given software type must
>> appropriately:
>> * install, remove and update software, even if multiple operations are
>> sc
On Wed, Nov 3, 2021 at 4:02 PM Ben Cotton wrote:
> On Wed, Nov 3, 2021 at 7:32 AM Kamil Paral wrote:
> >
> > * install, remove and update software, even if multiple operations are
> scheduled sequentially or concurrently
>
> I don't like the "multiple operations" part but to be honest I'm not
>
On Wed, Nov 3, 2021 at 3:48 PM Brandon Nielsen wrote:
> On 11/3/21 6:31 AM, Kamil Paral wrote:
>
> During the F35 release cycle, there was a dissatisfaction that we use the
> "basic functionality" criterion [1] too broadly when discussing package
> manager issues (like multiple issues in plasma-d
On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral wrote:
> ~~
> The default graphical package manager for a given software type must
> appropriately:
> * install, remove and update software, even if multiple operations are
> scheduled sequentially or concurrently
>
I am definitely against bloc
On Wed, Nov 3, 2021 at 7:32 AM Kamil Paral wrote:
>
> * install, remove and update software, even if multiple operations are
> scheduled sequentially or concurrently
I don't like the "multiple operations" part but to be honest I'm not
sure if that's because I worry about how many delays it will
On 11/3/21 6:31 AM, Kamil Paral wrote:
During the F35 release cycle, there was a dissatisfaction that we use
the "basic functionality" criterion [1] too broadly when discussing
package manager issues (like multiple issues in plasma-discover). I
was asked in the latest QA meeting to propose a sp
During the F35 release cycle, there was a dissatisfaction that we use the
"basic functionality" criterion [1] too broadly when discussing package
manager issues (like multiple issues in plasma-discover). I was asked in
the latest QA meeting to propose a specific criterion to cover package
managers
54 matches
Mail list logo
