This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: gdb-6.7-bz233852-attach-signalled-fix.patch


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> Sometimes I spend a lot of time to split the patch and create a
Jan> ChangeLog just for upstream, such as (there were many others):
Jan> 	http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html
Jan> with later no single response.  I understand it would need a lot
Jan> of changes to find a consensus and I assume there is not enough
Jan> free workforce upstream.

Yeah, that is hard.  All I can suggest is to make sure to ping pending
patches periodically.

Jan> Sometimes I do not understand the upstream preferences
Jan> 	http://sourceware.org/ml/gdb-patches/2008-05/msg00166.html

In this case, me neither.  I would ask.

Jan> and also some of the patch adjustments I find more as nitpicks
Jan> 	http://sourceware.org/ml/gdb-patches/2008-06/msg00476.html

Yeah, I hear you.  I personally assume that any documentation or help
string change is going to require a second edit :-}... I do think
using words well is important, I just don't always have the patience
to do it myself :).

I think we simply have to accept that any time we widen the group of
reviewers, the situation will change; so any patch going upstream will
probably need some kind of modification.  Having a branch lets us time
this more conveniently.

Jan> with the existing deficiencies of no memory management (reference counting)
Jan> 	http://sourceware.org/ml/gdb-patches/2008-07/msg00097.html

I've noticed the weirdnesses here too.  I wonder whether we'll want to
fix this for the values work in pretty-printing.  We'll learn soon.

Jan> I even still do not understand the meaning of the GNU ChangeLog content
Jan> describing the patch lines by words.  Why?  We have Bonsai and `cvs diff'.
Jan> The ChangeLog should just describe an intention of the patch which I still
Jan> miss in the current ChangeLog.

A lot of this is just cultural.  Plus I guess I am just used to it.
FWIW, for bigger changes, I do stick a (short) statement of intent at
the top of the ChangeLog entry.  As long as this isn't something that
should be in the code, it is harmless at worst.

Tom


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