From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23566 invoked by alias); 21 Apr 2004 21:24:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23554 invoked from network); 21 Apr 2004 21:24:44 -0000 Received: from unknown (HELO timesys.com) (66.30.22.40) by sources.redhat.com with SMTP; 21 Apr 2004 21:24:44 -0000 Received: by timesys.com (Postfix, from userid 201) id 36488400833; Wed, 21 Apr 2004 17:24:44 -0400 (EDT) Date: Wed, 21 Apr 2004 21:24:00 -0000 From: Christopher Faylor To: Keith Rollin Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Various Windows support changes (assignment needed) Message-ID: <20040421212444.GA23427@coe.bosbc.com> Mail-Followup-To: Keith Rollin , gdb-patches@sources.redhat.com References: <3271DBB88437ED41A0AB239E6C2554A4031CE230@ussunm001.palmsource.com> <20040420163507.GB22971@coe.bosbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2004-04/txt/msg00505.txt.bz2 On Wed, Apr 21, 2004 at 01:43:18PM -0700, Keith Rollin wrote: >At 12:35 PM -0400 4/20/04, Christopher Faylor wrote: >>1) It is a fairly large patch involving a few distinct fixes. >> It is much easier to review and install one patch which addresses >> one problem than it is to review one gigantic patch which addresses >> n problems. Would you consider sending this as multiple patches? > >I remember reading that recommendation in the CONTRIBUTE document, >but it wasn't clear to me how to provide multiple patches. I don't >know how to create them -- how do I separate my changes? Techniques vary. I guess you could, one at a time, edit the patch file, apply it to a vanilla source for verification, and then submit the patch. That's what I do when I have a small patch that I want to submit from a much larger change. >>2) Please don't send compressed patches here. Just send your patch >> and ChangeLog as plain text. > >OK. The CONTRIBUTE document said "We accept patches as ... gzipped >text", so I thought what I did was OK. This is the third option provided. The preferred method is plain text. It makes things much easier for a patch reviewer since you don't have to take an extra step. It should also make things easier for a patch submitter since *they* don't have to take a separate step but some mailers (notably Windows mailers) like to munge newlines in patches. Regardless, it still pays (IMO) to submit your patches in clear text. I think you'll see that this is the case for the majority of the patches here. >>3) Please send patches against CVS rather than a gdb release. >> Patches generated against CVS are more likely to apply cleanly. >> As it turns out, your patch installed ok with the exception of >> your change to version.in. However, it is always a little more >> comforting to see a patch apply without the fuzz and offset warnings >> from patch. > >I was leery of sending in patches against gdb 6.0, especially when >6.1 had just been released. However, I've never used CVS, and so >don't know how to perform what you ask. If needed, of course, I >could learn. It's not an absolute requirement for this set of patches. It's just a nice to have. >>I do appreciate all of the work that went into this patch. The only >>real stumbling block here is the lack of an FSF assignment. > >At this point, it's not clear to me if your points above are advice >for any subsequent submissions, or if I need to address them for this >submission. You noted that you'd already applied the patch, so I'm >thinking the former. I just applied the patch to my local sandbox to see if there were problems applying the patch. I haven't evaluated it in any way other than that. My preference would be for you to 1) get the assignment and then 2) start submitting small patches + ChangeLog here against CVS. I can move pretty quickly when there are individual nuggets to consider but if I have to break up the patch myself and puzzle over it, it will take more time. I will eventually get to it but it will just take longer. Anyway, 1) is an absolute requirement. These changes are too large to be included without an assignment. 2) is just a nice to have. If you would prefer to just break up the patches but avoid CVS then that's ok, too. Or, if you want to just avoid this part entirely then you'll have to be patient for me to find a block of time to deal with your whole patch. Thanks again for taking the time to both fix the problems you found and submit them here. I hope you will continue to improve the windows version of gdb. cgf