August 2, 2013
Participants: Samuel Ortiz, Jiri Kosina, Jason Cooper, Rafael J. Wysocki, John W. Linville, H. Peter Anvin, James Bottomley, Steven Rostedt, Takashi Iwai, Greg KH, Paul Gortmaker, Jonathan Corbet.
People tagged: (none)
See also: What's missing from our changelogs on LWN.
Samuel Ortiz would like to discuss how maintainers like himself should handle device-tree bindings, effective co-maintainership strategies, and how the single-SOB problem should be solved. (And that presumably stands for Signed-off-by as opposed to referring to the “How to act on LKML” thread.)
It was noted that git currently cannot add Signed-off-by tags without rebasing, which is to be avoided in many cases, and that although one could add the Signed-off-by tags in later merge commits, this would not track exactly which of the merged commits this Signed-off-by applied to. One concern is that maintainers might be sliding patches in without adequate review, although Rafael J. Wysocki noted that the number of Signed-off-by tags does not necessarily correlate with the adequacy of the review process. John W. Linville, never bound by convention, suggested a Singed-off-by in the merge commit, but also noted that trust was recursive, “turtles all the way down.” There was some debate as to the value of Signed-off-by, with some discussion on whether the mere existence of a merge commit could be considered to imply a Signed-off-by, or whether corner cases such as fast-forward merges invalidated any such implication, or whether refusing to pull except from signed tags covered these corner cases. Others argued that for many small fixlets, the lack of review was not a problem, with some pushback and forth.
Others debated the relative merits of stunning examples of git “committish” on the one hand and gitk on the other. [ Ed.: One's preference might be a function of the number of commits and merges you are dealing with on the one hand and the resolution of your monitor(s) on the other. ]
Some messages argued that signed-off merges would help align the development and stable trees, but Greg KH spiked this discussion by pointing out that he uses quilt, turning commits into patches and back into commits, which changes the SHA1 IDs. This prompted some discussion as to whether the stable trees should try to maintain the same SHA1 IDs (say what?) along with additional rehashing of the stable kernel thread.