Massimo Del Fedele wrote:
Alexandre Julliard ha scritto:
The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff.
Hi again :-)
Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped.
Latters were one testcase (which was meant preparing some gdiplus patches....) which was rejected because "too long" and "with meaningless comments" and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because "contains errors" (possible, but which ?) and were "a pain to review" (hmmmm....). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-)
I tend to disagree with your self evaluation of 'too many'. There is NO such thing in coding. I've seen code with too little comments and then had to figure out what the heck the coder was trying to do inside the code. Of course, talking to the coder resulted in a "I know what I'm doing" conversation that resulted in no forward movement on a fixable problem that may have resulted in the company's demise.
I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help !
This is very true. Code should at a minimum point out where the examples can be found. MSDN is very frustrating when it comes to how a piece of code is supposed to work.
What I see here is a lack of assistance from those who grade the code. This is what I consider unacceptable and has resulted in the stoppage of fixes being submitted by folks who 'code for food', that is they write code for a living. I evaluate and support programs for a living. Guess what? I don't recommend that folks use Wine on Macs for production level work. It just is not 'there'. Sadly, these same folks want to walk away from using Microsoft Software because, pardon the phrase, it just plain sucks. It is poorly written and full of bugs (and some of those bugs have been there for years.) I appreciate AJs efforts to keep the code base 'clean'. In the process, however, you have to tell folks what to do in order to keep the base clean. That is just plain being nice and is good ettiquitte. Otherwise, all you are doing is attempting to shoo away those who could really help move the project along and fix long standing problems. It does not take more time to state: Your code does not meet Wine standards because it has tabs in it", then to say "You can do better". Adding comments to what a certain chunk of code does is not expensive and it does make troubleshooting code much easier at a later time by a different person. One line comments are best.
So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival.
James McKenzie