From: Marc-Andre Lafortune <ruby-core-mailing-list@...>
Date: 2009-08-30T07:26:21+09:00
Subject: [ruby-core:25188] Re: Patch writer's guide to submit

Reducing the submitters' frustration by reducing the delay for
feedback is a fine goal. Maybe it would be best to improve the steps 2
and 4 of http://www.ruby-lang.org/en/community/ruby-core/#patching-ruby
?

"2. Add your improvements to the code. Add tests in test/*/test_*.rb"
"4. Send your patch with a detailed explanation of what issues it
solves, ideally with code examples. As much as possible, keep changes
separate by making a patch for each bug fix/new feature"


My matrix patch (http://redmine.ruby-lang.org/issues/show/1532 )
probably qualifies as a big patch (fixing half a dozen bugs and
changing the behavior for many edge cases). I address the library as a
whole because I feel that the issues I raise are all interrelated and
that the library as a whole needs some love, but I would welcome some
guidance as to how to break it in parts if that makes it easier.

Given the gravity of the bugs in this library (as well as the lack of
feedback), I suspect that the Matrix lib is not used much, if at all.
Nevertheless, I hope it can become usable and mathematically sound in
the future.

Thanks,

Marc-Andr�

On Wed, Aug 26, 2009 at 9: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.
>
>