Am 10.08.2010 um 17:42 schrieb Oldrich Jedlicka: > Ok, I understand. I'm just sending the whole patchset with changed/unchanged > patches (the number of patches changed, because some of them had been applied > and some of them I removed, because they don't implement things properly). Admittedly I didn't look at the other patches, I looked at patches 1-2 and thought that I've seen this in exactly the same form before.
In your specific situation it is probably better to send just patch 1, wait until it is applied, then send patch 2, etc, and send bigger patchsets once you've a few patches in Wine. To answer the general questions, this is how I deal with problems in a part of the patchset: *) Generally write a mail stating that the patch is broken and shouldn't be applied to wine-devel. If follow-up patches are independent of this patch I can state so in the mail. If the issue was quick to fix(e.g. whitespace problems) and I am confident that the patch should work now I'll attach the new patch and send the mail to wine-patches only. Otherwise, if I can't attach a fixed patch right away the options are as follows: *) Resend the entire patchset, probably on the following day. *) Let the first patches be applied, resend the remaining patches the next day. Basically it is better to push forward a bit slower and let the patches of the day settle and resend the next day to avoid confusion. Also a (try X) with X > 4 usually often leads to skepticism, because people don't know how many more tries will be needed. I am personally critical of this because of my own experience on gcc-patches. I needed about 10 tries to get the gcc patch for the Steam overlay, I would never have been able to do it with just 4 or 5 iterations. > Is there some recommended way to send updated patchsets when only some > patches need to be improved (but the sequence of applying should stay)? Would > the "introductionary" mail describing changes and patches as follow-ups help? This can be helpful, but it is also possible to mention what changes you made in the new patch version in the patch description itself. A separate overview description(or description in patch 1) can be helpful if the overall direction of the changes is not easy to understand from the patches themselves, e.g. if more patches are going to come after those are applied. In this situation it is also recommended to send all patches in a packed archive to wine-devel for review, so everyone can see where you're headed.
