Am 15.11.2021 um 03:21 schrieb Chris Murphy
<lists(a)colorremedies.com>:
How is the nano problem related to issue #32? The nano problem
happened just for Fedora 35. Issue 32 is about a 9 month old problem.
I think if you're even more careful about it, you're at risk of the
problem continuing for another 9 months. My opinion is that escalation
is needed.
OK, I try to explain it again and I hope I succeed better than the various times before.
You wrote: "The nano problem happened just for Fedora 35. Issue 32 is about a 9 month
old..“
The „nano problem“ was *detected* some weeks ago and long after issue #32. That says
nothing about when it *happend* and it says nothing about the technical reason, *why* it
happened. It was discovered by chance, not by systematic, theory-based testing. Overall,
the timing is simply "spurious information" from a scientific point of view.
We know from #32 that we have a systematic, technically based issue. Our net-install and
dvd-install deliveries result in non-identical OS Installations. And we know the
systematic technical reason for that, it is a different handling of "recommended
packages“. This did result in a faulty cockpit installation.
As you found out yourself, nano installs correctly with net-install, but not with
dvd-install. The known difference between both is that different handling of
„recommended“.
A systematic, theory-based (or engineering based - I hope engineering is the right term
for German ingenieurwissenschaftlich), a engineering based search for the cause of the
error would start with this difference as the first hypothesis. Accordingly, the
"nano problem" would simply be another incarnation of the same technical cause
as the "cockpit problem“, although not discovered until later.
Kindly, Zdenek Dohnal provided a detailed reconstruction of the technical processes that
strongly supported this hypothesis and proved it to be highly probable „true"
(verification is logically impossible from a scientific-theoretical point of view).
For this reason, a systematic-scientific i.e. engineering-led correction starts at exactly
this point. At the same time, this opens up the lowest probability of side effects and so
does not reduce the quality of the product.
For the same reason, Matthew's intervention is simply „mindless", since it
intervenes at a more or less random point without consideration of the overall technical
design. From a systematic point of view, this entails a high risk of degraded quality of
the product, i.d. Fedora Server Edition.
And again for the same reason, contrary to Matthew's action Stephen Gallaghers last
minute quick fix of the Cockpit issue was „mindful“ as hi knows the engineering details
and was able to intervene precisely at a specific point.
And again for the same reasoning, it is mindless to simply shuffle in one quick fix after
another, accepting that at any time another error will be discovered (not occur, that is
done beforehand) due to the same cause. This is also a process of degrading quality.
You wrote "My opinion is that escalation is needed“ of the nano issue.
We don’t need escalation. We need to work as planned. Basically we trusted a person to get
things done who faded away silently when it got more complicated and elaborate.
I hope it helps.
Best
Peter