Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sat, 15 Jul 2000 23:42:04 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
Cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Cygdrive Path Prefix Patch Questions
Message-ID: <20000715234204.A8343@cygnus.com>
Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com
Mail-Followup-To: Jason Tishler <Jason DOT Tishler AT dothill DOT com>,
	cygwin-developers AT sourceware DOT cygnus DOT com
References: <3946A03A DOT C5452A47 AT dothill DOT com> <200006132109 DOT RAA08578 AT envy DOT delorie DOT com> <20000613172026 DOT A17487 AT cygnus DOT com> <3947971E DOT AFEFFF0 AT dothill DOT com> <20000614104822 DOT A9279 AT cygnus DOT com> <39712A83 DOT 8500E111 AT dothill DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <39712A83.8500E111@dothill.com>; from Jason.Tishler@dothill.com on Sat, Jul 15, 2000 at 11:22:43PM -0400

[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