From: brian ford <brixen@...>
Date: 2009-08-27T01:42:39+09:00
Subject: [ruby-core:25142] Re: Patch writer's guide to submit

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> wrote:
> Hi,
>
> Sometimes we laze core developers have procrastinated to review
> submitted patches, been late to merge patchs, and frustrated
> submitters. �That's unfortunate for both side. �Here's the guideline
> to avoid such miscommunication.
>
> �* one modification per a patch
>
> � This is the biggest issue for most deferred patches. �When you
> � submit a patch that fix multiple bugs (and add features) at once,
> � we have to separate them before applying it. �It is kinda hard task
> � for us, busy developers, so this kind of patches tend to be
> � deferred. �No big patches please.
>
> �* more description
>
> � Sometimes mere patches do not describe problems that fix. �Better
> � description (a problem that fix, precondition, platform, etc.)
> � would help a patch to be merged earlier.
>
> �* diff to the latest
>
> � Your problem might have been fixed in the latest. �Or the code
> � might be totally different. �Before submitting a patch, try fetch
> � the latest (trunk for 1.9, ruby_1_8 for 1.8) from Subversion,
> � please.
>
> �* diff -u
>
> � We perefer diff -u style unified diff patches to diff -c or any
> � other style of patches. �They are far easier to review. �Do not
> � send modifed files, we don't want to make diff by ourselves.
>
> �* (optional) test cases
>
> � a patch to test cases (preferably in a patch to test/*/test_*.rb)
> � would help us understand the patch and your intention.
>
> We might move to git style push/pull in the future. �But until then,
> the above guideline would help you to avoid your frustration.
>
> Thank you.
>
>
> � � � � � � � � � � � � � � � � � � � � � � � � � � � �matz.
>
>