This is the mail archive of the
mailing list for the Archer project.
>>>>> "Jan" == Jan Kratochvil <email@example.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> 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
Jan> Sometimes I do not understand the upstream preferences
In this case, me neither. I would ask.
Jan> and also some of the patch adjustments I find more as nitpicks
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)
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.