►
From YouTube: 2022-01-06 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
D
B
D
Well,
I
don't
think
I
mean
we,
don't
I'm
not
talking
about
cost,
I'm
talking
about
the
annoyance
of
having
to
go
through
the
process
of
asking
for
more
repositories
containing
them
and
managing
them,
and
a
lot
like
we've
seen
how
much
of
a
pain
it's
been
just
for
contributing
docs
to
try
to
coordinate
all
that
crap.
D
Well,
I
think,
rather
than
complaining,
jason,
you
should
actually
make
something
happen.
C
All
right
welcome
everyone
to
2022.
D
Yeah,
so
I
think
we're
planning
on
releasing
110
this
week,
so
if
there's
stuff
that
needs
to
be
in
people
should
call
it
out.
Otherwise,
I
think
I'll
chat
with
honorog
this
evening
and.
C
Awesome,
I
saw
you
merged
the
auto
configure
log
auto
configure
configuration.
That
is
a.
C
Hello
configuration
this
is
gonna,
I'm
looking
forward
to
pulling
this
into
our
the
instrumentation
repo,
because
we've
started
writing
logging
instrumentation,
but
it's
not
actually
usable.
Yet
without
the
auto
configuration
of
the
log
exporter.
E
I
have
I
have
an
outstanding
pr
about
async
instruments,
so
when
you
register
multiple
callbacks
for
the
same
async
instrument
and
there's
been
some
discussion
on
this
with
matej,
you
know
he's
ran
into
some
issues
where
the
micrometer
instrumentation
is
registering
multiple
callbacks
and
he
has
a
solution
where,
instead
of
like
registering
multiple
callbacks
with
the
meter,
he
has
a
mutable
callback
that
composes
the
callbacks
that
he
can
register
things
to
and
unregister
callbacks
from.
E
E
Yeah
right
there
405
one,
and
we
can
consider
that
the
spec
is
ambiguous
on
what
the
behavior
should
be
in
this
situation,
and
so
I
think
that
this
needs
to
be
resolved
at
the
spec
level.
But
for
now
the
behavior
is
actually
really
confusing
in
the
sdk.
If
you
register
multiple
callbacks
for
the
same
instrument,
we
just
silently
ignore
any
callback,
that's
registered
after
the
first
one
and
and
so
like.
If
you
accidentally
do
that,
it's
it's
hard
to
figure
out
why
your
callback
isn't
being
invoked.
So
if.
E
So
the
pr
that
I
have
is
just
to
log
when
this
situation
happens
and
we
can
always
roll
that
back,
and
you
know
change
the
behavior
to
like
if
multiple
callbacks
happen
to
compose
them,
but
yeah
just
just
curious.
If
we
should
get
this
in
before
the
release.
D
D
D
E
What
we
could
we
could
solve
this
later
by
you
know
providing
a
utility
that
did
just
this
so
mittayusha's.
You
know
composable
callback,
type
thing
where
you
know,
instead
of
passing
a
call
back
directly,
you
pass
like
a
callback
that
can
compose
other
callbacks
and
you
can
control
the
logic
by
what
you
add
and
remove
callbacks
from
that
anyone
can
do
that
right
now,
right
right,
we
don't
need
to
have
an
api
for
that.
No,
no!
B
E
Fair,
so
I
I
think
there's
this
metrics
sig
tonight
at
four
pacific
time,
so
I'll
bring
this
up
there
and
and
open
an
issue
at
the
spec
level
to
try
to
address
this.
But
that's
just
a
question
that
I
have
about
the
release
tomorrow.
C
Cool,
so
let's
I
I
wanted
to
share
what
we're
doing
started
doing
in
the
contrib
repo.
C
So
we've
got
two
of
these
components:
have
component
owners
now
so
we're
trying
to
use
the
github
code
owners
to
manage
manage.
C
You
know
people
getting
assigned
reviews
so,
for
example,
for
the
maven
extension,
ken
and
cyril
are
have
been
owning
that
component,
but
with
we
and
other
open
telemetry
repos
have
run
into
this
problem.
Also
where
the
code
owners
you
have
people
in
the
code,
owners
file
have
to
have
right
access
to
the
repo
for
them
to,
for
any
forget,
have
to
do
anything
about
it
for
them
to
be
real
code
owners,
so
without
that
github
won't
assign
them
to
reviews
in
particular.
C
That's
the
important
thing
is
we
want
people
to
be
assigned
to
the
reviews
automatically
so
dan
from
the
javascript
sig
created
a
a
github
action
that
reads
that
basically
sort
of
duplicates
the
code
owners
but
from
those
component
owners.
So
we
can
list
here
and
it
will
then
on
prs
it'll
automatically
assign
these
folks
as
both
reviewers
and
assignees,
which
is
kind
of
nice
to
see.
Let's
see
this
doesn't
have
opened
yesterday.
Maybe
this
was
before
I
created
that
yeah.
I
think
so.
C
So
what
I
wanted
to
bring
up
was
it
would
be
nice
to
have
two
component
owners
for
each
component.
That
way
if
one
of
the
component
owners
submits
a
pr
there's
the
other
component
owner
to
do
the
initial
review.
At
least
the
repo
wide
approvers
still
have
to
approve.
C
That's
the
only
way
we
get
the
green
check
mark
and
merge,
but
that
can
be
more
of
a
rubber
stamp
and
so
wanted
to
ask
for
volunteers
for
any
of
these
components
to
be
component
owners
and
even
if
you're,
already
an
approver
on
the
in
the
contrib
approver
maintainer
in
the
contrib
repo,
it
would
still
be
nice
to
list
one
of
us
explicitly
in
here.
So
we
know
who
owns
those
sort
of
initial
reviews.
C
Anybody
else
been
involved
in
the
jmx
metrics.
C
Not
really
it's
pretty
much
been
ryan
anybody
interested
in
the
disrupter
processor
did
we
send
it
over
there
to
die.
D
C
C
All
right
thank
y'all
all
right,
the
big
one
for
instrumentation
99
tasks
done.
Yes,
thank
you
to
everybody
who
participated.
It
was
a
big
effort
over
lsu.
When
did
we
open
this
april?
All
right.
C
C
A
C
Instrumentation
yeah,
we
don't
we
currently,
we
currently
does
this
affect.
Oh,
I
guess
the
problem
here
is
that
we
don't
have
a
way
to
for
people
to
we
hard
code.
Oh
that's
right.
We
always
get
it
from
the
manifest.
Is
that
the
problem
here.
A
A
A
A
C
E
A
there's
an
open
issue,
though,
to
accept
schema,
url
and
version
in
the
instrument
or
api
right.
C
A
A
E
C
C
A
A
A
C
C
Sure
enable
exclude
option
to
exclude
query
string.
Do
you
think
this
is
really
required
for
api
stability,
because
this
would
just
be
an
additional
config
option.
C
C
Okay,
we
do
need
to
decide
finalize
on
that
type.
Annotation
placement-
I
don't
think
this
is
this-
affects
any
stability
right.
This
is
just
yeah
and
I
think
we
already-
I
think,
we're
decided
on
this
I'll
I'll
revisit
this
later,
but
I
don't
think
it's
required
anyway.
C
Right
but
a
java
agent
extension
not
instrumentation
api.
C
A
C
Yeah,
except
that
we
have
several
people
external
folks,
waiting
for
instrumentation
api,
specifically.
A
C
Okay,
but
can
we
maybe
create
a
separate
project
for.
A
Yes,
please
leave
otherwise
I
will.
I
will
have
trouble.
C
Yeah
again,
yeah
attributes
extractor
set
okay.
So
that's
just
that
we
have
to
decide.
Oh
yeah.
This
is
related
to
your
other
topic.
You
put
on
yeah
and
nikita.
C
Okay,
yeah,
not
that
we
could.
This
could
be
added
later
after
stability,
but
it
makes
sense
to
think
about
this
in
the
context
I'll
we'll
I'll
leave.
This
yeah
makes
sense
to
think
about
yeah,
okay,
awesome,
so
any
questions
from
anybody
on
the
phone
about
the
instrumentation
api
stability.
C
I
guess
there
was
the
question.
We've
discussed
this
a
few
times
semantic
convention
stability.
How
can
semantic
convention
stability
effects,
instrumentation
api.
C
In
particular,
because,
for
example,
some
of
the
let's
look
at.
C
So
we
have
methods
like
target
flavor
route
scheme
host.
These
are
all
things
that
are
defined
in
particular
target
is
the
one
that
I'm
slightly
concerned
might
change
well,
partly
because
I
opened
a
spec
issue
asking
for
it
to
be
changed.
So
that's
my
fault.
C
A
G
Regardless
of
of
this
like
target
path
and
query
issue
like
can
you
say
that
something
is
stable
if
its
dependency
is
not
like?
You
are,
depending
on
the
on
the
semcon
specification
right
and
if
it
is
not
stable,
then
the
api
cannot
really
be
stable.
G
Those
as
well
like
anything
which
is
coming
from
the
semantic
conventions
like
because
if
it
is
still
like
in
experimental
phase,
I
guess
if
they
like
change
something
rename
something
remove
something
that
means
that
the
api
needs
to
follow
it.
So
if
the
semantic
conventions
are
not
stable,
the
api
cannot
be
stable
or
at.
A
Just
so
here
you
know,
that's
exactly
the
question,
so
we
currently
have
api,
which
is
like
mirrors,
semantic
convention
names
which
can
change,
and
that
is
yes.
We.
C
G
Yeah,
my
like
what
I
see
is
is
more
like
conceptual,
like
the
semantic
conventions,
define
some
things
and
how
to
name
them
and
the
api
must
follow
them.
So
if
semantic
conventions
like
break
those,
then
the
api
must
break
those
as
well.
I
guess.
C
Yeah,
it's
it's
a
problem
and,
and
the
database
like
the
http
semantic
conventions
are
at
least
somebody
is
they're
approaching
stability.
I
think
the
trying
to
get
it
stable
by
march.
I
don't
know
if
that
will
really
happen
or
not,
but
at
least
there's
like
a
work
stream
and
working
group
working
on
it,
whereas
like
and
same
with
messaging
but
database,
for
example,
there's
nobody
there's
no
work
stream
currently
on
stabilizing
that
this.
C
So
it's
a
big
risk
item.
If
we
mark
it
stable
one
thought
we
had
had
was
you
know
we
could
put
like
a
verge
like
a
v1
kind
of
package.
For
these.
A
C
G
C
Okay
yeah,
so
this
is
the
big
question.
Then
it
sounds
like
because
that
the
list
of
sort
of
specific
tasks
didn't
look
too
bad
for
getting
to
stability.
C
Okay,
let's
revisit
again
with
I'll
I'll
revisit
again
with
anurag
this
evening,
see
because
we've
discussed
this
a
few
times
before
see
what
his
latest
thoughts
are
and
then
let's
discuss
it
again
next
week
and
yeah,
I
agree
with
you
nikita
that
that
is
that
could
be
the
next
step
for
this
group.
Then.
C
C
Cool,
I
don't
think
we
have
I
passed
for
that,
but
maybe
will
you
create
one
for
that
project.
A
C
A
C
Somebody
gets
the
honor
of
deleting
all
the
all
the
base
tracers.
C
I
don't
know
I
was
thinking,
I'm
not
sure,
my
off
the
top
of
my
head.
I
was
gonna
guess
that
laurie
probably
closed
the
most
of
these.
I
don't
know.
B
C
Did
a
lot
also
but
yeah,
giving
that
honor.
C
All
right
cool,
yeah
nikita
you
have
a
pr
here.
A
C
C
Cool
yeah
sue.
C
I
won't,
I
won't
try
to
or
jack
do
you.
You
work
a
lot
in
the
sdk
repo.
Have
you
dealt
with
the
j,
a
p,
the
api
comparison
files
like
do
you
have
to
run
my
understanding?
Is
you
have
to
run
something
locally
to
regenerate
them
and
check
them
in
so.
E
Like
just
just
with
with
every
pr,
if
you
don't
run
a
build
locally,
then
those
files
won't
be
generated
and
then
like.
So
if
you,
if
you
don't
run,
if
you
don't
generate
those
files-
and
you
merge
your
pr
to
main
then
like
each
time,
you
run
a
build
locally
on
main
there'll,
be
like
a
diff.
That's
generated
so
like
so
that's
a
bit
of
a
problem,
but
it's
not
a
huge
deal
and
somebody
will
have
to
like
make
up
that
diff
later
with,
like
a
subsequent
beer.
C
F
In
api
into
merged
code,
yes
yeah,
you
can.
C
Yeah
I
was
hoping
that
that
the
build
could
like
regenerate
them
and
then
fail
the
build
if
there
was
anything
any
changes
under
git.
E
Yeah
I've
done
stuff
like
that
in
the
past.
You
know
basically
do
a
diff
detection
after
you
run
your
build
and
you
know
if
there's
any
diff
that's
detected,
then
something's
awry.
E
Because
I'm
with
you
it's
it's
easy
for
pr
reviewers
to
overlook
breaking
changes
and
to
let
something
in
that
they
don't
expect.
C
Cool
all
right,
I'll
I'll
I'll,
summarize
nikita
what
would
discuss,
but
I
think
my
thought
is
the
way
that
they
do.
It
makes
sense
to
me
in
that,
like
it's
under
source
control,
we'll
always
regenerate
them
under
source
control,
then
we
can
have
that
pr
build.
C
Do
the
diff
and
having
them
under
the
build.
Folder
won't
allow
that
kind
of
a
diff
during
ci.
A
A
Like
why
why
I
raise
that
issue
is
because,
like
I,
I
work
on
all
those
different
ways
to
make
sure
that
we
work
properly
with
gradle
caches
and
gradle.
Up-To-Date
checks
and
some
experiments
fail
because,
like
we
generate
something
that
is
not
cleaned
by
clean,
but
that's
not
the
part
of
the
actual
repository,
because
if
you
make
a
clone
nearby,
you
will
not
have
those
files.
C
A
Because
they
like,
if
I
try
to
make
sure
that
I
can
that
I
can
run
like
build
from
two
different
locations
on
my
computer
and
the
gradle
cache
will
be
reused.
A
C
Opt,
if
is
it
part
of
that
problem,
because
we're
generating
them
in
lots
of
places
that
that
aren't
added
to
source
control
right
like
what,
if
we
only
generate
them
in
modules
that
we
want
them
to
be
checked
in.
A
C
C
A
C
A
A
C
Right,
but
if
you
don't
add
so
the
reason
I
sort
of
think
it's
intentional
is
say
you
want
to
think
about
a
take
a
health
check
for
an
example.
You
want
to
suppress
a
health
check
and
you
want
to
suppress
the
nested.
A
A
C
C
A
E
What
about
so,
okay,
so
you'd
want
to
get
rid
of
internal
spans
because
they're,
just
noise,
sometimes
they're,
there's
too
much
data
there
and
they're.
Just
not
that
of
that
much
consequence,
but
they're
needed
to
retain
the
hierarchical
relationship
between
the
parents,
band
that
you
want
and
the
client
span
somewhere
down
the
link.
E
A
Yeah,
that's
one
way
to
solve
it.
I
believe
my
first
problem
currently
is
that
we
adva
we
recommend
people
left
and
right
that
please
write
custom
sampler
if
you
want
to
make
some
strange
decisions
about
to
span
record
so-
and
I
still
think
that's
a
good
thing.
Yes
right,
custom
temperatures
if
you
want
to,
but
probably
we
have
to
somehow
warn
people
that
if
you
want
to
use
non-parent
based
samplers,
then
that
will
not
work.
Don't
do
that
and
go
some
other
way.
C
C
Right
so
I
see
what
you're
saying
is:
essentially
you
want
to
know
almost
who
want
to
you
want
to
know
if
it's
parent-based
or
not,
whether
to
oh
yeah,
I
don't
know
how
to.
B
A
F
C
Deep,
we
have
hit
our
time,
but
I
did
want
to
give
a
quick
logging
update
because
there's
this
is
gonna,
be
a
big
new
feature
in
the
1.10
release,
which
our
the
instrumentation
110
release
will
probably
be
hopefully
end
of
next
week
so
a
week
after
the
sdk
release,
but
we
have
now
log
back
log4j
and
java
util
login
instrumentation
that
will
capture
the
logs
so
like
a
pender-based
instrumentation,
both
in
the
java
agent
and
stand-alone
appenders
for
log
back
and
log4j
that
will
capture
the
logs
and
send
them
out
over
the
alpha
log
exporter
signal.
C
So
that's
pretty
cool
progress
and
we
had
some
good
discussion
around
how
to
deal
with
the
like,
because
there's
a
logging
sdk,
but
there's
no
logging
api,
and
so
we
built
a
an
appender
api
sort
of
in
our
repo
api
dash
appender
for
instrumentation
to
use.
C
But
after
some
further
discussion
in
the
spec
repo,
we've
decided
that
this
should
we
basically
really
don't
want
to
expose
anything
that
looks
like
a
logging
api,
so
we're
gonna
make
this.
Basically,
we
still
need
this
artifact.
We
still
need
it
to
be
sort
of
from
the
instrument.
The
instrumentation
needs
something
to
use,
but
also
we
need
something
in
the
java
agent
to
bridge
and
but
we're
gonna
make
it
all
internal
hide
it.
C
Basically,
in
an
internal
module
internal
package,
I
think
we
had
some
proposed
some
names
in
yeah,
maybe
something
like
instrumentation
logging
internal,
so
that
it's
clear
that
other
people
should
not
use
that.
F
C
C
So
if
you're
using
slf
for
j
simple
or
we
did
get
some
user
who's
using
jboss
logging-
I
don't
know
if
that
is
based
on
slf
for
j
or
something
different.
But
that's
something
we'll
probably
need
to
look
at
cool
thanks.
E
C
C
All
right,
sorry,
we
hit
time
did
not
do
my
moderating
job
closing
this
off
great
to
see
everybody
until
next
time
see
ya.