[opensuse-project] distribution release timing
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0. Does anyone have any recollection if this is a typical result of a new release? It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On lundi, 11 juin 2018 20.44:13 h CEST Felix Miata wrote:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event.
The last 10 or 15 days before the release we go GA and so what's inside the distribution at that time it was you get on release day (minus correction that have gone to update channel in the meantime) Better advertising the Beta, RC phase would normally help to detect a part of those bugs. We need people for that job too. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2018-06-11 21:00, Bruno Friedmann wrote:
On lundi, 11 juin 2018 20.44:13 h CEST Felix Miata wrote:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event.
The last 10 or 15 days before the release we go GA and so what's inside the distribution at that time it was you get on release day (minus correction that have gone to update channel in the meantime)
Better advertising the Beta, RC phase would normally help to detect a part of those bugs. We need people for that job too.
I hit three bugs in the Gold that were not present on the Betas I tried. One that destroys data and another that blocks the upgrade. 1) systemd crashes sometimes during zypper dup, which then continues with very long timeouts taking several hours to finish 2) Fresh install import of existing partition uses wrong logic to decide what to format. It can decide to format all, including /home, which can be *terrible*. 4) Yast refuses to upgrade if there are reiserfs partitions that are not relevant to the system - in my case, old installs in the same computer. 5) YaST crashed during the upgrade, telling to report in bugzilla. Even if this is corrected, it is no use this year. 3) YaST crashed on me during -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.0 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 11 June 2018 at 20:44, Felix Miata <mrmazda@earthlink.net> wrote:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event.
Did were any of those cited bugs found by people at or involved in the organisation of the openSUSE Conferences? - looking at the cited examples it's easy to say No, none of those people were at the conference. Was Leap 15 in a Beta/RC phase for FOUR WHOLE MONTHS? - Yes Therefore Do I find your suggestion that those bugs should have been found by people at oSC insulting to the hundreds of volunteers who went to oSC? - Yes. Do I find your suggestion that those bugs should have been found by people at oSC insulting to the thousands of volunteers who were NOT at oSC? - Yes Both groups were working very hard to make Leap 15 as much of a success as it has been. I think you owe them all an apology as a result of your 'wondering'. I'm open to the discussion that the Project has a problem with an uptick of bugs after the release. This wouldn't be the first time, I consider it usual, and I find it unfortunate. But I would say that the question that needs to be asked is not whether or not our project's annual gathering is a factor, but why are more people testing Leap 15 now after the release than during the MONTHS of testing? I also would love the answer to the question of why do people like you feel empowered to write mails like this posing such questions to the Project, when you yourself haven't found or reported any such bugs. This entire post smells like an attempt to stir shit for your own self aggrandisement for no real benefit to the project. If you want to be an active aid in ensuring we have better releases in the future - please try and improve your quality of bug reports so they're about important things than the print screen key [1] or your unsupportable reuse of filesystems [2] Please try to commentate less and _do_ more. I would greatly appreciate that. [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1087537 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1081653 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
oh and top-posting because I forgot to mention Leap 15 was gold (finished, frozen, and unable to be changed) for a WEEK before it's release Just like every other year - because it takes that long to get the mirrors, press, etc, all sorted. So really, again, the suggestion that oSC had anything to do with any bugs being found after it's release are nonsense If people want to help make Leap 15.1 better, there is one option, test it more before the release. Not the week before, but from the moment we start those Betas and doubly so when we reach that RC Phase That's what we do them for. Waiting for the last week or after the release is never going to be good enough, and anyone who did that should take their share of any collective blame for any and all bugs that slipped by. On 11 June 2018 at 21:25, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 11 June 2018 at 20:44, Felix Miata <mrmazda@earthlink.net> wrote:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event.
Did were any of those cited bugs found by people at or involved in the organisation of the openSUSE Conferences? - looking at the cited examples it's easy to say No, none of those people were at the conference.
Was Leap 15 in a Beta/RC phase for FOUR WHOLE MONTHS? - Yes
Therefore Do I find your suggestion that those bugs should have been found by people at oSC insulting to the hundreds of volunteers who went to oSC? - Yes. Do I find your suggestion that those bugs should have been found by people at oSC insulting to the thousands of volunteers who were NOT at oSC? - Yes Both groups were working very hard to make Leap 15 as much of a success as it has been.
I think you owe them all an apology as a result of your 'wondering'.
I'm open to the discussion that the Project has a problem with an uptick of bugs after the release. This wouldn't be the first time, I consider it usual, and I find it unfortunate. But I would say that the question that needs to be asked is not whether or not our project's annual gathering is a factor, but why are more people testing Leap 15 now after the release than during the MONTHS of testing?
I also would love the answer to the question of why do people like you feel empowered to write mails like this posing such questions to the Project, when you yourself haven't found or reported any such bugs. This entire post smells like an attempt to stir shit for your own self aggrandisement for no real benefit to the project.
If you want to be an active aid in ensuring we have better releases in the future - please try and improve your quality of bug reports so they're about important things than the print screen key [1] or your unsupportable reuse of filesystems [2]
Please try to commentate less and _do_ more. I would greatly appreciate that.
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1087537 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1081653 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 06/11/2018 12:25 PM, Richard Brown wrote:
Was Leap 15 in a Beta/RC phase for FOUR WHOLE MONTHS? - Yes
I'm open to the discussion that the Project has a problem with an uptick of bugs after the release. This wouldn't be the first time, I consider it usual, and I find it unfortunate. But I would say that the question that needs to be asked is not whether or not our project's annual gathering is a factor, but why are more people testing Leap 15 now after the release than during the MONTHS of testing?
In my case, the odd thing is that I tested 15.0 for months in the Beta stage, ran into absolutely NO problems. I tried various things -- the zypper dup upgrading, and occasionally downloading the latest Beta and installing it to make sure a fresh install would work properly, as well as installing it using the "Upgrade System" (or similar) menu option, to see if I could run into a bug that would fix it. My mistake? I should have been trying it in test partitions on my other Machines. When 15.0 was released, I suddenly ran into a flurry of problems installing on at least two of the other machines. I am currently holding those exercises until I have time to explore them and either join or create a Bug report where I can provide some perhaps useful information to help with the solution. In the meantime, I was able to get those other machines up and running in 15.0 with some stumbling around (with duct tape and haywire?). Shocked me, because I had somehow managed to slip past those important bugs unscathed all during the Beta testing. I will be creating test partitions on those other machines and will explore the issue further so I can contribute. But, when I get a chance. Meantime, I hope others who run into such problems report them in appropriate Bugs, rather than just whine about them. These things do happen in Tech. As you said, perhaps if a lot more were testing on a lot more machines? In my testing, I was convinced that 15.0 was the Most Rock Solid Release of All Time! Oh, Well. Still a job Very Well Done by all involved in the Development Process ... and I am NOT going to be Humble in my Opinion on this. -- -Gerry Makaro openSUSE Member openSUSE Forum Moderator openSUSE Contributor aka Fraser_Bell on the Forums, OBS, IRC, and mail at openSUSE.org Fraser-Bell on Github -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Op maandag 11 juni 2018 20:44:13 CEST schreef Felix Miata:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
Did you count the # of downloads as well? Checked the validity of all these bugreports?
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event.
Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2018-06-11 21:46, Knurpht @ openSUSE wrote:
Op maandag 11 juni 2018 20:44:13 CEST schreef Felix Miata:
It bugs me to see reports like https://bugzilla.opensuse.org/show_bug.cgi?id=1096913 https://bugzilla.opensuse.org/show_bug.cgi?id=1096971 https://bugzilla.opensuse.org/show_bug.cgi?id=1096960 so soon after a new release. In the past two weeks there have been 20 new Distribution reports on Installation, 7 on Upgrade Problems, 9 on YaST2, 7 on Network, 2 on Bootloader, 13 on Basesystem, and 186 on simply Distribution, of which explicitly 15.0.
Does anyone have any recollection if this is a typical result of a new release?
Did you count the # of downloads as well? Checked the validity of all these bugreports?
I did, some of them are mine. I have dedicated entire days to investigate bugs this last week.
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event. Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there.
Felix is not blaming the conference or the people there, but wonders if the release was hurried and last minute bugs creeped in, not found till too late. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.0 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
El 2018-06-11 22:30, Carlos E. R. escribió:
It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event. Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there.
Felix is not blaming the conference or the people there, but wonders if the release was hurried and last minute bugs creeped in, not found till too late.
Felix have a good and interesting point about bugs slipping it, the testing and the timing. And all that probably deserves a wider discussion. That being said, Felix IS indeed blaming the conference. If not, he expressed it VERY wrong, the sentence you quoted looks very explicit about the blame: "It makes me wonder if releases should better be timed to _not_ coincide with social gatherings as happened with 15.0, so that last weeks' testing time isn't disrupted by plans and preparations for a social event." If that is not drawing a direct relationship between the existence of severe bugs in Leap 15.0 and openSUSE Conference 2018, I don't know what is. Cheers. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
isn't disrupted by plans and preparations for a social event.
Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there. Indeed it is ridiculous - I wonder what put Felix into position to pass such judgements, not only about release but also about conference - it is far from "social gathering". If Felix was involved either with
On Mon, 2018-06-11 at 21:46 +0200, Knurpht @ openSUSE wrote: planning of conference or with releasing Leap he would know that there is actually very little overlap between people involved in each, therefore there is no risk of one influencing other. Cheers Martin P.S "You kids stop having fun when I am not having any!"
On 06/12/2018 08:50 AM, martin@pluskal.org wrote:
isn't disrupted by plans and preparations for a social event.
Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there. Indeed it is ridiculous - I wonder what put Felix into position to pass such judgements, not only about release but also about conference - it is far from "social gathering". If Felix was involved either with
On Mon, 2018-06-11 at 21:46 +0200, Knurpht @ openSUSE wrote: planning of conference or with releasing Leap he would know that there is actually very little overlap between people involved in each, therefore there is no risk of one influencing other.
Calm down folks. Felix was talking about people *attending* the conference prepare for their trip and don't test. And there is indeed some overlap for those testing. But in all fairness: this is just normal business. Releases are tested *way* more and in *way* more scenarios than any milestone - plus people love to create drama for bugs in the release while they consider problems in betas 'normal'. You might remember only previous Leap releases, but those were boring service pack updates. None of it included as drastic changes as Leap 15. And for previous (non-leap) openSUSE releases, it has always been the same story. Afterwards we discussed if Betas shouldn't have been more tested or if we shouldn't have had more Release Candidates, or .... And not sure about Felix, but I would expect most grownups to be able to prepare for a weekend trip in a reasonable time that doesn't block them from any other activity they wanted to do. So I believe any other schedule of the release wouldn't have changed a bit. Well, possibly one bit: without the OSC less people would have noticed the release and tested it so soon. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 2018-06-12 at 09:55 +0200, Stephan Kulow wrote:
On 06/12/2018 08:50 AM, martin@pluskal.org wrote:
On Mon, 2018-06-11 at 21:46 +0200, Knurpht @ openSUSE wrote:
isn't disrupted by plans and preparations for a social event.
Felix, this a completely unrespectful insinuation, next to completely ridiculous. What makes you think so low about people from the community? Disappointing and IMNSHO deserves an apology to those organing the conference and those that were there.
Indeed it is ridiculous - I wonder what put Felix into position to pass such judgements, not only about release but also about conference - it is far from "social gathering". If Felix was involved either with planning of conference or with releasing Leap he would know that there is actually very little overlap between people involved in each, therefore there is no risk of one influencing other.
Calm down folks. Felix was talking about people *attending* the conference prepare for their trip and don't test. And there is indeed some overlap for those testing.
But in all fairness: this is just normal business. Releases are tested *way* more and in *way* more scenarios than any milestone - plus people love to create drama for bugs in the release while they consider problems in betas 'normal'. You might remember only previous Leap releases, but those were boring service pack updates. None of it included as drastic changes as Leap 15. And for previous (non-leap) openSUSE releases, it has always been the same story. Afterwards we discussed if Betas shouldn't have been more tested or if we shouldn't have had more Release Candidates, or ....
And not sure about Felix, but I would expect most grownups to be able to prepare for a weekend trip in a reasonable time that doesn't block them from any other activity they wanted to do.
One would assume so, but "...last weeks' testing time isn't disrupted by plans and preparations for a social event." - I also hope that for most people preparations for attending conference takes less ... 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). Cheers M
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.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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. Of course not, they were likely there for quiete some time, but if
On Tue, 2018-06-12 at 13:53 +0200, Stephan Kulow wrote: people test one week before release, its already to late for not super critical bugs to get to GM => meaning that people should be encouraged to do such testing earlier. Cheers M
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. 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. This feature was added late in the process, I didn't notice when, with the result that I did not test it. Well, two serious bugs crept in late and I failed to discover them :-( a) YaST crashes if there are encrypted partitions listed in fstab 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. (true, it is a proposal, but in previous versions the logic was better) Also, it seems the automated testing failed to detect these two problems. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.0 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 13.06.2018 um 19:56 schrieb Carlos E. R.:
This feature was added late in the process, I didn't notice when, with the result that I did not test it. Right. So shit happens - and complex systems will contain bugs. But believing that you can change anything about it by releasing a week earlier or later is just illusion.
What does help and what did help is writing test cases for things that get implemented. And we're getting better with this, but we surely have a long way to go. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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
On 2018-06-14 10:42, Ancor Gonzalez Sosa wrote:
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).
Ten extra clicks per partition. In this system there are 55. Ok, I may not need all of them at start, I can edit them back when the system runs importing some fstab from backup copy myself. So say I enter 5 partitions manually: that's 50 clicks, and several strings to type (label perhaps and mount point). Say quarter an hour extra. Enough to decide for zypper dup instead.
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.
No. A bug that was not discovered because the feature was introduced too late for being noticed, and possibly in a hurry. In fact, I failed to do late testing of the final ISO betas, or I would have discovered those two bugs
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).
Well, my testing in the same computer did not detect it previously. In fact, mounting existing encrypted partitions failed before because yast did not write crypttab. Possibly when this bug was corrected the other one appeared.
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.
It happened to me in a virtual machine where I tested for this bug.
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.
I say it is a dangerous bug. If it is a conscious decision, put a warning in red. ... Till someone at IBM gets his home deleted and complains, as happened once years ago. Then you people changed the code fast :-( -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.0 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Till someone at IBM gets his home deleted and complains, as happened once years ago. Then you people changed the code fast :-( "you people" - I wonder what makes you use such polarizing wording - I was not under impression that openSUSE is "us vs them", neither is it
On Thu, 2018-06-14 at 11:12 +0200, Carlos E. R. wrote: ... polite or fair to adress YaST developers in such manner. Cheers Martin
On 06/14/2018 11:12 AM, Carlos E. R. wrote:
On 2018-06-14 10:42, Ancor Gonzalez Sosa wrote:
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).
Ten extra clicks per partition.
Not really. But I will not start a contest of counting clicks. ;-) That was not my point.
In this system there are 55.
Ok, I may not need all of them at start, I can edit them back when the system runs importing some fstab from backup copy myself. So say I enter 5 partitions manually: that's 50 clicks, and several strings to type (label perhaps and mount point). Say quarter an hour extra.
Enough to decide for zypper dup instead.
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.
No. A bug that was not discovered because the feature was introduced too late for being noticed, and possibly in a hurry.
Ah. I misunderstood something in your original mail then. I though that the bug you labeled as "(a)" was a generic problem not related to importing partitions and that you haven't found it because testing a full re-install was cumbersome for you. Now I got it.
In fact, I failed to do late testing of the final ISO betas, or I would have discovered those two bugs
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).
Well, my testing in the same computer did not detect it previously. In fact, mounting existing encrypted partitions failed before because yast did not write crypttab. Possibly when this bug was corrected the other one appeared.
No, those are unrelated bugs and the import one is not a consequence of fixing the other. As said, I simply misunderstood what you were talking about.
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.
It happened to me in a virtual machine where I tested for this bug.
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.
I say it is a dangerous bug.
As said, I agree about the "dangerous" part and not so much about the "bug" one. But enough discussed about it.
If it is a conscious decision, put a warning in red.
...
Till someone at IBM gets his home deleted and complains, as happened once years ago. Then you people changed the code fast :-(
Initially the button was not there at all in the initial pre-releases of Leap 15 (and SLE 15) because we were focusing on other stuff and, as explained in my previous mail, it's more a convenience than something indispensable. But then we decided to implement it in the last minute because it was requested. By IBM? For SLE? NO. Because it was requested for Leap by openSUSE users. So we re-allocated some human resources to bring back at least an initial minimal version of the button just in time for the Leap release. So we prioritized having something requested by openSUSE users in time for the Leap release instead of focusing on other features requested by partners on time for the SLE release. So please, don't insinuate we are leaving openSUSE behind to please IBM, because that's exactly THE OPPOSITE to what happened here. 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
participants (10)
-
ancor -
Ancor Gonzalez Sosa
-
Bruno Friedmann -
Carlos E. R. -
Felix Miata -
Fraser_Bell -
Knurpht ＠ openSUSE -
martin＠pluskal.org -
Richard Brown -
Stephan Kulow