Hi there
Just an idea, good or not I don't know:
I have been through several loss of data this week-end during an upgrade to KDE 4.8
As you can imagine, all those losses would not have appeared in a windows world, and all this is due to a couple of personn that actually decided to put a Release status on a couple of software that I won't name here.
Hence the question: How to avoid that all the users loose so much time, though all the wonderful world of so much developper, only because couple of maintainer act like irresponsible-only-feature-focussed maintainer?

The idea is not clear but one could imagine a sort of groupe of user, designed by the community,very active with beta testing, that would be able to put a Veto on a software release as long as they do not consider it to be ready for a day by day use.
I mean it is just an idea and would have to be further developped but what do you think about the efficiency it would have and how feasible it would be ?

It would help if you stated what you lost and which sw caused it to be, it might be that the data still exists but that the sw for some reason doesn't display or can't find it.

wotan wrote:Hi there
Just an idea, good or not I don't know:
I have been through several loss of data this week-end during an upgrade to KDE 4.8
As you can imagine, all those losses would not have appeared in a windows world,

lucky you, seriously. Never heard of any system that can't loose data in case of errors.

and all this is due to a couple of personn that actually decided to put a Release status on a couple of software that I won't name here.

You can name it, afterall you decided to talk about it in public and a simple search shows what you already have written. So, this obviously is about Amarok...

Hence the question: How to avoid that all the users loose so much time, though all the wonderful world of so much developper, only because couple of maintainer act like irresponsible Nazi and release maniac?

Before we go further, take a look at
No need to call anyone irresponsible Nazis or anything along those lines. Especially not when you call those who provide you with the software you obviously use like that.
Back to the point, you already have been asked if you tested the beta version for your certain use case. This might have been a great opportunity for you to make sure the final product fits your needs. But you obviously didn't.

The idea is not clear but one could imagine a sort of groupe of user, designed by the community,very active with beta testing, that would be able to put a Veto on a software release as long as they do not consider it to be ready for a day by day use.
I mean it is just an idea and would have to be further developped but what do you think about the efficiency it would have and how feasible it would be ?

That is exactly how it is working right now. But - and that is an important point - all of the contributors, be it developers or testers, are volunteers. That means persons like you and me need to step up and help out with testing. If noone reports issues they might slip under the table without being noticed.

