►
From YouTube: 2022-08-11 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
B
All
right
and
welcome
raphael-
and
I
don't
remember
brian
if
you've
joined
before
or
not
great,
to
see
you.
B
So
maybe
we'll
come
back
to
release
if
jack
makes
it
and
my
custom
aggregations
question
is
probably
should
wait
for
jack
also
so
brian
instrumentation
questions.
C
All
right,
so
this
is
looking
at
the
apache
knife.
I'm
sure
you
kind
of
remember
our
discussion
two
months
ago
and
we're
just
kind
of
getting
started
on
to
seeing
what's
possible.
C
B
Yeah
I
mean
we,
we
accept
prs
directly,
you
could
also
open.
Do
we
have
an
issue
about
it
already.
B
Okay,
so
oh
yes,
yes
yeah,
I
mean
you
could,
you
know,
add
a
little
bit
of
context
here,
but
primarily
yeah
just
send
a
pr
and
I'm
imagining
it's
kind
of
large
change.
C
Yeah
and
is
there
specific
expectations
like
performance
tests
or
smoke
tests
that
we
need
to
write
as
part
of
the
pr.
B
Yeah,
so
not
performance
tests
and
not
smoke
tests.
From
the
perspective,
we
have
some
smoke
tests
here,
but
all
of
the
instrumentations
have.
B
Fairly
good
test
coverage
and
they're
essentially
like
into
their
integration
tests,
if
you
and
I
fear,
you've
seen
the
docs
on
writing
instrumentation,
let's
see
what
we
say
about
tests
here,
yeah.
C
C
If
we
did
get
approval
to
do
manual
instrumentation,
would
the
work
done
for
the
auto
instrumentation
help
benefit
the
potential?
You
know
eventual
manual,
I'm
hoping,
maybe
if
they're
they
accepted
that
we're
able
to
add
it
to
their
build,
and
then
we
can
take
advantage
of
the
work
done
through
the
auto
instrumentation.
B
I
see
yeah
so
typically,
it's
kind
of
the
reverse
of
we'll
build
library,
instrumentation
and
auto
instrumentation
together,
but
the
auto
instrumentation
tries
to
leverage
the
library
instrumentation
as
much
as
possible.
B
Have
you
in
the
work
that
you've
done?
Have
you
split
out
sort
of
library
instrumentation
or
is
it
only
java
agent,
instrumentation.
C
B
I
see
in
that
case
right
and
I'm
kind
of
remembering
knife.
I
is
a
fair
like,
like
people
run,
it
stand
alone
sort
of
like
a
server.
It's
not
like
a
library.
B
B
The
code
may
not
be
terribly
reusable
because
read
a
lot
of
the
code
is,
in
the
you
know,
the
byte
buddy
on
method
enter
on
method
exit,
but
all
of
those
will
guide.
You
then,
on
where
you
want
to
put
the
equivalent
calls
in
nifi
directly.
B
A
Yeah,
I
think
we
would
want
to
do
a
release.
Well,
I
think
we
would
have
wanted
to
do
it
at
the
end
of
last
week.
A
A
If
anyone
is
interested
in
becoming
more
involved
in
the
project,
getting
the
release,
notes
and
change
log
up
to
date
and
ready
to
go
for
the
release
would
be
extremely
helpful,
something
that
would
help
move
things
forward
on
the
on
the
release.
So
jack
wouldn't
have
to
do
that.
B
A
B
A
Like
the
well,
I
mean
it's
it's
squishy,
obviously,
but
since
the
first
of
august
was
the
monday,
the
fifth
probably
would
have
been
a
good
target,
so
yeah,
I
think
the
end
of
the
first
full
week
is
what
we
usually
target
got
it.
B
Oh
for
the
instrumentation
api
is
that
what
you're
asking
jonathan
that
will
be
so
a
week
after
the
core
repo
release?
Oh
yeah,
sorry
they
are
released
differently.
Okay,
yeah,
sorry,.
B
Thank
you
yeah,
but,
yes,
mateosh.
I
believe
we
are
planning
on
calling
instrumentation
api
rc
in
117.
I
think
we
are.
I
mean
I've
looked
through
all
the
code
and
it
seems
quite
ready
to
me.
I
mean
there's
still
several
deprecated
classes
that
will
need
to
be
removed,
but
I
think
keeping
deprecated
stuff
as
part
of
our
seas
should
be
fine,
nice
yeah.
So
that
has.
B
B
The
next
step
will
be
extension,
api
and
later
maybe
http
symmetric
conventions
assuming
they
get
stabilized
in
the
spec.
B
Oh
yeah,
the
new
mateish,
were
you
still
thinking
of
working
on
the
updated
http?
B
I
am
still
thinking
of
that,
but,
like
this
week,
is
a
planning
week
in
splunk,
so
I
have
no
time
for
anything
so
at
the
earliest.
I
will
start
doing
anything
like
next
week:
cool
cool.
B
B
Oh
yeah,
this
I'll
check
with
jack,
but
this
did
get
john.
You
did
approve
this,
I'm
hoping
for
this
to
be
merged
into.
Oh,
no.
He
left
me
a
comment,
but
I
didn't
see.
Okay.
B
All
right,
oh
anonymous,
fox,
yes,
give
us
more
to
talk
about.
B
Yes,
we
did,
I
removed
it
from
the
calendar,
it
should
not
be
there
anymore.
B
B
B
A
I'll
just
throw
out
what
you
know.
What
we
really
need
in
this
project
is
more
people
giving
deep
pr
reviews,
because
I
am
no
longer
getting
paid
to
do
this,
so
it's
only
what
I
can
squeeze
in
in
amongst
in
my
free
time.
A
So
we
would
really
really
appreciate
it
and
it'll
help
move
things
forward.
If
people
could
spend
the
time
spend
some
time
doing
some
really
deep
code
reviews
in
the
core
repository
when
there
are
dr's,
especially
around
metrics,
we
need
some.
We
need
some
very
careful
eyes
on
this
code
because
it's
complicated
and
it
is
the
core
of
everything
else
and
logs
too,
since
they're
we're
heading
towards
stabilization.
B
When
you
code
review
the
those
prs,
do
you
typically
pull
the
code
down
and
mess
around
in
there?
What
I'm
trying
to
think
of
like
actionable
things?
What
this
means.
A
But
when
I
say
deep
coders
I
mean
this
stuff
is
going
to
be
being
used
in
all
of
our
projects
everywhere,
and
it's
really
important
that
it's
right
and
that
it
is
very
highly
performant,
and
especially
the
correctness,
is
something
that
would
be
is
just
very
important,
we're
all
using
this
stuff
and
the
more
eyes
on
it.
The
better
it's
going
to
be
because
right
now,
it's
kind
of
I'm
able
to
give
some
cursory
reviews
and
jack
is
kind
of
writing
the
code.