On 02/03/2010 05:24 PM, Markus Elfring wrote: > >> >> The general feeling on this list is that patches are listened to, no >> matter how foul they are, and you will get a (hopefully) polite >> rejection if it is considered useless because it addresses a problem >> that doesn't exist. >> > > I hope that a healthy balance will be found between correct software > design, development and quick "hacking". What's considered a "healthy balance" varies from person to person though. > There might also be more > efforts if too many patches will be rejected just because the suggested > and planned changes were not discussed before. > Perhaps, but those wasted efforts would have been yours, not ours. Sorry, but the sad fact is that unless you're willing to "fix" this (which you should show by submitting patches), it's entirely uninteresting to even discuss it. We're all busy folks here, and we do not have unlimited time on our hands to masturbate mentally when most of us realize that it's not a practical approach to blindly follow standards. > Would you like to get an acknowledgement for signal handler problems > from people in other discussion groups like "comp.programming.threads"? > No. I have no interest in theoretical best practices for a program that has no known issues with its use of multiple threads. I do have interest in bug-reports about my favourite scm and patches to make it better. So far you have only shown a willingness to discuss possible problems instead of real-world ones. I've mentally marked you down as "the threads theory troll". To remedy that sad title, you should deliver some patches pointing out and fixing problems in the sources. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html