Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.

[Thiago Farina <tfransosi@gmail.com>]

On Fri, Sep 18, 2009 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> This release candidate freeze is a period that no one can send patches?
>
> No.
>
> After -rc1, only fixes to regressions and severe bugs and trivially
> correct documentation patches will be applied to my tree, but all other
> kinds of patches are still sent to the list for discussion, so that the
> proposed changes can be discussed, polished and then become ready for the
> development cycle after the upcoming release.
> I often even pick them up and queue them to 'pu' and possibly 'next' as time permits.
If you don't want to pick a patch this means that it was not accepted,
right? I wrote others two trivial patches, one has comments, and I did
the changes suggested, but I guess not will be done about it because
it is just trivial.
>> And what did you mean with code churn?
>
> A change primarily for the sake of change without urgency nor real benefit
> in the longer term.
>
> It bothers nobody if a long literal string is written as a string literal
> in a dq pair with LFs quoted with backslashes, or as a run of multiple
> string literals, each of which ending with LF, to be concatenated by the
> compiler.  It however would bother somebody who actually wants to modify
> these lines for a real change, and that is the best time for doing such a
> clean-up.  Reasons for such a real change vary; to fix earlier mistakes
> (e.g. one line being excessively longer than others, or an option is
> misspelled), to add a new option, or to make the output of the program
> easier to read in general, etc.
This means that trivial patches like this one I wrote are generally
not accepted? Why is there this difficult (is it to maintain the high
level of the patches)? I thought if it is trivial it can be merged
after a review, into one of the integration branches. You write the
comments (the people in mailing list), I make the changes, and then
the patch is committed. But what I'm seeing here, this is not how the
things are done here. It is much more complicated than that I guess.

In a codereview tool I can send a patch for review, I can assign it to
someone review, he will make comments, I will make the necessary
changes, and when the patch is ready, it will be committed. What is
the workflow? With an email I can't assign a patch to someone, with
time it will be lost.

I'm just trying to understand what I have to do, to submit better
patches. Another issue that I saw, is about *issues* or bugs, they are
not tracked in a bug traker. It's just an email, so how can I work in
a bug if I don't know about it, have I to find the bugs myself?