But to make it short, it is never too late. You can jump on the train, get back to the original topic, explain your use case a bit better (sorry, i didn't understand it that much) and help to make a better next release. Without flaming developers, but i guess that is evident enough.

neverendingo wrote:lucky you, seriously. Never heard of any system that can't loose data in case of errors.

Neither did I, lucky me, I have experienced systems that encountered less erros..

neverendingo wrote:You can name it, afterall you decided to talk about it in public and a simple search shows what you already have written. So, this obviously is about .....

Again, I don't name it because this post is not about

neverendingo wrote:flaming developers

it is rather about understanding why so much amount of work, carried out by so much pepole lead to so big fails..

neverendingo wrote:No need to call anyone irresponsible Nazis

Nazi was an image, I understand it can hurt some persons, if it is the case for anybody who has read this, i woul like to present my excuse. Also I have withdrawn it now.
But I kept the term irresponsible for following reasons:
For most KDE as well as FOSS software more generally, devs and maintainer are not payed. This is really a great luck, we can develop the product we want without a boss saying "You ought to be finish by THIS DATE". Thus, we can and HAVE TO realease software for a given reliability, not for a given date

Does the fact that we are not paid means we are not responsible for anything, whatever we do?
Well this is an arugable point of view. Mine is slightly different:
When a beta or alpha status fail, to me there is no problem, I have used and am using some beta software, I have bug with them all day long, I have data losses, that is fine: the software is not yet ready.
When I put a release status on top of the software, it is another thing:
"Release status" means "People, we have developed this software to be as ergonomic as possible, we have tested it night and days, in all possible main use case, we have corrected all the bugs we have found, and right now we are at the point where we don't know how to improve the software, except adding features, hence we release now before starting adding feature for the new version"
By doing this I commited that I have done all my possible to reach the perfection and that the only reason why the software could bug is because I am a human after all...

Now if somebody use my software, has some problem with it because of a bug that appear in an obvious use case after only 10 minutes of use:
The user can't make me responsible of the bug: As a human I do make mistake
But the user is in its own right to say that I am a liar because I told him I would have tested it.

neverendingo wrote:Back to the point, you already have been asked if you tested the beta version for your certain use case. This might have been a great opportunity for you to make sure the final product fits your needs. But you obviously didn't.

I must confess I did not. But who did beta test every single software he is using? did you? I do beta test some of them, I do submit bug report, I am in contact with devs of couple of software to submit them some ideas/ feedback etc..I have even started to develop a (very small) programm. Also, I am surely not Aaron Seigo but I do make my part of the job regarding the skills I have and free time I have

neverendingo wrote:That is exactly how it is working right now.

I am not sure the word exactly is well placed here, repsectively, I probably did not express my idea very well.
Anyway it might work, the fact is that it unsufficient...

A light in the dark for me is the Calligra project: It should be on my harddisk since the middle of November and it is still not there. And I really enjoy it! Because if the mainainer were crazy , they would have realesd it anyway in November and I would have bug after bug using it since now more than 3 month. Thanks god they seems to be more responsible.
Calligra with it's 8 beta version is a good example. Any FOSS project in the world should take example from it and go even more extreme. To me any FOSS software that has not been tested for at least 3 month can not pretend to a release status.

Furthermore to beta testing:
Wouldn't it be good to make life of beta testers easier? By definition they are not devs, and pretty often they have to compile from the source which 9 time out of 10 do not work. I don't know the technical feasiblity of this but it would be good to have a sort of sandbox were we can easily beta test, ideally as easy as we download a software from the package manager. Recently I have tried to neon-project to test calligra but it was too massiv, and it did not worked for me.

If anything constructive can outcome from the problem I had this weekend, this would be a good thing...



PS: datas that I have losted:

Emails
Playlist
Customed icone setted up for each personal folder, that I have to reset
Same things for activities
All change that I have made in my music collection (Names of artist name of alubm etc)

Alltogether its probably 100 hours of work that I will have to redo now and that I won't spend on making my (small part) of the job
All this coul have been avoided if at some point someone did not lied

wotan wrote:For most KDE as well as FOSS software more generally, devs and maintainer are not payed. This is really a great luck, we can develop the product we want without a boss saying "You ought to be finish by THIS DATE". Thus, we can and HAVE TO realease software for a given reliability, not for a given date

Does the fact that we are not paid means we are not responsible for anything, whatever we do?
Well this is an arugable point of view. Mine is slightly different:
When a beta or alpha status fail, to me there is no problem, I have used and am using some beta software, I have bug with them all day long, I have data losses, that is fine: the software is not yet ready.
When I put a release status on top of the software, it is another thing:
"Release status" means "People, we have developed this software to be as ergonomic as possible, we have tested it night and days, in all possible main use case, we have corrected all the bugs we have found, and right now we are at the point where we don't know how to improve the software, except adding features, hence we release now before starting adding feature for the new version"
By doing this I commited that I have done all my possible to reach the perfection and that the only reason why the software could bug is because I am a human after all...

I'm not sure what you are discussing here, so I will give my opinion about this. First of all, all the software can fail, even if tested (tests can fail too). Second, it is not possible to test every possible environment, due to lack of resources (being a volunteer means also you have your own hardware and could not be able to test other platforms), due to the lack of time (we don't want to release software with the speed of the Amiga OS...) and the fact that is impossible to imagine what the final user is going to do with your software.
The fact that the software is going to be released means, actually, it has been tested at the state of the art, so developers are telling you they did the best to provide you good software. What you have to do is, for instance, read the upgrading docs to see if there could be a compatibility problem, backup your data (you should always do it). As you stated, developers are humans, and so are users, so while it could be that the software is broken, it could also be that your procedure of upgrading is broken too. And by the way, usually distros are more concerned with delivery on time than developers, so the distro could be broken too for this upgrade.

To me, what seems to me unsufficient in the way it works, is that so far I see the things, when a software get released, there is no one that is able to know in which extent it has been tested.
I mean to take example of a software that has three usecase A,B,C A being the most important.
You release the beta versions
You get reports of bug that appear when users do B and C
You correct those bug
You wait two weeks
No other bug

Does it mean A is right? What if none user did ever tested A?

What would be great is to have a tool, sort of database of all usecases, that betatester would tick if validated. This would help to clearly assess how deepply the thing has been tested.
This would not help to test all loadcases but at least when releasing, to say " warning feature A has not been tested"

Since month that I use KDE, i can say by experience that two times out of three, when I find a bug, I clearly see that it simply has not been tested, and it is rarely because I make a weird use of the software neither related to the hardware.

If i were a CEO of a company, the biggest thing that would frighten me about working with KDE is that you don't know at all in which extent it has been tested

I mean I am certainly largely wrong about the idea I am giving, but I do believe that if others do better than us, than there is something to improve in the way software are developed, and I will not believe that things will get better, just by themselves from alone without that something change in the process

For that to work we would need a lot more betat-esters then, you are welcome to give a hand