►
From YouTube: 2022-03-17 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).
A
I
proposed
that
as
an
option
in
the
community
issue
about
this.
I
think
the
I'll
raise
it
again.
I
think
the
solution
was
if
we
can
get
the
hotel
calendar
to
enterprise
google
calendar,
then
there's
like
audit.
Oh
no.
D
A
Sergey
was
able
to
see
the
last
time
that
it
was
like
a
slack
that
it
was
the.
What
are
we
on
now
zoom
the
zoom
integration
that
deleted
it,
but
so
maybe
he'll
be
able
to
see.
A
A
Yeah,
I
we've
not
had
a
whole
lot
of
topics
lately.
I
do
want
to
celebrate
this
pr.
That
has
been
a
long
time
in
the
making
running
our
tests
with
java
17,
all
of
the
all
of
the
tests
with
java
17..
A
Through
this,
and
just
to
run
it
by,
it
seems
reasonable
to
me
to
we
would
just
I
just
wanted
to
go
at
the
the
steps
we
would
need
for
making
something
not
alpha
in
contrib
seem
like
about
the
same
as
for
instrumentation.
We
would
want
the
api.
A
Diff
workflow
automation,.
B
C
B
What's
the
status
on
on,
you
know
instrumentation
stability,
I
think
the
last
I
remember,
but
I
haven't
I
haven't
followed
up
with
this
in
a
while
was
I
thought,
tigran
proposed
that
if
the
schema
url
is
omitted
that
the
instrumentation
should
be
considered
unstable.
B
And
then
was
there
additional
kind
of
some
sort
of
additional
indication
that
we
are
putting
in
code
to
indicate
that
the
that
it's
unstable,
like
some
sort
of
annotation
or
anything
or
just
you,
know,
omitting
the
schema
url.
A
Oh
yeah,
I
was
just
confused
by
the
assignee.
Thank
you.
Yeah
tigran
left
that
to
do
sort
of
question
open.
A
Yeah
I
had
to
do
to
decide
if
we
need
to
define
how
unstable
instrumentation
is
indicated
on
the
wire.
Is
this
kind
of
your
question
jack.
B
Yeah,
I
guess
it's
related,
so
so
does
the
omission
of
a
schema
url
indicate
that
it's
not
stable?
I
think,
if
that's
yes,
you
know,
is
he
saying
that
you
can't
include
a
schema
url
but
that
in
itself
it
doesn't
doesn't
indicate
stability
right.
A
Right
because
that
that's
what
anthony
was
questioning.
A
A
Are
the
only
exception
sort
of
has
been
for
the
java
agent
since
it's
a
distribution?
It's
like
a
bundle
of
lots
of
things.
We
will
mark
things
incrementally
as
stable
telemetry
is
stable
within
the
java
agent.
C
Yeah
then
again,
it's
I
think
it's
a
good
question
like
if,
if
we
introduced
semantic
conventions
for
maven
and
they
were
released
and
aspect
release,
would
that
be
enough
for
a
stable
release.
A
B
Well,
do
you
need
semantic
inventions
in
order
for
us
to
emit
stable
telemetry
so
like,
let's
say
we're
instrumenting,
some
kind
of
esoteric?
You
know
java
specific
library,
but
it's
really
stable.
Do
we
need
to
write
semantic
inventions
for
those
or
can
we
just
emit
the
telemetry
say
that
it's
stable
and
let
it
be
so
yeah
good
point
so.
C
A
If
we,
I
think,
if
we
want,
would
stable
just,
I
think,
from
the
spec
perspective,
stable
means.
Just
I
mean
the
there
were
rules
in
that
doc
about
not
no
breaking
changes.
Yeah.
A
You
can
create
new
new
new
stuff
new
attributes.
Definitely
I
thought
new
spans.
A
F
A
A
B
Just
just
to
confirm
what
you
said
earlier,
because
I
wasn't,
I
wasn't
quite
sure
I
understood,
but
so
in
the
java
instrumentation
project.
B
A
A
It's
good
to
know,
and
I
think
that
fits
the
so
here.
A
Let's
see
documentation.
A
Yeah,
so
stable
telemetry
producing
instrumentation
should
be
labeled
by
this,
and
this
was
kind
of
where
we
discussed
about
the
java
agent
should
be
labeled
by
any
means
that
we
consider
idiomatic
version
number
is
the
most
obvious,
though,
and
most
so
I
think
version
number
is
the
best
where
we
can
do
that.
A
B
B
So
then,
I
suppose,
then
at
least
to
me
it's
becoming
kind
of
clear
the
answer
to
his
question.
You
know.
In
order
to
mark
the
maven
module
is
stable,
we
would
need
to
minimally
have
the
the
schema
the
stable
schema
included
in
the
contrib
repository
at
a
url
that
could
be
referenced.
F
Like,
realistically
speaking,
is
there
like
enough
interest
to
like
to
do
all
like
the
semantic
conventions
and
stuff
for
the
maven
extension?
Maybe
it
doesn't
have
like
the
user
base.
E
And
is
having
is
having
some
amount
of
test
coverage
even
required
for
stability
declaration.
I
think
it's
not
right.
I
mean
it
makes
common
sense
to
all
of
us,
but
it's
not
is
that
actually
part
of
it,
it
shouldn't
be
required
for
a
pr
in
the
first
place
I
mean
I'd,
see
where
jack's
coming
from.
I
think
we
all
want.
That
would
be
great,
but.
B
Oh,
I
wasn't
talking
about
test
coverage.
I
was
just
saying,
like
you
know,
it's
admitting
telemetry
in
this
particular
shape.
You
know
I
haven't
used
it
before.
Is
that
actually
the
right
way
to
represent
the
data
are
the
right
attributes
present
that
type
of
thing,
because
once
you
once
you
say
that
that's
stable,
you
can't
you
can't
you
can't
hit
the
undo
button,
got
it
you're,
talking
more
about
like
validation,
yeah,
yeah,
yeah.
A
Yeah
my.
A
F
B
D
I
I
have
some
quick
feedback
for
this
one.
We
have
this
issue
like
all
the
time
that
means
like
every
single
week.
There
is
somebody
who
is
asking
us
about
like
the
open
telemetry
stability,
mostly
for
tracing
because
of
sleuth
hotel
and
like
tracing,
is
marked
as
stable,
but
it
isn't
so.
This
causes
a
lot
lots
a
lot
of
confusion
for
the
users,
so
if
you
can
fix
it
for
this
one,
that
would
be
desirable,
ideally
from
the
user
perspective.
F
Do
they
want
just
like
the
declaration
of
stability,
but
really
don't
care
about
the
stable
telemetry?
I
assume.
F
Like
are
the
users
complaining
because
it
isn't
called
stable
like
to
the
care
that
it's
called
stable,
not
not,
that
it
produces
stable
elementary.
B
D
I
am
talking
about
the
open
developer,
tracing
instrumentation
api.
Oh
the
instrumentation
api.
Okay,
this
one
is
in
alpha
and
tracing
as
as
all
like,
open,
telemetry
io
says
it's
stable.
If
you
ask
people
on
slack,
they
just
say
it
is
stable,
but
there
are
still
alpha
version
in
tracing.
A
Those
you
mean
these,
you
mean
the
sdk,
the
metrics
sdk,
that
it
brings
in.
A
B
Well,
metrics,
the
sdk
is
still
unstable,
so
you
know
we're
trying
to
get
that
as
stable
as
fast
as
possible,
but.
B
So
that's
explainable,
so
yeah,
I
think
it's
kind
of
complicated
because
there's
layers
this
stuff,
you
know
there's
the
the
core
api
and
sdk,
and
then
on
top
of
that,
there's
this
abstraction,
which
is
the
instrumentation
api
and
then
all
the
instrumentation
produces
telemetry,
and
so
each
one
of
those
things
has
its
own
kind
of
path
to
maturity.
B
So
you
know,
depending
on
who
you're
talking
to
you'll,
get
a
different
interpretation
of
like
which
specific
layer
they're
referring
to,
and
it's
perfectly
accurate
to
say
that
the
tracing
sdk
and
api
are
stable.
C
Yeah
and
to
be
fair,
we
so
we
are
still
making
some
backwards
and
compatible
changes
in
the
instrumentation
api,
like
recently
deprecated
a
lot
of
methods.
I
don't
even
remember
how
many
so
yeah
there's
probably
still
some
work
that
needs
to
be
done
there
and
with
like
actually
with
instrumentation
api,
there's
a
quite
bigger
problem,
because,
even
if
we
fix
like
even
if
we
clean
up
the
code,
complete
and
fix
all
the
replicated
and
weird
stuff,
there's
the
question
that,
should
we
even
mark
the
instrumentation
api
as
stable?
C
If
the
semantic
conventions
are
not
stable,
I
mean
we
have
packages
that
serve
as
the
base
or
scrat
implementation
for
http,
instrumentations
data
based,
instrumentation
and
so
on,
and
if
the
underlying
semantic
conversions
can
change
these,
the
the
classes
in
this
packages
will
also
change.
So
does
it
even
make
sense
to
make
this
slip
market
as
stable
without
the
semantic
conventional
stability.
B
Yeah,
how
much
value
does
the
instrumentation
apei
provide
without
those
kind
of
components
that
kind
of
embody
the
various
semantic
inventions.
C
Yeah,
so
I
actually
had
an
idea
to
split
the
instrumentation
api,
like
the
instrumentation
api
core
from
instrumentation
api
semcons,
but
yeah.
It
has
like
very
limited
usability.
I
mean
okay,
we
declare
stability
on
the
interfaces
like
attributes,
extractor
or
spam
name
extractor,
but
that's
pretty
much.
All.
D
Also,
even
if
like,
for
example
like
there
is
a
chain
in
changing
the
same
content,
you
will
be
able
to
like
make
the
the
connecting
chain
in
the
instrumentation.
That
still
mean
a
breaking
change
in
the
behavior.
A
So
I
think
we
I
mean
materials,
I
like
the
the
idea
of
splitting
because
we
have
to
plan
for
incrementally
stabilizing
those
things
anyway,
because
you
know
we'll
get
maybe
http
and
messaging
in
the
next
six
months.
I
know
I
said
that
six
months
ago
also,
but
you
know
the
other
ones
are
gonna,
be
you
know
in
a
year
or
longer
and
so
yeah.
So
I
I
I
really.
I
I
really
like
that
idea.
C
Okay,
I
will
create
an
issue
for
that,
so
that
it's
not
lost,
and
you
know
it's
not
just
an
idea
floating
around
in
my
head
and
yeah.
I
I
think
it's
quite
doable
right
now,
there's
not
that
much
code.
If
you
remove
the
cement
the
stuff,
that's
related
to
some
other
conventions
in
the
instrumentation
api.
D
A
quick
question
connected
to
this:
do
you
happen
to
know
if,
if
there
is
any
vote
map
for
the
semantic
conventions,
when
is
there
any
eda
to
be
declared
as
stable.
B
D
Or
the
whole
thing,
or
do
you
happen
to
know
if
they
have
like
a
nice
list
of
what
is
left,
because
I
remember
the
like
the
instrumentation
had
like
a
huge
issue
with
90
something
items
that
was
that
was
so
cool.
I
really
loved
it
because
I.
D
To
track
every
week,
okay,
like
how
far
is
it
do
you
happen
to
have
know
if,
if
some
conf
has
like
something
where
we
can
track
where
they
are.
B
That's
that's
kind
of
a
tricky
question
because
I
I
mean
I'd
say
that
the
semantic
inventions
are
like
a
never-ending
list.
They'll
never
really
be
done.
They'll
always
be
like
an
additional
semantic
invention.
That's
you
might
want
to
define
someday
there's
like
kind
of
in
my
head,
there's
like
a
key
handful
of
really
important
ones.
You
know
http
and
messaging
being
really
high
up
there.
D
I
believe
that's
totally
all
right,
but
like
70,
conversions
should
define
like
a
1.0
something
or
a
stable
version
at
some
point
and
after
that
they
will
be
just
like
adding
like
additional
changes.
So
not
not
breaking
ones.
A
A
So
there's
definitely
plans
if
we
find
yeah
check
these
out
and
then
this
additional
otep,
so
sort
of
the
oteps
are
where
some
of
those
plans
are
being
made,
and
I
think
yeah
so
like
in
this
one.
You
know
the
goal
was
to
declare
http
stable
end
of
you
know,
end
of
march.
A
A
But
if
you
have
any,
if
you
have
questions
here
and
you
know
don't
want
to
filter
through
all
the
spec
pr's
ask
ask
this
group,
because
many
of
us
follow
all
the
spec
stuff.
So
we
can
at.
F
A
Level,
at
least,
if
we
don't
read
through
all
the
gory
details,
we
can
help
point
you
in
the
direction.
B
My
feeling
is,
though,
that
they're
not
going
to
wait
for
like
some
set
of
the
domains
to
reach
the
domains
within
the
semantic
inventions
to
reach
stability,
and
then
say
the
semantic
inventions
are
1.0.
B
The
the
specification
is
like
kind
of
a
like
has
a
version
holistically
that
that
you
know
that
you
know
it's
on
1.9.0
right
now
and
as
soon
as,
for
example,
http
is
marked
stable.
The
next
version
of
the
specification
altogether
will
have
at
least
one
part
of
the
semantic
inventions
as
stable
within
it,
and
it
will
just
grow
as
more
domains
are
stabilized.
D
So
for
semantic
conventions
like
suit,
has
an
instrumentation
for
messaging
as
well
and
like
for
a
lot
of
stuff
like
jdbc
and
so
on.
So
for
us,
semantic
conventions
is
not
really
a
blocker
for
sleuth,
but
it
is
like
a
transitive
blocker
because
of
the
instrumentation
api.
A
So
if
we
released
say
we
released
instrumentation
api
as
stable,
with
no
semantic
conventions
like
no
http
with
just
the
attributes
extractor,
you
know
the
interfaces,
but
no
http
attributes
extractors
does.
That
is
that
all
that
you
need
from
sleuth
or
I
believe
we
are
using
the
http
attributes
extractor.
D
I
am
not
100
sure
about
the
messaging,
but
not
the
database.
I
guess.
A
A
D
Like
what
do
you
mean
like?
Have
the
users
in
you
know?
What,
because
like
right
now,
I
guess
like
auto,
being
like
not
stable
or
tracing
being
not
stable
is
not
a
big
issue.
For
that
we
can.
We
can
wait.
Users
are
like
they.
They
can't
try
it
out
if
you're
not
like
release
like
stupid,
lga
till
like
instrumentation
is
not
nothing
in
ga.
A
So
what
I'm
trying
to
think
of
is,
like
I'm
worried
that
this
might
be
a
blocker
for
you
know
another
year
for
you.
A
A
D
Also,
I
am
not
sure
if
there
are
like
still
like
breaking
changes
on
things
that
that
that
we
would
use
like
once
once
you
do
this,
this
move
or
this
separation.
D
We
can
begin
checking
sleuth
like
what
what
are
the
components
that
we
are
still
using
from
the
from
the
unstable
part,
and
we
can
focus
on
that
and
figure
out
something,
because
so
sleuth
3
was
released
a
few
months
ago.
That
means
that
open
source
support
will
go
away
at
the
end
of
this
year.
D
So
maybe
we
can
release
something
and
and
say
that
hey
we
are
deviating
promotal
for
for
this
year
and
like
that,
that
version
will
will
go
away
eventually.
So
we
can
like
introduce
breaking
changes
like
later.
F
A
Need
to
split,
probably
anyways
and
then
revisit
that.
A
Yeah,
I
would
love
to
help
you
all
get
stable
or
release
that
if
we
can,
because
I
know
that
that's
been
a
thorn,
thorny
issue
for
a
long
time.
A
Cool
any
thing
else
that
we
should
chat
about
today.
D
I
have
a
very
quick
one.
I
have
created
the
the
jpm
cpu
pr,
so
the
the
comments
should
be
should
be
resolved.
A
A
Oh,
I
was
going
to
because
whenever
I
go
and
whenever
I
go
and
search
here
for
you-
and
I
don't
find
you
I
think
of
telling
you
anytime-
you
want
to
join
the
hotel.org
github
org,
the
just
use,
you
know
any
two
of
us
as
your
sponsors
and
who
would
love
to
have
you
in
the
drop
down.
So
I
don't
have
to
jonah
jonathan
I'm
a.
A
Okay,
awesome
anything:
you
think
that
we
should.
A
A
So
you
wanted
the
elastic.
F
A
Lock,
yes,
I
can
fire
that
off
today.
F
C
A
So
it
when
we
introduced
that
jdk
that
weird
loading
for
the
java,
the
jpms,
the
weird
loading
of
the
sunnet
http
server
for
prometheus.
Yes,
we
had
to
do
some
weird
class
letter.
Laurie
did
some
cool
and
weird
glass
loader
stuff,
more
more
weird
at
the
cool
class
loader
stuff,
and
but
we
didn't
mark
that
class
loader
as
parallel,
and
so
it
would
take
out
locks
on
the
whole
class
loader
and.
A
Yeah,
so
my
my
fix
was
initially
super
calling
super
load
class
here
and
basically
just
adding
the
register
is
parallel,
but
laurie
had
the
brilliant
idea
to
call
class
for
name
because
that
doesn't
then
even
take
that
lock,
because
the
lock
is
the
the
lock
is
in
the
super
load
class.
A
But
I
left
this
here
just
in
case
because
it
freaked
me
out
because
it
was
real.
I
was
so
confused.
I
was
looking
at
this
deadlock
stack
traces
and
it
didn't
match
the
source
code
right
in
the
source
code.
I
was
I
kept
thinking.
It
was
the
the
locks.
A
Well,
it
did
match
the
source
code,
the
class
loader
source
code
after
I
read
it
correctly,
but
yeah
it
was
confusing.
B
Yeah
so
ottawa
and
I
have
been
doing
some
passes
at
the
metrics
sdk
to
limit
the
api
interface,
the
public
api
as
much
as
possible.
I
think
and
make
sure
it's
tight
before
you
know
we
hopefully
stabilize
it,
and
one
of
the
things
that
I
was
taking
a
look
at
was
how
you
register
metric
readers
and
there's
this
kind
of
roundabout
process
where,
when
you
register
a
metric
reader
with
an
sdk
meter
provider,
you
register
what's
called
like
a
metric
reader
factory
and
a
factory.
B
Is
you
know?
B
Basically,
it
just
is
a
simple
interface
which
you
it's
provided
a
metric
producer
and
you
return
a
metric
reader
in
response,
and
it
seems
it
like
unnecessarily
complex
and
like
we
have,
you
know
extra
classes
and
methods
exposed
that
we
don't
want,
and
so
this
pr
proposes
simplifying
it,
but
in
the
process
I
also
propose
that
we
remove
the
ability
for
custom
implementations
of
metric
reader
for
now,
unless
you
take
a
dependency
on
an
internal
class,
and
so
my
question
is:
is
anybody
trying
to
register
metric
readers
besides
the
built-in
ones,
so
the
built-in
ones
being
like
the
prometheus
collector?
B
That's
a
metric
reader,
in-memory
metric
reader
for
testing
and
then
the
big
one
is
periodic
metric
reader,
which
you
know
runs
a
background
thread
and
periodically
pulls
for
metrics
and
pushes
those
to
some
exporter.
You
configure
it
with
so
does
anyone
have
any
use
cases
outside
of
that
that
they're
aware
of.
A
D
I
I
might
have
two
one
is
if
it
can
be
useful,
if
you
want
to
add
like
another,
like
support
for
another
back
end,
which
is
not
prometheus
or
dip,
and
you
need
to
like
push
it
there.
I'm
not
sure
if
this
will
ever
happen,
but
it's
it's
it's
it's
an
option.
D
Another
possible
use
case
I
can
think
of
is
when
you
want
to
like
debug
your
instrumentation,
and
you
want
to
query
okay,
what
are
the?
What
are
the
instruments
I
have
right
now
and
I
print
it
out
on
demand
not
necessarily
like
in
a
in
a
schedule
to
the
logs
but
or
like
to
do
system
out,
but
you
can
see
that
hey
after
this
happened,
I
wanted
to
see
like
what
what
what
meters
do.
I
have.
B
If
you
want
to
print
them
out
to
system
out,
you
can
use
a
periodic
metric
reader
with
a
you
know
like
a
logging
metric
exporter
that
just
receives
them
and
prints
them
the
console
out,
and
if
you
want
to
do
that
on
a
cadence
that
is
outside
of
the
the
interval
that
you've
configured
your
periodic
metric
reader
with
you
can
flush
the
the
meter
provider
to
force
to
forcibly
send
those
to
the
to
the
council,
not
sure
if
that
satisfies
what
you're
thinking.
D
I
I
think
it
does
like
whenever
I
can
get
it
like
owned
event,
like.
B
You
can
call
the
sdk
meter
provider
sdk,
meter
provider,
flush
that
will
forcibly
you
know,
send
the
metrics
to
any
readers
that
you've
configured.
A
Now
do
we,
if
we
remove
it
for
now
and
if
we
need
it
later,
does
that
is
it
just
a
layering
in?
Do
we
lose
anything
by
any
design
choices
by
removing
it
initially.
B
The
the
way
that
I
see
it,
the
only
change,
is
if
we
wanted
to
allow
custom
implementations
of
metric
reader
later,
would
be
an
additional
method
on
the
metric
reader
interface,
and
this
method
would
be
called
something
like
register
or
something
like
that,
and
you
know
upon
initialization
of
the
sdk
meter
provider.
It
would
call
register
on
its
configured
readers
and
provide
it
those
each
reader
a
hook
that
the
reader
can
use
to
collect
metrics,
and
so
it's
that
kind
of
pairing
process
that
needs
to
be
exposed
publicly.
B
B
So
only
a
couple
of
implementations
have
that,
because
that
part,
that
exchange,
isn't
it's
it's
not
specified
and
there's
discussions
at
the
at
the
spec
level
like
do
we
need
to
do.
We
need
to
define
additional
components
for
that,
or
you
know
you
know,
and
another
question
that
came
up
altogether
was
this
one
is
like:
do
we
even
allow
for
custom
implementations
of
metric
reader
for
now,
and
so
in
light
of
that,
I
thought
that
we
should
limit
the
surface
area
until
it's
more
explicit.
A
Cool
then
look
out
for
one
twelve
one
and
see
y'all
next
week
see
ya.