> It bothers me that we're cluttering up our commit messages with > ephemeral data unrelated to the actual change. DONTBUILD and CLOSED > TREE are the worst offenders.
What if we asked people to put DONTBUILD / CLOSED TREE in a new line at the bottom of their commit message? Most of the time we look at only the first line of the commit message, so it seems to me this would eliminate most of the aesthetic offense, without requiring us to develop entirely new tools for interacting with our SCM. This would have the added benefit of teaching people that they can write multiline commit messages, which is something I hope we can all agree on. :) On Thu, Apr 11, 2013 at 12:48 PM, Steve Fink <sf...@mozilla.com> wrote: > It bothers me that we're cluttering up our commit messages with > ephemeral data unrelated to the actual change. DONTBUILD and CLOSED > TREE are the worst offenders. I would also like to have > machine-readable tags for regular push vs bustage fix vs backout vs > merge, because they would be useful for computing statistics that could > then drive automation optimizations. But I think using push metadata > for all of this is a non-starter, both for new and existing > contributors. > > If I were to propose something, it would probably be (1) define a > format for metadata that could be placed after the first line of a > commit message, (2) make the automation check push metadata (the > built-in kind) for DONTBUILD and CLOSED TREE, and (3) make tbpl expose > DONTBUILD/CLOSED TREE and perhaps backout metadata in the UI. The value > of #2 is debatable, since you can already put it after the first line > and it's fairly easily ignorable. > > If you wanted to ensure that #1 serves its purpose, you might also want > to implement a push hook that requires that if the metadata is present, > then it must be properly formatted (and semantically valid, to the > extend that it's automatically checkable.) > > I can also see the argument for externalizing this metadata, since > there are some related things that are not known at the time of commit > -- whether it crashed and burned on landing, for example. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
