This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Various Windows support changes (assignment needed)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]