Let's suppose 'I' am the user and 'you' are the developer, which I guess is partially true sometimes.
Let's also say what should be implicit, that we are discussing for the sake of exchanging ideas, and that nobody is criticising the work of nobody, and also that the fact of replying in a somewhat 'polemic' tone doesn't mean one feels offended but only that the debate excites him/her (this is my case, hope it is yours as well).
You're right, mine are not suggestions, they are demands.
Wich leads me to what seems to be the (or one) underlying point throughout your email, that is: what right do I have to demand things from you? Why should you listen to my demands and work to fulfill [dunnow if it is the right verb here] them? What do you get from it?
Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you. This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop. But I assume there is one, because if there wasn't one then the software would'nt exist and we wouldn't be talking about it. I have to assume that for some reason you (the developer) are interested in developing the software and in making it the best it can be. Otherwise, we wouldn't be talking in the first place.
So, I don't have any right to demand anything, I am very grateful that PD exists the way it is, with its bugs and everything, and you don't have to fix anything; but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is "feedback", and feedback consists, among other things, in DEMANDS. These demands can be reasonable or foolish, that is, the feedback from the user can be valuable or useless.
The latter also holds for bug reports (another kind of feedback), which can actually help to fix the bug or not.
[.......] allowing the user to go "beyond limits" usually involves more sophisticated code: easier to make errors, easier to create bugs.
Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: "What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one?" Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software...
Jesus, are we discussing whether bugs should be fixed or not?????????
Remember (I say this to myself too) that the whole "debate" arose because somebody mentioned a situation of instability and I pointed out that it seems to be particularly frequent with big patches in PD. So, let's try not to take this as a criticism (maybe the tone of my first mail didn't help in this sense). PD is constantly under development, isn't it? It is not a "finished" product (if such a thing even exists). So, it has its strengths and weaknesses, like every piece of software. It doesn't make sense to discuss whether the first compensate the latter or viceversa; it MAY make sense to analyze its strengths and merits; but I think it is more useful to point out weaknesses so that they can be worked on in the future.
What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it. One thing that I have experienced, and that a few users have experienced but, I suspect, not so many, is that with huge patches things start becoming unstable. Since it is not so frequent to "hit" this problem, when I did, I gave my feedback about them, including bug reports when I could isolate some reproducible crash, and test patches when I could. Now, since another user commented about instability with huge patches, I took the opportunity to stress again the importance that this kind of issue has (imo, obviously), and to express the feeling (possibly wrong) that they are not given the importance they deserve. That's all.
sometimes I have the
impression that though that is the philosophy, it is not fully expressed in the implementation.
true. but what can you do about it? basically i see two ways: do it better, or tell people that they MUST do it better.
Well, unfortunately I can't do it better, and about the second option, I guess you are sarchastic. I think there's a third thing I can do: give the developers information (i.e. reports, test patches, etc) that can help them doing it better, which implies the assumption that they are interested in doing it better. If every time I do that I should feel like I was telling them what they MUST do, thus offending them, well, then I probably had better unsubscribe this mailing list.
but you feel that it is not too difficult for other people to isolate the bug and fix it, with nothing more than "if i create 12000 instances of a patch (which i cannot send you because it's proprietary and i can't trust you) it crashes, but it doesn't crash with 20500 instances of another patch".
(first, I didn't say I don't trust you; I just said I can't give you what is not mine, stop) No, I just think I have to report the bug with as much information as I can; if that is not enough to fix the bug, well, I tried. I think the developer usually has much more information than the user, and sometimes with some clues can find the problem even without a directly reproducible crash. Obviously your oversimplification or example is exagerated.
I am a developer also (or I consider myself such), though I don't develop in C++; obviously my work is way way simpler than something even comparable to a software like PD. But sometimes "my users" simply report that things "don't work" and they are not capable of giving me a directly reproducible error that I can investigate, nor anything better than a confused explanation. I don't consider their duty to do so, I rather consider my duty to find out what's wrong, which is my error in the first place. Anyway, the fact that there's no simple way to reproduce the problem has no relevance in evaluating the importance of fixing it. That can be very frustrating, I know. However, I recognize this is not the same thing because I do get paid for the work.
but if somebody is ready to shout "your work frustrates me", than they should be prepared to get an answer "your statement frustrates me". i think there's equal rights about frustrations and expressing them.
Well I must recognize you are right here. But please be sure I didn't mean to "shout".