On 06/13/2018 07:56 PM, Carlos E. R. wrote:
On 2018-06-12 13:53, Stephan Kulow wrote:
On 06/12/2018 11:42 AM, martin(a)pluskal.org
That being said I would like to express my hope
that people interested
in manually testing Leap before release realize that last week before
release is a bit late (if you expect to have some impact on what is
released as iso).
I actually doubt seriously that any of the linked bugs slipped
Yes, some did.
Well, that's at least questionable for the examples you have provided. :-)
I tested a few betas as fresh installs in my laptop, and there was a
missing feature I needed: importing the existing partition layout (from
reading fstab). This lack made installing on existing computers more
cumbersome, as partitions have to be entered one by one manually. So I
used zypper dup instead.
"Needed" is a too strong word here. It's true that without the
Mount Point" button you have to manually select all the partitions you
want to reuse. Something like 10 extra clicks. So that button was a
convenience to save clicks, but its absence is far from being a stopper
for testing the installer (that's why it was not implemented at the
This feature was added late in the process, I
didn't notice when, with
the result that I did not test it.
We can agree then, this is again about late testing and not about the
bugs being introduced late.
Well, two serious bugs crept in late and I failed to
discover them :-(
a) YaST crashes if there are encrypted partitions listed in fstab
If I'm not mistaken, this bug didn't slip in the last moment. It was
probably there since the very beginning (by the way, it may be that your
description makes it sound more severe than it was).
b) YaST can select ALL existing partitions for
/home and other data partitions, with the result of data destruction.
b2) sometimes it formats none, which is also catastrophic.
I don't think (b2) is true. The partitioner in Leap 15.0 always formats
ALL reused mount points.
In previous versions there was an extra checkbox labeled "Format System
Volumes" to control all that. The exact behavior depending on the
concrete partition and the value of that checkbox turned out to be
(true, it is a proposal, but in previous versions the
logic was better)
Better in some situations. And always complex. So it was a conscious
decision to bring back the functionality in its simpler form (without
the checkbox and always formatting everything in a consistent way) as
starting point. Specially since, as you have mentioned, it's only a
proposal done by an specific button inside the Expert Partitioner.
So, as much as you can disagree with the intention of simplifying the
functionality or with the way in which it was done. It's not a bug that
failed to be detected. It works as expected by the developer. It's more
a mismatch in expectations.
Also, it seems the automated testing failed to detect
these two problems.
This is true for the first problem (which didn't slip in late, which is
the main discussion topic here).
The second one was indeed automatically tested... to behave as it does,
even if it doesn't match your expectations.
Conclusion: none of your examples count to me as bugs introduced late in
the process (not even both of them count as bug, if you ask me). ;-)
Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org