On January 11, 2004 08:04 am, Martin Fuchs wrote:
This patch consists of a number of changes we implemented in the ReactOS CVS tree in order to use Wine's shell32.dll implementation for ReactOS explorer. Please see the following changelog lists for the individual patch descriptions:
Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody. Here are some relevant links: http://www.winehq.org/site/sending_patches http://www.winehq.org/site/docs/wine-devel/patches
Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody.
Yes, I am aware of that. This patch is the result of four weeks work (not only of me), spending most of the time with debugging, as most of those stuff is pretty undocumented by Microsoft. It's not possible to simply look at the ReactOS CVS history to separate out patches for every small piece of change. If you want me to send in it this way, this would take me another week. I don't think, it's worth that. It would be better to commit the code changes in one transaction. Shell32 has been quite incomplete before this patch, and it's also far from complete with this patch.
Why I have compressed the attachments: Well, I don't think every one on the list wants to read the changes, which are not very readable at their own. And reading through endless hex numbers of shres.rc is also not very interesting.
Regards,
Martin
"Martin Fuchs" martin-fuchs@gmx.net writes:
Yes, I am aware of that. This patch is the result of four weeks work (not only of me), spending most of the time with debugging, as most of those stuff is pretty undocumented by Microsoft. It's not possible to simply look at the ReactOS CVS history to separate out patches for every small piece of change. If you want me to send in it this way, this would take me another week. I don't think, it's worth that.
I'm afraid you'll have to do that. There's no way I can put that patch in as is, it's way too big and doing way too many different things. It also has a number of ugly hacks that will have to be cleaned up. Please submit small self-contained patches that do only one thing, with a changelog explaining what they do.
I know it's a pain, but the real solution for next time is to submit things as soon as they are done, instead of waiting a month and then sending a huge patch that cannot possibly be reviewed.
I'm afraid you'll have to do that. There's no way I can put that patch in as is, it's way too big and doing way too many different things. It also has a number of ugly hacks that will have to be cleaned up. Please submit small self-contained patches that do only one thing, with a changelog explaining what they do.
OK, OK - I feared that.
I know it's a pain, but the real solution for next time is to submit things as soon as they are done, instead of waiting a month and then sending a huge patch that cannot possibly be reviewed.
This "as soon as they are done" has been the problem. I did not wait a month, I simply could not get some things running at the first try, and had to change some things a number of times. I don't think, you would have been happy with receiving all those forward and backward steps.
Perhaps you could commit the biggest but simplest thing in the meanwhile, the new icons. They are nearly independend from the C code, and I would like to avoid resending this big patch file. But please don't the change the icon ID in shres.rc for now: -0 ICON document.ico +1 ICON document.ico This also needs a code change.
Regards,
Martin
Hiya M8, --- Alexandre Julliard julliard@winehq.org wrote:
I know it's a pain, but the real solution for next time is to submit things as soon as they are done, instead of waiting a month and then sending a huge patch that cannot possibly be reviewed.
There has to be a more simple way of us diffing our patches. Would any of the scripts you use on Crossover merging help us?
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
On January 12, 2004 09:14 am, Steven Edwards wrote:
There has to be a more simple way of us diffing our patches. Would any of the scripts you use on Crossover merging help us?
There is csgrep in the tools/ module in CVS, but for that to work you guys need to run our commit_prep and log_accum in CVSROOT. If you do that, you get the wine-cvs - type messages for free, and can use our patch.py script to generate patches. From what I see in other similar systems (used in projects such as SourceForge/gcc/KDE/etc.), ours is the best -- comes highly recommended! ;)
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
There is csgrep in the tools/ module in CVS, but for that to work you guys need to run our commit_prep and log_accum in CVSROOT. If you do that, you get the wine-cvs - type messages for free, and can use our patch.py script to generate patches. From what I see in other similar systems (used in projects such as SourceForge/gcc/KDE/etc.), ours is the best -- comes highly recommended! ;)
This would be nice anyway as our CVS commits dont currently show anything but the filenames of what was changed. Our CVS maintainer said he wasnt opposed to setting this up a while back to maybe this will be what we will have to do.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
-
Alexandre Julliard -
Dimitrie O. Paun -
Martin Fuchs -
Steven Edwards