New kernel development guide might be good model for Wine...

[Reece Dunn]

2008/8/19 Markus Hitter <mah at jump-ing.de>:
>
> Am 19.08.2008 um 00:41 schrieb James Hawkins:
>
>> when the patch doesn't get committed, you should look back at it
>> and really think
>> outside the box about what could possibly be wrong with the patch.
>
> Essentially, you ask to change code on unfounded guesses (I did the
> best to my knowledge in the first place already) and to commit into a
> black hole until some unknown, not communicating person is satisfied
> to her/his taste.

I agree to a point. There are certain things you can check (e.g. do
the tests pass on Wine) that usually block a patch.

Other things it can be difficult to spot. Especially if you are not
used to the coding conventions, or Windows idiosyncracies.

>> You assume it wasn't noticed.  I can guarantee that's not the case.
>
> So, what did the reviewing person then? Sitting there smiling "Heh,
> look, he could have done better, but, ha-ha, I won't tell him"? I
> hope this wasn't the case.

This is why it is important to keep track of the patches you have sent.

>> Give Alexandre a bit more credit than that.
>
> I'm fine with Alexandre personally but not so sure about Wine's
> current patch receiving process.
>
> That said I'm perfectly fine if Wine people consider this process as
> being effective. There's no law enforcing Wine to accept what I've sent.

I think Alexandre does a fantastic job.

>> [...] or ask the community or Alexandre what the problem is.
>
> Correct. Communication is a plus.

Which is why it is important to ask why your patches have not been
committed. Whenever I have asked, I have got a good response.

I have found that this is easier to do on the IRC, but like with
everything it requires time and commitment.

- Reece