"Dimitrie O. Paun" dimi@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.