OLE storage SetFilePointer fix

[Alexandre Julliard]

"Dimitrie O. Paun" <dimi at intelliware.ca> writes:

> There is good reason for this: people put work into their patches, and
> if they don't get apply, they ask why. This is where I don't understand
> Alexandre: he will eventually have to reply to such questions, why not
> do it proactively, it's the same amount of work, me thinks. But I'm not
> the one putting in the time and effort to sort through the patches, so
> I may be missing many things.

There are multiple factors here, I'll try to explain the process a bit
more:

First, if a patch is obviously wrong, I send a reply right away; if
it's obviously correct I apply it right away. But some patches are in
between; they need some more thought or investigations to determine if
they are OK or not. So in that case I put them aside and move on to
the next patch; the idea is to provide quick turn around on the
obvious patches. And hopefully it encourages people to submit easier
patches, or provide better explanations...

Then when I'm through with the obvious things I come back to the
pending patches; and when doing that I give a higher priority to the
more recent patches. The idea is that older patches are more likely to
no longer apply, or to have been superseded by a more recent one, or
to have had someone else comment on them. Again the idea is to spend
time first on things that are more likely to be applied. The result
here is that after being pending for a week or two, a patch becomes
very low in priority; this is where I expect the submitter to look
into the issue, make sure that their patch is still relevant, and if
it is, to resubmit to put it back at the top of the list.

Yet another factor is that I don't always bother to send an
explanation if I think someone will be able to figure out for
themselves why their patch was rejected. This can be because they are
an experienced developer, or because they started the mail with "I
know this is an ugly hack", or because of some obvious problem like
not in diff -u format. In such cases, if people can't figure it out
they should ask and then I will gladly provide the explanation; but if
they can figure it out by themselves then I've saved the time that it
would have taken to write the explanation.

And of course sometimes I hit 'd' on the wrong line and a patch
disappears without a trace...

The real problem I think is that there is no external way to determine
the pending/rejected/dropped status of a patch, and I understand this
can be frustrating. This is where a tracking system could help; but
IMO it will be quite a bit of work to implement something transparent
enough that I don't have to spend more time on each patch that I do
now.

-- 
Alexandre Julliard
julliard at winehq.com