Thread (5 messages) flat view 5 messages, 4 authors, 2021-12-01

Re: [PATCH] trace2: increment event format version

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-11-12 22:36:14

On Thu, Nov 11 2021, Junio C Hamano wrote:
Josh Steadmon [off-list ref] writes:
quoted
On 2021.11.11 15:03, Junio C Hamano wrote:
quoted
Josh Steadmon [off-list ref] writes:
quoted
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 <redacted>
---
 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 ;-)
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help