►
From YouTube: 2021-11-23 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
A
Excellent,
perhaps
for
one
more.
C
Yeah,
I
think,
we'll
start
focus
on
the
pro
the
joint
map
to
general
availabilities,
I
think
open
elementary.
They
have
a
documentation
that
set
us
to
be
generally
available
next
q2
next
year.
I
think
okay,
how
to
find
that
somewhere.
A
Yeah
seems
like
it
could
be
worth
maybe
reviewing
the
the
sort
of
outstanding
pieces
I
mean
I,
it
does
appear
to
be
mostly
feature
complete
from
a
tracing
side,
so
I
think
it
would
be.
I
think
the
items
on
the
agenda
are
sort
of
accurate
in
that,
potentially
there
could
be
more
tests.
We
could
sort
of
assess
things
for
viability,
the
the
api
checklist
for
just
making
sure
this
is
a
well-formed
rust
project
generally.
Does
it
conform
to
all
the
idioms?
A
Those
type
of
things
I
think
doing
the
survey
doing
all
those
types
of
things
would
be
good
and
then
yeah
getting
sort
of
to
you
know,
through
the
last
kind
of
tracking
issue
there
for
the
long
tail
one
of
the
bigger
pieces
that
I
would
think
so
originally
we
had
a
similar
model
to
to
the
go.
A
Implementation
on
sort
of
a
pipeline
builder
go
walked
that
back
before
they
did
gas
to
to
not
need
clarity
on
the
best
way
of
of
making
a
few
specifics.
I
think
it
was
about
resources
and
a
few
others
that
were
sort
of
tricky
to
get
in
with
the
builder
syntax.
A
A
It
may
be
an
easier
commitment
to
make
if
we
want
to
get
something
that
we
can
call
stable
and
then
sort
of
release
higher
level,
maybe
cleaner
constructors.
On
top
of
that,
not
sure
how
how
sort
of
everyone
feels
about
that
or
parallels
that
if
their
core
team
has
sort
of
more
guidance
or
if
there's
a
general
sort
of
hotel
stance,
I
know
the
the
constructors
across
languages
vary
a
little
bit,
but
they
they
do
sort
of
tend
to
be
a
little
more
verbose
sort
of.
A
If
there
are,
if
there's
sort
of
a
consensus
generally
among
ways
of
making
that
more
sort
of
to
lower
the
boilerplate,
perhaps
for
configuration
or
if
it's
just
a
thing
that
we
we
shouldn't
be
attempting
yet
and
should
just
standardize
first
around
something
that
may
be
a
little
more
verbose
and
then
sort
of
have
have
the
nicer,
maybe
cleaner,
uis
later.
If
they,
if
sort
of
patterns
emerge,
that
people
find
useful.
A
Yeah
for
yeah
for
the
construction,
so
right
now,
they're
sort
of
too
often
two
separate
ones.
So
the
go,
for
example,
went
from
one
sort
of
pipeline
builders
kind
of
struck
pattern
to
just
sort
of
minimally
two
one
for
sort
of
configuring,
the
exporter
and
then
one
for
configuring,
the
tracer
provider
and
then
often
explicitly
setting
the
tracer
provider
as
the
global
defaults.
A
There's
sort
of
a
few
steps
in
properly
constructing
an
an
hotel
environment
generally
right
and
there's
sort
of
a
few
ways
that
could
go
wrong
like
if
you,
if
you
think
that
just
creating
one
will,
for
instance,
register
it
as
the
global
and
you
sort
of
forget
to
you-
may
sort
of
create
a
instance
of
your
application
that
doesn't
actually
end
up
tracking
anything.
Things
like
that.
A
There's
sort
of
there's
more
foot
guns
in
the
more
verbose
sort
of
fully
defined
manual
structure,
rather
than
something
that
would
that
would
be
a
little
more
declarative,
but
is
is
there's
sort
of
less
consensus
upon.
As
far
as
I
can
see
in
the
hotel
side
generally
on
sort
of
tracing
instantiation.
B
Yeah
that's
correct.
I
think
that
in
at
least
I
have
seen
that
many
things
they
try
to
keep
this
minimalistic,
if
possible,
just
to
avoid
problems,
usually
they
they
have
been
adding
stuff
like
for
a
more
advanced,
more
regular
configuration.
A
Any
any
other
thoughts
on
that
or
is
that
sort
of
the
is
the
is
the
recommendation
effectively
that
that
would
sort
of
roll
back
any
non
non
sort
of
strictly
necessary
features
that
currently
exist
in
order
to
get
sort
of
to
a
faster,
stable,
one-o.
B
B
Yeah,
so
it's
up
to
you
in
general,
I
mean
there's
some
effort
that
still
needs
to
happen
when
it
comes
to
configuration,
but
that's,
but
that's
mostly
when
it
comes
well.
There
are
two
two
things,
and
probably
they
are
not
entirely
related
to
what
you
are
talking
about,
because
they
are
related.
Only
one
of
them
is
how
to
provide
a
high
level
api
to
configure
things.
So
it
means
that
in
any
case,
for
final
users,
we
will
be
offering
at
some
point
in
the
future,
a
very
easy
abstraction
to
provide
that.
B
The
second
thing
is
to
provide
environment
or
external
configuration
to
environment
variables
or
configuration
files.
So
those
things
exist,
I
would
say
in
parallel
and
in
theory
those
two
things
will
help
configuring.
You
know
open
telemetry,
because
of
that
I
would
say
that
you
have
less
responsibility
on
your
side.
There
will
be
other
things
that
will
be
taking
care
of
that.
B
Because
of
that
I
would
say,
as
I
said
before,
I
think
that
is
there
something
that
you
are
not
confident
about.
It's
totally
absolutely
fine
to
leave
that
out.
A
Yeah,
but
so
that
may
be
something
that
we
sort
of
try
to
to
assess.
Then
internally
is
sort
of
the
confidence
in
the
current
builder
model
for
for
configuration
there
are
some
others.
You
know
the
compiled
languages
obviously
have
a
trickier
time
in
kind
of
dynamic
construction
of
some
of
these
things,
especially
as
packages
have
to
sort
of
be
statically
imported
and
some
other
bits
that
make
sort
of
full
configuration
through
through
environment
variables,
somewhat
trickier
and
in
some
languages
than
others,
but
yeah.
A
B
Yeah,
actually,
if
you
want
some
actual
further
more
technical
review
on
that
more
detailed
review,
maybe
you
can
create
an
issue
for
this
specific
point
and
what
things
you
would
like
to
maybe
keep
out
and
what
things
to
keep
in
and
then
I
can
review
the
actual
issue
with
the
technical
details.
A
Yeah,
I
think
perhaps
some
of
them
could
be
useful.
Are
there
are
there
folks
on
the
technical
committee
or
other
people
who
are
more
comfortable
with
rust.
A
Yeah,
that's
sort
of
the
state
of
the
world.
It's
you
know
the
the
newer
languages,
often
we'll
we'll
run
into
just
some
more
of
that,
but
yeah
from
a
from
sort
of
a
an
ergonomic
side.
That
would
be
one
where
obviously,
it's
nicer
to
to
have
different
sized
organizations
input
on
it
as
well.
If
there's
certain
you
know
certain
concerns
that
are
that
are
useful.
It's
nice
to
know
that
before
you
you
commit
to
a
stable
1.0.
B
Yeah
yeah.
Well
I
mean
we
can
still
do
a
review
when
it
comes
to
the
api
in
general.
What
things
we
think
like,
for
example,
when
I
did
something
in
python.
I
remember
that
they
were
adding
a
lot
of
sugar
sugar
methods
there
and-
and
I
for
example,
I
suggested
just
remove
that
and
it's
on
you,
so
it's
like
very
general
stuff
that
we
can
provide.
B
The
other
thing
is
that
for
some
specific
stop-
and
this
is
not
specific
to
the
six-
is
that,
for
example,
like
the
current
sampling,
the
probabilistic
sampling
effort
a
lot
a
lot
of
people
in
hotel.
They
are
not
familiar
with
any
of
these
brand
new
stuff
that
is
happening
there,
and
so
basically
there's
a
separate
group
of
external
experts
that
they
are
providing
feedback.
B
People
in
the
auto
community,
they
just
go
review
that
they
give
a
very
general
feedback
piece,
and
then
we
count
on
the
experts.
I
think
that
for
gold,
that
was
actually
some
idea
that
we
had
in
the
past
because
jana
I
forgot
her
her
family
name
but
jana,
who
was
around
in
the
past.
She
was
very
very
involved
in
golang,
so
even
though
she
was
not
part
of
the
core
hotel
community,
we
wanted
to
get
feedback
from
her
and
it
would
be
totally
valid.
You
know
it's
just
to
so.
B
A
Yeah
we
could,
we
could
perhaps
look
into
those.
Let's
see
what
was
the
other
issue
that
was
lying
to
your
oh
yeah
issue.
364.
there.
C
A
Sort
of
wait
is
that
right,
maybe
the
other
issue
for
the
the
tracking
issue.
For
one
point,
there
were
sort
of
a
couple
smaller
issues.
I
think
just
auditing
sort
of
the
interfaces
generally
to
make
sure
that
that
these
are
the
types
of
things
we
want
to
support,
but
I
think
in
general,
most
of
the
the
tracing
feature
set,
I
mean,
as
you
can
see,
on
the
feature
matrix
most
of
the
things
are
implemented,
so
the
sort
of
the
overall
capabilities
are
all
there
for
one.
Oh,
I
think
it.
A
It
is
really
the
the
final
touches
which
are
are
sort
of
trickier
right.
It's
it's
it's
sort
of
understanding
if
there
are
more
either
performance,
sensitive
or
other
optimizations.
That
could
be
done
at
this
point
to
make
apis
more
ergonomic
or
that
type
of
thing
before
they're
sort
of
locked
down
and
yeah.
A
You
know-
maybe
that
is
the
type
of
thing
we're
going
through
and
just
sort
of
identifying
those
and
requesting
specific
audits
could
be
the
most
sort
of
the
the
quickest
path
forward
for
some
of
those
or
the
easiest
way
to
get
feedback
rather
than
just
sort
of
the
blank
slate
of
of
asking
people.
Is
this
good
or
not
type,
of
of
broad
questions?
Yeah?
A
Maybe
there
could
be
some
attention
there
for
breaking
out
more
of
the
specifics
on
where,
where
we
sort
of
want
to
make
sure
that
the
interfaces
are
correct
and
sort
of
ready
to
be
to
be
committed
to
for
a
longer
term,.
A
A
Maybe
in
more
detail
were
there
were
there
other
sort
of
bits
of
feedback
too,
and
it's
been
been
a
little
bit
since
we've,
we
sort
of
talked
to
maybe
some
of
the
the
techno
committee
more
directly
or
there
are
other
bits
of
of
context
that
that
should
be
sort
of
at
the
same
level
or
things
we
should
be
taking
into
account
when,
when
working
on
the
language,
specific
implementations.
B
B
We
didn't
know
like.
I
know
that,
for
example,
ruby
was
coming
and
going
and
then
some
effort
actually
happened
there.
So
we
were
wondering
what's
the
state
and
I
don't
know
whether
you
have
timelines
and
how
confident
you
feel
about
them.
If
you
have
any.
That
would
be
mostly
the
thing
and,
as
I
said
before,
I
was
talking
in
the
slack
channel
that
we
are
happy
to
do
at
this
review
whenever
you're
free
whenever
you're
ready,
sorry
but
yeah.
We
were
initially
curious
about
the
timelines.
A
Yeah,
it
seemed
it
seemed
like
the
mention
at
the
beginning.
This
meeting
of
of
you
know,
q1
2022,
seems
sort
of
the
right.
The
right
sort
of.
A
Basically,
it
and
the
the
other
side
can
follow.
Some
updates
need
to
be
done.
There
was
sort
of
an
implementation
of
the
metric
side
as
well
that,
while
feature
complete,
was
more
along
the
lines
of
the
the
original
go
implementation
rather
than
sort
of
some
of
the
bits
that
have
changed
since
then,
but
at
least
from
the
tracing
side.
I
think
that
probably
is
is
reasonable.
It
just
needs
sort
of
a
few
last
passes
to
before
we
can
sign.
A
This
is,
this
is
the
right.
The
right
feature
set
to
go
with.
B
A
Yeah,
the
api
is
more
stable.
I
think
there
are
some.
There
are
some
questions
like
there's
the
open
issue
658
on,
if,
if
things
like
they're
sort
of
the
ability
to
say
force
flush
spans
and
if
that's
kind
of
part
of
the
api
or
the
sdk,
it's
currently
sort
of
right
defined
more
at
the
sdk
level,
it
seems
within
the
actual
spec
document.
A
But
in
order
to
have
that
work
across
implementations-
or
you
know,
within
sort
of
the
the
current
implementation
of
the
global
constructor,
it
almost
exists
more
at
the
api
level
and
rust.
So
there's
there's
some
small
questions
like
that
on
kind
of
package
specifics
or
where,
where
some
functionality
should
live
and
if
it
makes
sense
or
if
it's
kind
of
sdk
specific
right.
B
Actually,
I
would
be
very
happy
honestly
to
take
all
these
small
doubts
on
stuff
like
this.
Let
the
separation
between
api
and
sdk.
I
would
be
very
happy
to
to
read
about
them
in
issues,
because
I
know
that
for
python,
that
was
a
problem
like
before
the
release.
This
had
the
same
problem,
some
things
that
were
expected
to
be
on
the
api.
They
were
on
the
sdk
and
the
other
way
around,
and
it
was
not
so
obvious.
You
know,
because
the
specification
sometimes
is
suddenly
not
as
clear
as
it
should
be.
B
So
in
anything
that
you,
you
guys
think
that
is
not
clear.
I'm
really
happy
to
you
know,
go
to
an
issue
that
you
create
and
go
over
that
even
before
the
actual
pc
review,
which,
by
the
way
the
this
review
is
optional,
but
it's
up
to
you,
but
in
case
you
are
even
before
that
any
doubt.
I
will
be
very
happy
to
go
over
that
because,
yes,
I
think
that,
as
I
said
before,
that
the
difference
is
not
clear
as
it
should
be.
Sometimes.
A
Okay,
great
yeah,
maybe
we'll
take
a
pass
at
those
types
of
issues
and
find
find
the
areas
that
are,
I
think,
there's
probably
only
one
or
two
of
those
currently,
but
you
know
ping
you
on
some
of
those
that
where
it's,
it's
perhaps
a
little
ambiguous
and
we
can
try
to
find
the
right.
The
right
resolution
to
those
type
of
of
proper
module
definitions,
great
yeah,
were
there
go
ahead.
C
C
For
example,
the
tracer
was
used
to
be
the
used
to
only
have
two
required
parameters.
One
is
name,
one
is
the
other
instrument,
library
and
after
that,
the
the
specification
had
something
called
schema
and
we
were
having
a
hard
time
to
adjust
that,
because,
like
our
tracer
function
is
just
one
function,
it
takes
exactly
two
parameters
and
if
we
add
another,
one
can
become
tricky.
C
C
Right
so
I
mean,
in
that
case
the
builder.
The
building
will
actually
make
sense
because
you
can
have
the
basic
add
more
functionality
into
it.
Yes,.
B
A
Yeah
yeah,
so
we
may
need
to
that,
may
be
one
where
we
sort
of
have
sort
of
an
ergonomics,
review
or
sort
of
other
questions.
I
think
there
are
ones
where
it
becomes
yeah.
I
think
that
the
point
that
you're
bringing
up
is
a
really
good
one
where
you
know
if
there
is
one
one
constant,
you
know
parameter
that
is
passed
and
one
optional
parameter
that
that
is
sort
of
reasonable.
You
know
even
sort
of
idiomatic
rust
to
have
have
sort
of
a
method
with
that
signature.
A
To
have
a
method
with
with
two
optional
parameters
starts
to
become
a
little
a
little
long
in
the
tooth
for
for
a
lot
of
idiomatic
rest
so
yeah,
maybe
we
can
sort
of
look
through
which,
with
which
methods
make
sense
to
break
out
into
ones
that
are
that
are
maybe
have
sort
of
a
simpler
form
like
if
you
only
have
a
if
you're,
just
trying
to
get
a
tracer
with
just
a
name
and
you
don't
have
a
schema
or
or
you're
just
using
the
default
instrumentation
library.
A
Maybe
that
is
sort
of
simpler
one,
and
then
we
have
another.
That's
a
builder,
or
we
can
sort
of
decide
on
on
some
other
basic
pattern
to
to
use
there,
but
yeah.
It
would
make
sense
to
have
sort
of
a
usability
or
just
sort
of
a
developer.
Experience
review
on
some
of
those
to
make
sure
that
the
the
ergonomics
of
the
apis
that
we're
exposing
are
sort
of
reasonable
to
commit
to.
C
And
also,
I
agree
that
we
shouldn't
worry
about
the
high
level
configuration
scene,
because
I
think
a
lot
of
users
are
using
the
library,
so
the
glass
tracing
ecosystem,
which
means
there
are
other
interfaces,
actually
landed
in
the
tracing
side.
And
we
just
provide
the
underlying
functionality
from
the
tracing
part
right.
A
Yep
yeah
rust
has
the
the
added
perhaps
benefit,
but
also
complication
of
there
being
other,
very
interoperable
tracing
ecosystems
that
this
sort
of
slots
into,
which
means
there's
some
ability
to
experiment
within
those
other
interfaces
and
and
sort
of
punt
on
making
that
decision
here
like
we
could
effectively
ship
1-0
and
other
libraries
can
provide
higher
level
abstraction
for
making
the
developer
experience
a
clean
one
yeah.
So
that's.
C
A
Yeah,
that's
good,
that's
a
good!
It's
a
good
strategy,
but
that
would
that
would
mean
sort
of
going
through
and
removing
all
of
the
pipeline
syntax
that
we
have
right
now
and
just
reverting
all
the
examples
to
use
the
more.
The
more
explicit
you
know,
create
an
exporter
and
then
create
a
tracer
provider
and
then
set
the
tracer
provider
as
the
global
tracer
provider.
Sort
of
pattern
of
of
instantiation.
C
A
That's
that's
a
good
question.
Carlos.
Have
you
seen
sort
of
ways
of
delineating
sort
of
more
experimental?
I
mean
we
could
have.
You
know,
for
example,
on
a
more
experimental
package
or
sort
of
other
ways
of
explicitly
marking
things
as
kind
of
out
of
the
scope
of
stability
right
now,
but
are
there
sort
of
hotel
sort
of
cross
hotel,
maybe
standard
ways
of
of
doing
that
type
of
signaling?
There.
B
Yeah
there's
a
document
somewhere,
but
basically
the
idea
is
that
everything
that
is
not
stable,
it
has
to
be
in
a
separate
package
or
artifact
or
whatever
it's
called
in
in
for
different
cities.
A
A
Be
behind
a
feature
and
rest,
I
mean
there's
sort
of
a
few
a
few
ways
of
doing
it.
One
would
be
a
you
know
like
open,
telemetry,
experimental,
rust,
crate
literally
one
might
be
just
using
a
cargo
flag
to
basically
let
users
opt
into
the
more
unstable
api
or
just
putting
it
in
a
module,
marked
experimental
or
something,
so
they
have
to
have
it
in
their
import
path.
So
it's
sort
of
signaling.
A
B
Yeah
the
first,
the
first
case
that
you
mentioned
it
was
mentioned
that
it
happened
to
be
like
that
in
scala,
like
it's
releasing
the
actual
stable
package,
but
with
with
some
labels
saying
you
know,
this
is
experimental,
but
the
problem
is
that
people
started
relying
on
that.
So
even
though
it's
experimental
it's
in
the
final
package,
so
they
you
know,
and
it's
coming
out
of
the
box,
so
they
don't
know
and
then
later
they
will
be
complaining
that
you're
breaking
their
their.
B
You
know
their
code
base
when
it's
compiling,
so
that's
the
risky
part
and
that's
why,
for
example,
in
java,
we
also
wanted
to
have
some
experimental
annotation,
but
it
was
deemed
too
risky.
So
it's
at
least
like
putting
a
lot
of
stuff
in
their
own
package.
So
users
have
to
be
super
explicit
that
they
are
importing
ros,
specific
ros
experimental.
B
A
Yeah,
that
makes
sense,
I
think,
I
think
minimally
sort
of
having
a
flag
that
actually
requires
opting
in
rather
than
just
just
an
import
path
like
the
import
path
is
easily
missed
by
ide
as
sort
of
auto
importing
and
other
things.
But
you
know
a
flag
that
when
you
import
the
package,
you
explicitly
have
to
choose
that
you're
you're
opting
into
the
unstable
set,
maybe
a
happy
middle
ground.
B
A
A
Okay,
yeah,
that
sounds
great,
so
we
can.
We
can
sort
of
start
moving
things
that
we're
not
that
are
that
are
sort
of
in
in
tracing
the
module
currently,
but
not
sort
of
being
committed
to
behind
those
types
of
flags
yeah.
I
think
that
those
are
those
are
probably
a
couple
sort
of
takeaways
from
from
this.
That
will
be
useful.
C
A
Yeah,
I
guess
carlos
is
their.
What
does
the
the
overall
ecosystem
look
like
for
when
I
was
on
exporters
and
other
sort
of
related
packages.
A
Is
it?
Is
it
generally
that
there's
a
a
set
of
of
exporters
that
go
1-0
at
the
same
time
as
oh
yeah,.
B
B
So,
basically
for
exporters,
I
need
to
check
the
link,
but
basically
from
the
top
of
my
head,
you
need
you
need
one
of
one
of
the
otlp
ones:
either
the
the
jrpc
or
the
http
one.
You
need
the
trigger
the
shipping
one,
the
memory
one
and
the
login
one.
B
A
So
all
of
those
are
there.
I
think
it
would
be
more
on
the
the
stability
guarantee.
So
if
we
were
to
have
the
tracing
api
and
sdk
1.0,
would
the
expectation
be
that
that
that
those
accompanying
exporters
also
hit
1-0
at
the
same
time
or
are
those
sort
of
independent
releases
in
terms
of
sort
of
stability
guarantees.
B
That's
a
good
one.
I
think
that
most
ziggs
already
have
all
of
these
exporters
by
1.0.
B
That's
correct,
yeah.
I
have
to
say
that
the
exception
to
that-
and
this
is
a
very
recent
thing-
is
javascript-
that
they
win
1.0
without
without
some
of
these
ones,
and
the
reason
is
that
they
are
using
otlp
json,
which
is
not
stable,
so
they
went
without
without
without
any
stable
otlp
exporter
yeah.
So
I
don't
have
a
clear
answer
for
that
in
theory.
Yes,
you
should
have
all
of
these
ones
1.0.
B
As
part
of
the
of
the
final
of
the
one
ga
release,
I
could
say
I
would
say
that
the
motivation
or
the
rationale
behind
that
is
that
the
community
is
afraid,
like
you
know
the
gc
at
least
it
is
afraid
that
if
you
owe
1.0,
then
maybe
you
will
provide
one
otp
exporter
and
then
you
will
not
release
a
seating
and
a
nor
a
exporter,
and
you
will
never
do
that
because
you
were
never
you
know
right
it
was.
It
wasn't
a
requirement.
A
Yeah,
okay:
well,
we
yeah
we've
sort
of
got
those
already
developed
but
yeah.
I
guess
so
that's
a
good
point.
Then.
Maybe
the
integration,
testing
and
making
sure
we
have
coverage
on
those
and
support
would
be
something
we
should
check
as
well.
So
we
don't
break
those
guarantees
once
we've
released
them.
C
Okay,
one
last
thing
is
the
last
time
we
talked
about
ga.
We
talked
about
our
dependency
studies,
I
think
most
of
the
important
ones
when
become
stable,
but
there
are
still
one
or
two
dependency:
it's
not
stable.
A
Are
they
in
public
interfaces
like?
Are
they
in
in
public
methods
signatures,
or
are
they
just
internal
sort
of
implementation?
Details
right
now.
C
Yeah,
we'll
have
to
figure
that
out
too
I
don't
have
a
list
of
dependency
with
me
right
now,
but.
A
I
think
that
would
be
the
bigger
question
as
long
as
we
don't
expose
any
of
those
then
they're
not
we're
not
really
committing
to
them.
It
would
be
really
if,
if
any
of
their
types
end
up
in
the
public
interfaces,
then
we
have
to
be
we.
We
we
can't
release
before
they
are
1.0
or
they
can
make
breaking
changes
it
will.
It
will
negatively
affect
us,
but
we
need
to
examine
these.
Yes,
yeah.
That's
a
good
point.
That's
another
audit.
A
B
By
the
way
I
was
checking
and
it's
something
interesting
because
per
the
specification,
the
jager
and
the
shipkin
exporters
are
not.
They
are
not
optional,
well
it,
but
they
have
some
some
interesting
things
because
they
forgot
that,
for
example,
jager
supports
multiple
formats,
so
you
are
obligated
to
support
at
least
one
in
theory:
okay,
because
they
have
drift
protobuf
or
tripped
over
http.
B
So
it's
it's
awful
thing
there.
But
anyway,
probably
if
you
want
you
can
create
an
issue
in
the
ros
repo
and
I
can
follow
up
and
they
will
double
verify.
What
are
the
expectations?
There?
I
mean
most
of
yeah,
I
mean
yeah.
Let's
do
that.
I
mean
the
actual,
so
the
thing
is
that
their
section,
the
section
for
these
exporters
in
spec,
doesn't
mention
a
mouse
or
a
shoot.
B
However,
in
the
spec
in
the
compliance
matrix
matrix,
you
have
basically
I
mentioned:
you
have
a
column,
you
have
a
section
with
exporters
and
then
you
have
a
a
column
with
your
called
optional
and
then
you
know
what
did
you
need
and
then
there
are
of
course
a
lot
of
notes,
but
yeah,
let's
follow
up
on
the
other
one.
A
Very
cool
yeah,
so
they're
yeah,
we
we
have
the
the
zip,
the
let's
see,
yeah
the
thrift
and
the
drift
over
http
versions,
at
least
for
jaeger
done.
The
zipkin
has
one
of
the
I
think
json
http
implementation
and
yeah.
The
otlp
is
the
grpc
implementation.
A
Oh
yes,
yeah
yeah,
yeah,
that's
great
yeah,
so
making
sure
those
are
there.
A
If
there
are
yeah,
I
guess
right
more
around
the
the
the
interfaces
that
those
use
so
make
sure
the
the
exporter
interface
is
stable.
A
I
think
there
were
some
changes
we
wanted
to
make
there
in
terms
of
where
it's
exported,
there's
sort
of
a
few
sort
of
internal
ergonomics
changes
that
we
wanted
to
make,
and
I
think
they
were
in
the
tracking
issue
for
1-0.
But
if
they're
not,
we
can
make
sure
that
they
get
in
there.
So
it's
all
sort
of
centered
easy
to
to
sort
of
centrally
see
the
state
of.
A
Yes,
this
looks
good,
okay,
great,
so
yeah
carlos,
the
the
metrics
side
is
still
waiting
for
feature
freeze.
Is
that
right,
the
spec
status?
B
A
Yeah
yeah,
like
it
sort
of
there's
yeah
we
we
have
to
do
a
bit
of
sort
of
rework.
We
had
again
we
had
more
alignment
with
the
initial
kind
of
working
draft
of
the
spec,
but
haven't
done
the
change
for
kind
of
the
latest.
The
latest
metrics
changes
that
have
come
out
so,
but
the
the
spec
is,
is
effectively
locked
in
terms
of
that.
So
it's
it's
sort
of
safer
from
a
sync
perspective.
To
start
working
with.
B
Yes,
and
actually
I
mean
technically
technically
you
have
to,
if
you
want
to
go,
ga,
you
only
have
to
be
compliant
with
one.
They
don't
1.0
release,
which
has
probably
a
few
less
items
in
the
matrix
itself.
So
yeah
I
mean
we
have
had
eight
releases
ever
since
with
some.
B
So
yeah,
probably
that
it's
a
silly
thing,
because
we
should
probably
be
presenting
some
difference
or
you
know.
Well
I
mean
you,
you
can
actually
go
to
the
actual
release
and
check
what
the
the
stuff
is
at
that
release
and
then
you
can
just
go
and
go
with
that.
I
know
that
yeah,
one
of
the
recent
things
that
we
changed,
for
example,
is
that
now
these
days
we
recommend
that
if
cities
have
to
choose
between
supporting
otlp,
grpc
and
otl
http,
we
prefer
that
they
go
with
otlp
http.
B
So
it's
a
shoot.
You
know,
should
support
this
instead,
but
it's
a
a
relatively
minor
change
yeah,
because
in
windows
series
that
you
you
have
to
support
one
or
the
another,
and
now
it's.
A
C
A
Cool
cool,
great
anything
this
was
this
was
useful
to
go
through
and
sort
of
recap
things
and
see
what
the
state
of
this
is.
Is
there
any
any
other
things
that
we
should
discuss
here
while
we
well?
We
have
folks
thinking
about
it.
B
Okay,
I'm
fine
and
as
yeah
just
to
mention
this
again
want
to
mention
this
again,
I'm
happy
to
do
this.
This
review,
even
if
I
don't
know,
whenever
you're
ready,
no
pressure
and,
as
I
said,
this
is
optional,
the
actual
full
review
from
the
tc,
and
even
if
I
am
not
around,
because
I
will
get
holidays
in
the
future
in
the
near
future.
Anybody
from
the
tc
can
do
that
in
the
meantime,
happy
to
help
with
any
doubts,
perfect.
A
Thanks
well
that
sounds
great.
We'll
we'll
get
the
these
sort
of
next
steps
going
and
take
it
from
here.
Sweet,
wonderful,.