On Thu, Nov 11 2021, Junio C Hamano wrote: > Josh Steadmon <steadmon@xxxxxxxxxx> writes: > >> On 2021.11.11 15:03, Junio C Hamano wrote: >>> Josh Steadmon <steadmon@xxxxxxxxxx> writes: >>> >>> > In 64bc752 (trace2: add trace2_child_ready() to report on background >>> > children, 2021-09-20), we added a new "child_ready" event. In >>> > Documentation/technical/api-trace2.txt, we promise that adding a new >>> > event type will result in incrementing the trace2 event format version >>> > number, but this was not done. Correct this in code & docs. >>> > >>> > Signed-off-by: Josh Steadmon <steadmon@xxxxxxxxxx> >>> > --- >>> > Documentation/technical/api-trace2.txt | 4 ++-- >>> > trace2/tr2_tgt_event.c | 2 +- >>> > 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> Hmph, it seems to me that this is better done before the release, >>> or am I mistaken? >> >> Ideally yes, although I am not sure if there is anyone using traces who >> strongly depends on the accuracy of the evt field. > > Relieving us from having to keep track of the actual users is the > point of documenting to making promises ;-) > >> For release-blocking >> fixes (for lack of a better term), should I have sent this patch >> differently? > > I do not think so. Josh notes the "child_ready" event being new in this release, but the same is true of the cmd_ancestry event added in 2f732bf15e6 (tr2: log parent process name, 2021-07-21) So yeah, with both of those it makes sense to have this for v2.34.0. On the field itself I also wonder if it's useful at all. I'd think anyone implementing a parser for the format would dispatch to a lookup handling known keys, so having a version indicating "new keys here" seems rather useless.
