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@pluskal.org wrote:
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 in late.
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 "Import 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 beginning).
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 formatting, including /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 complicated.
(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). ;-) Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org