From: Jason Creighton <androflux@...>
Date: 2003-09-12T10:15:41+09:00
Subject: Re: using a filter inside Ruby

On Thu, 11 Sep 2003 18:23:45 +0900
"Gavin Sinclair" <gsinclair@soyabean.com.au> wrote:

> >> Here's how you can ensure this is fixed:
> >>  * subscribe to ruby-core@ruby-lang.org
> >>  * create a patch to fix that documentation issue (diff -u format, I
> >> think)
> >
> > Nitpick: unified diffs here, although shorter, can often less, umm,
> > informative and unless specifically asked for, I would suggest sending
> > in both a non-unified and a unified diff.

I find unified diffs easier to read. What are you suggesting as a
non-unified diff? (Plain old diff? Context diff? What?)

Plus unified diffs are more robust because of the context included.

> I've never seen two diffs sent before, and I believe the standard on
> ruby-core (I'm not a licenced representative, BTW :) is unified.  I've
> seen a complaint when a plain diff was sent.
> 
> > Also, it is not a patch file, until it has been applied :)
>
> That's a new one :/
> 
> Isn't the output of 'diff' considered fair game as input to 'patch'? 
> Don't uber-geeks simply run 'patch' on the entire contents of an email and
> trust it to do the right thing?
>
> >>  * send it to ruby-core, as a "PATCH: ..." subject
> >>
> >> It seems heavyweight, but it makes it easier for the maintainer to go
> >> "yep, that looks good, I'll commit that".  And besides, once you've
> >> subscribed, it's easier to contribute more patches!
> >
> > Given Jason's busy workload (I would imagine)

LOL! When you're not out of high school, there's really not that much
work to be done. :)

> > I doubt he will be able to contribute that many (if any) patches.
>
> The suggested patch would take less than 5 minutes.  It might not seem
> like much of an outcome, but the maintainer, on applying it, would
> probably be prompted to do some general improvement to the file.

No, actually, the main thing I'm worried about is subscribing to
ruby-core. About how many messages/day there? Might have to fork some
money over to softhome.net to get a higher mail quota. Anyhow, I think
I'll subscribe to ruby-core and submit the open3.rb doc patch.

<thinking out loud>

It Would Be Nice(tm) if there was an email address that would forward to
ruby-core so people wouldn't have to subscribe for simple little patches
like this. Maybe have to include "ruby-core" in the subject line or
something so spam doesn't get through.

> >> Of course, for some files, it may be better to send patches directly
> >> to the author, but if the file is in the Ruby distro, ruby-core is a
> >> good catch-all.

Yes, especially because there's no author listed for open3.rb. So the
general rule of thumb would be that if it's a package of it's own right
(something like test/unit or webrick or something), sumbit patch to
author and it'll get into Ruby next time he/she does a CVS commit, but
if it's on its own, like open3.rb, send to ruby-core?

Jason Creighton