Mail Archives: cygwin-developers/2000/07/15/23:42:26
[redirected to cygwin-developers]
On Sat, Jul 15, 2000 at 11:22:43PM -0400, Jason Tishler wrote:
>Chris,
>
>I'm about to (finally) submit my patch for the cygdrive path prefix
>changes that I have been (slowly) making. Since this is my first
>official patch, I would like to make sure what I submit is as useful
>as possible. I have the following questions:
>
>1. I am planning on using the following command to generate the patch:
>
> diff -aur cygwin-src-20000612.orig cygwin-src-20000612 >cygdrive.diff
>
>Is the above OK? Or, should I use other diff options?
I usually just use the equivalent of "diff -up". That should be
sufficient. You can skip the '-r' and just do this in the winsup
directory.
Please include a ChangeLog entry. Use the existing entries as your guide,
remembering that the entries are not supposed to be detailed explanations
about the change (although I may stray from that goal from time to time).
The comments in the code should describe what is taking place.
Also the entries should be in present tense, e.g.,
Sat Jul 15 23:30:56 2000 Christopher Faylor <cgf AT cygnus DOT com>
* foo.c (afunc): Change function return from int to char.
(bfunc): Fix a typo.
rather than
Sat Jul 15 23:30:56 2000 Christopher Faylor <cgf AT cygnus DOT com>
* foo.c (afunc): Changed the function to return int rather
than char.
(bfunc): Fixed a typo.
>2. Do you mind dealing with duplicate patches? Or, should I hand edit
>out parts of my patch that I know are already in CVS? Specifically, I
>needed to "fix" winsup/cygwin/fhandler.cc and winsup/cygwin/fhandler.h
>due to the -Dunix change when I upgraded to a new gcc package midstream.
You need to supply a patch against the current sources. I don't want to
have to guess what should be included and what shouldn't.
The ideal way to do this would be to check everything out using CVS and
just use "cvs diff -up".
If you can't do this for some reason, use the most recent snapshot
sources.
I should point out that Corinna is working on a "chroot()" implementation
that will impact path.cc, so, I'll probably leave it to her to apply
your patch.
>3. Anything else I should do that will make it easier for you to deal
>with my patch.
Those are the general guidelines. In a nutshell, all that you have to
do is Supply a ChangeLog (*not* a diff of a ChangeLog) and a diff -up.
It's probably not an issue for this patch, but you should also try to
make sure that each patch deals with one functional issue. I.e., don't
submit one patch that implements new console escape sequence handling
along with improvements to cygwin's socket() function.
That's about it. FYI, much of this is discussed in the GNU coding
standards at: http://www.gnu.org/prep/standards_toc.html .
I hope that the coding style of your patch adheres to the coding style
of the code that it is modifying in terms of indentation, brace usage,
etc. Cygwin source tries to be close to the standards discussed above
although probably the guidelines for error messages are not rigorously
followed.
Looking forward to seeing the patch.
cgf
- Raw text -