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
Message-ID: <397375E2.8D60F522@dothill.com>
Date: Mon, 17 Jul 2000 17:08:50 -0400
From: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
Organization: Dot Hill Systems Corp.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Cygdrive Path Prefix Patch Questions
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> <20000715234204 DOT A8343 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris,

Chris Faylor wrote:
> [redirected to cygwin-developers]

Sorry for the direct email.  I knew that when I was writing it that I
should have addressed it to cygwin-developers, but I was a little 
embarrassed by its content ... Oh, well! :,)

> On Sat, Jul 15, 2000 at 11:22:43PM -0400, Jason Tishler wrote:
> >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.

I'm just curious (since I will be using CVS) but how can "diff -up"
without "-r" in the winsup directory produce a complete patch?

> Please include a ChangeLog entry.

After I sent off the email, I realized that I forgot to ask about
providing a ChangeLog entry -- thanks for bringing it up.

> 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.

Thanks for the above, it was quite informative.

> >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.

Agreed.  One of the main goals of my email was to avoid things like the
above.  Although, unless I do a cvs update right before I generate my
patch (and even then) it may not be against the current sources.
Hopefully, almost current sources will be sufficient -- certainly better
than cygwin-src-20000612.

> The ideal way to do this would be to check everything out using CVS and
> just use "cvs diff -up".

I'm doing the CVS thing now -- I should have done it before instead of
messing around with the snapshots.

> 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.

That's fine, I'll just submit my patch to the list and whoever is
appropriate can apply it.

> >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.

The above sounds simple enough (now that I know).

> 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.

You are correct, my patch only deals with one functional issue -- cygdrive
patch prefix functionality.

> 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 have scanned the above before -- I will read it more carefully now.

> 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.

It does -- I consciously tried to make my changes match the existing
coding style.  This is my standard operating procedure when I am modifying
someone else's code.

Thanks for your time and patience.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason DOT Tishler AT dothill DOT com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com