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
