Hi Matz,

These guidelines sound very reasonable. Thank you for providing them.

Can I make one suggestion: please, please make test cases mandatory
for all patches.

Unless it is pure refactoring, which I suggest would be quite rare,
the patch *must* change something. So the author must have had some
Ruby code that did one thing, then after the patch, the Ruby code does
something else. I believe making the test requirement mandatory is not
too much to ask of patch authors.

Thanks,
Brian

On Wed, Aug 26, 2009 at 6:06 AM, Yukihiro Matsumoto<matz / ruby-lang.org> wro=
te:
> Hi,
>
> Sometimes we laze core developers have procrastinated to review
> submitted patches, been late to merge patchs, and frustrated
> submitters. =A0That's unfortunate for both side. =A0Here's the guideline
> to avoid such miscommunication.
>
> =A0* one modification per a patch
>
> =A0 This is the biggest issue for most deferred patches. =A0When you
> =A0 submit a patch that fix multiple bugs (and add features) at once,
> =A0 we have to separate them before applying it. =A0It is kinda hard task
> =A0 for us, busy developers, so this kind of patches tend to be
> =A0 deferred. =A0No big patches please.
>
> =A0* more description
>
> =A0 Sometimes mere patches do not describe problems that fix. =A0Better
> =A0 description (a problem that fix, precondition, platform, etc.)
> =A0 would help a patch to be merged earlier.
>
> =A0* diff to the latest
>
> =A0 Your problem might have been fixed in the latest. =A0Or the code
> =A0 might be totally different. =A0Before submitting a patch, try fetch
> =A0 the latest (trunk for 1.9, ruby_1_8 for 1.8) from Subversion,
> =A0 please.
>
> =A0* diff -u
>
> =A0 We perefer diff -u style unified diff patches to diff -c or any
> =A0 other style of patches. =A0They are far easier to review. =A0Do not
> =A0 send modifed files, we don't want to make diff by ourselves.
>
> =A0* (optional) test cases
>
> =A0 a patch to test cases (preferably in a patch to test/*/test_*.rb)
> =A0 would help us understand the patch and your intention.
>
> We might move to git style push/pull in the future. =A0But until then,
> the above guideline would help you to avoid your frustration.
>
> Thank you.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matz.
>
>