On Fri, Sep 18, 2009 at 4:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Thiago Farina <tfransosi@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html