[PD] Very large patches unstable?

Matteo Sisti Sette matteosistisette at gmail.com
Wed Dec 2 17:36:15 CET 2009

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 

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".

Matteo Sisti Sette
matteosistisette at gmail.com

More information about the Pd-list mailing list