On 14.11.13 13:50, "Oswald Buddenhagen" <[email protected]> wrote:
>On Thu, Nov 14, 2013 at 07:52:27AM +0000, Knoll Lars wrote: >> On 13.11.13 13:38, "Oswald Buddenhagen" <[email protected]> >>wrote: >> >or to put is a bit concisely, the proposal is to simply pay attention >>to >> >the existing rules consistently instead of creating an entirely >> >unnecessary "paper trail". >> >> I agree with the proposal. > >> But if there¹s no associated JIRA task, the commit message has to be >> clear and state why this change belongs into the release branch. >> Comments in gerrit are not good enough, as they are hard to trace. >> >this is exactly what this was supposed to preempt: Huh? I was saying that I don’t think we need to create JIRA tasks. The commit message should always be clear, but if there’s no associated task, you probably need a bit of extra argumentation in there. Cheers, Lars > >> >creating jira tasks just for the sake of being able to reference them >>in >> >the commit messages does not improve the quality of the git history. >> > [...] > >the point is that once the change is in, the historical context is >irrelevant (the additional information doesn't answer why the change was >done, it doesn't show how the code evolved, it doesn't show whom to ask >about it, etc. - it's just noise). if the context needs to be determined >for some weird reason, that is certainly process-oriented, and can be >done much better with the tool we use for that: gerrit (just take the >change-id from the commit and enter it into gerrit's search field. i >regularly do that; it's a much faster and more reliable way to find out >when and into which branch a commit originally went, than trying to >reverse-engineer the git commit tree). >_______________________________________________ >Development mailing list >[email protected] >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
