►
From YouTube: 2021-01-28 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
Hey,
does
anybody
know
if
leighton
or
alex
are
going
to
show
up
or
oh
there
we
go.
B
C
C
But
I
don't
know,
maybe
we
need
to
stop
making
such
interesting
software
projects,
everybody.
D
D
A
C
A
F
C
I
haven't
I
had
to
ask
for
the
password,
because
I
don't
see.
A
It
in
my
calendar
yeah
it
needs.
I
think
it
needs
to
be
updated,
because
if
you
look
at
the
some
other
events,
you'll
see
there's
like
a
pwd
query
parameter
in
the
url,
while
ours
does
not
have
one
in
the
calendar,
which
is
why
you
have
to
manually
type
it.
I
guess.
D
A
B
Sup
guys,
okay,
so
as
usual,
please
add
your
name
to
the
attendees
list.
If
you
can.
B
Have
a
couple
of
topics
to
talk
about
not
much
on
the
agenda
actually
today.
The
first
thing
is
the
versioning
discussion
that
we've
had
or
we've
been
having,
and
it
seems
like
we're,
making
good
progress
or
coming
to
a
consensus.
B
Basically
right
now,
the
the
decision
that
we're
kind
of
going
with
is
to
have
a
one,
stable
branch
and
a
either
dev
or
metrics
branch
in
which
we
can
continue
to
work
on,
in
which
our
our
main
branch
would
be
the
one
that
we
release
off
of
and
we
have
bug
fixes
from,
and
then
we
have
a
metrics
branch
or
dev
branch
in
which
we
will
be
doing
our
experimental
releases
off
of.
B
B
So
it's
pretty
much
a
trade-off
between,
like
you
know,
usability.
You
know
points
of
contention
for
the
customer
versus
how
much
the
work
the
maintainers
have
to
do
and
we
kind
of
tried
to
like
come
to
like
a
happy
medium.
B
So,
if,
like
nobody
else,
has
any
like
large
objections
to
this
methodology,
then
this
is
probably
what
we're
gonna
be
doing
here
on
out.
So.
C
Yeah,
I
see
that
you
asked
me
to
comment
I'll,
be
reviewing
the
the
last
comments
in
that
thread.
B
Yeah
sure,
oh
yeah,
we
really
need
to
settle
on
a
decision
for
this.
So
if
anyone
else
has
like
you
know
pretty
big
points
or
you
know,
please
bring
it
up
like
as
soon
as
possible,
because
this
is
delaying
our
release
date.
B
A
I
just
had
one
question:
I'm
not
gonna
object
anymore,
but
I
was
just
wondering
if
anybody
read
or
had
any
thoughts
on
on
the
I
don't
know
where
it
went.
The
comment
I
posted
with
a
different,
a
different
strategy.
B
Yeah,
I
think
like
this
is
the
method
that
we
were
choosing
to
do
from
the
very
beginning
right.
It's
like
there
was
like,
I
think,
the
first
proposed
one
without
the
extra
requires
stuff
right.
A
Yeah
more
or
less,
but
the
the
extra
requires
would
give
you
like
it
would
prevent
accidentally
having
an
overlap
in
your
namespace
package.
B
Yeah
yeah
and
I
think
that
solves
the
that
the
biggest
concern
in
which
why
we
moved
away
from
this
solution.
Yeah
does
anybody
have
any
thoughts
on
this
solution
me
personally,
it's
like
like.
We
could
do
this,
it's
just
that.
It
just
requires
some
engineering
effort
on
our
end
right
now
and.
B
Like
I
don't
know,
if
we
have
the
bandwidth
to
do
this
realistically
right
now
or
what's
it
called
like
the
if
the
benefits
like
outweigh
the
supportability
stuff,
that
we
got
to
deal
with
afterwards,
so.
B
A
All
right,
well
yeah.
If
anybody
else
has
comments
on
that
I'd
appreciate
but
yeah,
I
don't
I'm
not
gonna
block
this.
I
think
the
other
way
would
work
fine
as
well,
so.
D
I
just
realized
that
I
was
talking
to
myself
for
a
while
here
laden
as
usual
yeah.
I
know
right.
It's
the
outcome
here
to
update
the
release
kind
of
proposal,
doc
to
specifically
call
out
our
strategy
because
it
feels
like
it
feels
like
even
that
strategy
at
the
top
here
doesn't
match
what
we're
actually
going
to
go
with.
So
I
just
want
to
make
sure
that
we
don't
that
we're
very
clear
with
this,
with
our
users.
B
Yeah,
I
think
the
decision
has
evolved
as
the
conversation
went
on
and
if
we,
if
we
get
a
consensus
today
or
like
you
know,
once
diego
reviews,
this
and
majority
of
the
approvers
are
on
board,
then
we'll
definitely
have
to
make
it
explicit
in
our
documentation
to
align
with.
E
C
Question
here
is
this
pretty
much
just
following
the
django
release
process?
C
D
D
B
A
I
think
I
think
we
should
have
people
emerge
just
to
not
to
dev
so
like
to
master
as
much
as
possible,
because
I
think
that
way
we'll
be
eager
to
occasionally
merge
like
master
into
dev,
but
the
other
way
around
we're
not
going
to
be
doing
for
months,
so
it
could
be
merged
into
into
master.
That's
easier.
D
And
then,
if
you
are
contributing
to
metrics
directly,
then
you
would
be
working
in
inside
this
branch
and
that
that's
actually
why
I
propose
calling
that
dev
branch
just
colony
like
based
on
the
feature
that
it's
implementing
so
in
this
case
it'll,
be
called
metrics
or
whatever
yeah
yeah,
because
it
is,
it
is
a
long
like
it's
not
just
a
dev
branch.
It's
a
long
running
branch
right.
It's
a
long
running
feature
branch.
So.
A
A
D
A
A
B
Oh
yeah,
like
perhaps
in
the
future,
we
might
also
have
like
a
like
a
logging
feature
branch
too
yeah,
just
depending
on
like
when
the
release
timelines
are
out
and
like
how
far
along
we
will
be
at
that
point.
So.
A
Yeah,
I'm
just
gonna
ask:
what's
the
plan
for
like
the
contrib
packages,
specifically
like
exporters
that
support
metrics
and
I
think,
requests
or
flask
also
has
metric
instrumentation.
B
Yes,
yeah
good,
good,
good,
good
question.
I
would
assume
that,
like
once,
we
release
our
rc's
and
we
have
two
different
versions
of
the
package.
We
would
have
to
update
some
of
the
contrib
repos
to
point
to
the
unstable
version,
so.
B
A
I
mean
I
feel,
like
it's,
maybe
more
important
for
the
contrib
repo
because,
like
if
there's
a
breaking
change,
it's
going
to
break
people's
metrics
and
alerts
rather
than
just
breaking
their
code
like
like.
If
you
upgrade
in
the
code
breaks,
I
mean
that
sucks.
But
if
you
upgrade
and
then
like
your
metrics,
just
change,
it
breaks
your
alerts.
It
could
cause
like
outages
and
stuff
right,
yeah.
B
If
users,
if
users
use
like
the
the
unstable
package
right
with
the
like
the
flask,
instrumentation
or
whatever
like,
if
we
upgrade
it's
gonna,
break
their
like
it's
gonna
mess
up
their
metrics
and
have
alerts
anyways
right.
B
Yeah,
if
they're,
using
the
unstable
one
like
they're,
gonna,
they're
gonna,
get
broken
anyways
right,
you're
gonna
have
alerts
anyways
and
we
can't
prevent
them
from
not
using
the
unstable
one.
So,
at
this
point
it's
like
a
usability
problem
or
like
what
the
customers
will
do
as
long
as
like
we
don't
promise
the
1.0
like
they
can
do
anything
right
and
like
and
as
long
as
we
still
have
breaking
changes
and
metrics.
It's
always
going
to
be
like
that.
Until
we
we
promise
that
it's
going
to
be
stable
right.
A
Yeah
I
mean
that
makes
sense,
because
they're
probably
not
ready,
but
I'm
wondering
like
what
the
timeline
is
for
that
as
well,
because
I
think
for
anybody
I
mean
it's
like
the
same.
The
same
problem
right
like
if
people
can't
use
the
instrumentations
and
they're
just
going
to
manually
instrument.
It's
not
that
great
to
use
like
right,
1.0
right.
B
Right-
and
that
is
a
fair
argument-
it's
also
like
it
brings
to
the
the
whole
discussion
and
like
for
the
maintenance
part
of
it
too
right
like
if
someone
comes
in
and
adds
like
a
random
instrumentation
and
like
we
never
receive
them
again
like
what's
the
guideline
behind
that
right,
we
can't
make
it
1.0
and
then
like
now,
it's
just
the
burden
on
the
main
maintainers
or
the
approvers.
To
always
make
sure
this
unknown
piece
of
software
is
like
always
working
case
in
point
like
the
sk
learn
instrumentation
that
we
have
like.
B
E
B
Want
to
be
putting
under
our
responsibility,
I
think
they're
having
that
discussion
right
now
in
the
maintainers
meetings.
B
The
I
think,
they're
being
very
strict
about
this,
where
it's
like
you
know,
if
we
don't
foresee
it
as
something
we
want
to
support
like
we
actually
just
reject
the
pr
other
people
are
saying
it's
like
okay,
we
can
accept
the
pr,
but
it's
like
if
they're,
if
they're,
breaking
changes
or
like
you
know,
blocking
stuff
like
if
it
isn't
action
upon
within
an
x
amount
of
time
like
we
just
remove
it
or
something
you
know,
yeah.
A
A
To
be
clear,
like
I
have
no
problem
with
breaking
them,
it's
just.
We
need
to
follow
some
bear
so
that
if
people
don't
have
like
a
dependency,
exactly
pinned
doesn't
break
so
like
if
they
upgrade
they
know
what
they're
doing
and
obviously,
if
we
can
push
that
off
as
long
as
possible,
it's
best
because
that
that
way
we
don't
have
to
like
backboard
stuff,
but
I
don't
think
there's
going
to
be
much
like
patching
going
on
in
there
but
yeah.
That's
I'm
fine,
I'm
fine
with
that.
B
Yep
totally,
I
think
it's
been
on
like
the
maintainers
radar
for
a
while.
It's
just
that
there's
other
pressing
matters
right
now,
yeah
a
good
good
point,
good
question.
B
Right
any
more
comments
on
this
issue.
Hopefully
we
get
a
resolution
by
the
end
of
this
week,
all
right
nice.
If
there's
no
other
topics,
we
can
go
on
to
the
prs.
Now
I
added
a
couple
just
like
ping,
a
few
people.
B
So
this
resource
merge
key
conflict
residence,
basically
like
recently
in
the
oh.
I
guess
your
contest
here,
but
it's
pretty
straightforward,
like
recently,
the
precedence
for
merging
in
conflicting
keys,
which
is
like
the
same
string,
has
been
reversed.
So
before,
like
the
the
old
one
took
precedence,
but
now
it's
like
the
new
one
takes
precedence.
So
pretty
straightforward
change.
B
I
think
oh
nice,
it
just
got.
B
Yeah
yeah,
damn
yeah,
pretty
pretty
straightforward.
I
think
since
aaron
approved
it
there's
there's
nothing
I
can
say
now.
So
it's
like.
D
A
B
So
aaron,
I
think
what
you
were
referring
to
was
like,
so
some
exporters
require
a
service,
dot
name
field
in
the
resources,
specifically
jaeger
and
zipkin,
and
I
think
we
need
to
conjure
up
default
values
for
those
and
hector
put
out
a
pr
like
a
couple
of
weeks
ago
to
change
that-
and
I
think
that's
already
finished
so
I
think
we're
good
for
that
hold.
A
B
Awesome
yeah
there's
a
couple:
oh.
C
C
The
good
news
yeah
I
just
rebased
that
against
mastered
and
now
it's
working.
I
don't
know
why
and.
B
See
like
this
is
the
magic
yeah.
It's
actually
crazy.
You
needed
some
time
yeah
to
like
to
warm
up
right,
yeah,
sorry
going
back
to
the
actually
later
anyways.
So
this
is
the
next
pr.
This
is
the
one
other
one
that's
kind
of
waiting
on
for
rc
one,
and
I
probably
can't
start
the
splitting
up
of
the
metric
stuff
and
I
think,
there's
another
issue.
That's
also
waiting
on
this
until,
like
all
of
the
architectural
stuff
has
been
done.
B
So
if
people
can
review
this
and
get
this
as
soon.
D
D
E
B
Yeah
so
there's
also
a
anyways.
We
could
just
I'll
talk
about
this
later
anyways.
So
there's
this
pr
about
the
global
tracer
provider
after
tracer
creation.
I
think
this
has
been
out
for
a
while,
and
this
is
not
necessarily
blocking
the
rc1
release
because
we
still
like
spec
compliant
it's
just
like
a
very
specific
use
case.
I
mean
a
common
use
case.
I
guess
it's
a
sign
to
me
right
now,
but
I
don't
have
much
context
yet.
B
I
haven't
take
a
look
at
it
that
thoroughly,
but
if
the
current
approvers
can
kind
of
like
just
resolve
their
comments,
they'll
be
good
and
then
I'll
I'll
take
a
look
at
it
after
two.
So.
A
I
took
another
look
at
this
and
I
just
wanted
to
call
out
a
few
things
that
I
think
are
different.
If
you
scroll
down
a
little
sure
yes
stop
there.
So
one
thing
is
the
get
tracer
and
get
tracers
to
simply
be
like
an
alias
for
get
tracer.
Provider.Get
tracer.
That's
that's
like
not
the
case
now.
A
If
I
think
I
outlined
this
correct
and
we'll
see
if
anton
agrees,
but
basically
if
the
user
doesn't
set
the
global
provider
or
if
the
user
doesn't
set,
the
trace
provider
in
the
environment,
variable
they're
going
to
behave
slightly
differently,
which
I
mean
it
seems
like
it's
sane,
but
I
just
want
other
people
to
take
a
look,
because
I
think
it
was
supposed
to
just
be
a
really
simple,
alias
and
then
oh,
I
see
yeah
yeah
and
then,
if
you
scroll
down
a
little
more
yeah,
so
this
I
feel
like
it
might
be
an
issue
with
our
implementation
like
originally.
A
B
Yeah,
I
think,
like
the
specs
say
nothing
about
having
to
return
the
same
instance.
B
But
yeah
like
it
was
my
understanding
aaron
that,
like
this,
was
like
not
something
that
we
needed
to
have
and
just
like.
I
have
a
cache
or
something.
B
A
The
metric,
obviously,
when
you
register
an
instrument,
there's
more
state
so
just
like
for
symmetry
purposes,
it
might
be
nice.
I
don't
even
think
it
would
change
the
output
because,
like
if
those
variables
are
the
same,
then
it
becomes
the
same
thing.
The
internal
like
you
know
like
when
it
gets
converted
to
otlp
or
whatever,
but
yeah.
A
I
think
I
think
the
real
issue
here
is
that,
like
the
proxy
is
only
happening
at
the
tracer
level
and
it's
not
like
a
it's,
not
returning
a
proxy
tracer
provider,
so
basically
it's
using
a
separate
implementation,
almost
rather
than
using
the
trace
provider,
one
all
right,
yeah
anyway,.
D
B
Yeah
so
you're
talking
about
the
configuration
part
right
yeah.
So
I
was
taking
a
look
at
this
and
that
implementation
is
like
one
way
of
doing
this.
B
Basically,
I
think
what
usher
khan
is
he
posted
in
the
chat
it
refers
to
like
if,
if
any
time
a
configuration
change
in
the
tracer
provider
is
made,
users
shouldn't
have
to
like
call
get
tracer
again
to
pick
up
those
configuration
changes
and
I've
been
going
through
this
code,
like
in
the
last
couple
days
and
talking
with,
like
other
sick
people
and
and
also
to
kind
of
correct
me
if
I'm
wrong.
B
If
this
is
not
what
you're
referring
to
but
like
in
terms
of
configuration
like
the
only
things
that
we
can
change
right
now,
are
like
sampler,
ids
generator
resources
and
span
processors,
and
we
already
fulfill
the
spam
processors
one
because
we
use
a
multi-span
processor,
but
the
other
three
are
deemed
as
immutable
and
cannot
change
so
right
now
technically
like
if
there
is
new
stuff
added
or
if
they
ever
deemed
those
stuff
to
be
mutable,
we
would
actually
be
breaking
customers
in
the
future
if
we
needed
to
add
stuff,
because
all
we
do
is
just
pass
these
things
along
the
constructor
and
propagate
them
down
from
the
tracer
provider
to
to
the
spans,
whereas
other
languages,
they
have
a
like
a
trace,
config
concept,
which
is
pretty
much
just
a
simple
container
to
wrap
all
of
these
things
in
it
does
give
them
a
lot
of
flexibility
in
the
future
if
they
ever
want
to
add
something
more,
but
as
of
today
like
we're
still
like
technically
spec
compliant
and
following
these
things.
B
So
I
guess
what
do
you
guys
think
in
terms
of
this,
like?
I
didn't
foresee
this
as
a
problem?
So
so.
A
Yeah
yeah,
I
don't
think
this
pr
changes
that
for
our
repo,
because
it's
just
it's
just
getting
the
tracer,
which
has
those
things
already
like
you
said:
they're
passed
by
value,
so
yeah.
B
I
think
I
was
referring
to
like
the
reason
why
srikanth
posted
that
the
comment,
I
think
the
the
excerpt
in
the
specs
only
adheres
to
doing
the
the
cache
tracer
because
of
this.
So
we
don't
necessarily
have
to
return
the
same
instance
of
a
tracer.
B
Awesome
cool
all
right,
sorry,
aaron,
going
back
to
what
you
were
talking
about
so
you're
saying
so.
The
the
the
behavior
of
gay
tracer
actually
is
changed
right
like
we
only
had
that
as
like
a
simple
rapper
thing
for
ease
of
use,
and
now
it's
actually
different
depending
on
whether
or
not
they
have
configured
the
tracer
fight
or
not
right.
A
Yeah,
so
it's
it's,
basically
it's
semantically
almost
the
same,
but
it
will
return
like
different
objects
and
there's
only
one
case
that
I
can
think
of
that
it
will
actually
be
behaving.
A
So
yeah,
I
don't
know
there
might
be
other
things.
Basically.
My
point
was
just
this.
Pr
is
a
little
tricky
because
it's
like
tinkering
with
some
really
like
core
stuff
to
how
our
how
our
api
works.
So
if
other
people
could
take
a
look
as
well
and
we
could
do
our
due
diligence,
that
would
be
probably
good
because
I'm
a
little
nervous
about
it.
A
You
mean
the
rc1
or
the
yes,
the
rc1.
A
I
don't
I
mean,
I
think
it's
important,
like
a
lot
of
people
are
asking
for
it
and
now
that
I've
looked
around,
I
think
javascript
and
maybe
java,
and
I
mean
this
is
just
from
talking
to
people.
I
haven't
actually
looked
at
the
code,
but
okay
see
both
also
this,
so
it
would
be
like
nice
for
consistency
and
okay
yeah.
B
Make
this
high
priority
I'm
nervous
because
it
touches
a
lot
of
like
core
features.
You
know,
and
everything
is
based
off
of
the
tracer
provider
and
tracer.
So.
A
B
That's
totally
possible
as
long
as
this
doesn't
break
any
of
the
the
tracing
functionality
or
apis,
and
I
don't
think
it
does
right,
which
is
why,
like
I
was
able,
I
was.
I
was
okay
with
leaving
it
for
now,
but
I
guess
just
my
nervousness
is
like
it's
it's
very
highly,
coupled
with
like
stuff
that
we
promise
not
to
break
so
I
think
it
would
be
nice
to
have
it
as
part
of
rc1
and
like
I
think
that
would
be
most
desirable.
A
Yep,
I
think
street
college
just
put
something
new
in
the
chat.
F
B
Thanks
yeah,
okay,
so
we'll
try
to
yeah
get
this
out
for
the
rc1
release.
So
I
think
it's
a
pretty
important
nice.
Okay,
no
other
comments
on
that.
Then
we'll
moving
right
along.
D
This
says
diego's
the
pr
that's
in
the
notes
here.
C
Oh
yeah,
given
threesome
propagator,
it's
being
added
there.
There.
E
Is
something
that
I
noticed.
C
When
implementing
this
is
that
our
span
context,
they
store
the
trace
ideas
as
integers
right
so
apparently
for
open
tracing.
C
We
need
to
do
padding
when
extracting,
and
that
means
adding
zeros
at
the
left
side
of
the
screen
right
and
that
padding
is
lost
when
we
do
the
conversion
to
integer
to
store
into
the
span
context
race
id.
So
I'm
not.
This
is
a
a
difference
between
this
implementation,
the
at
least
the
javascript
implementation.
C
The
fact
that
we
are
storing
trace
ids
as
integers
and
not
as
strings.
So
I
wanted
to
bring
this
up
see
if
you
have
any
comments
or
suggestions
on
this,
oh
by
the
way.
I
I
added
this
case
that
intentionally
fails
to
highlight
this
issue,
so
this
here
should.
C
Anyway,
what
do
you
guys
think
about
storing
trace
ideas
as
strings
and
nothing.
D
C
Well,
I
was
when
you
implemented
this.
I
was
fully
and
closely
the
implementation
of
javascript.
Let
me
see
if
I
have
it
around
here,
so
I
can
show
you
where
the
issue
is
happening.
C
C
Line
91,
you
can
scroll
up
a
little
bit.
Please
yeah
right
there.
So
yes,
here
in
extract
the
pad
the
trace
id
with
zeros
at
the
left
side.
If
the
trace
id
is.
C
Too
short,
so
I
tried
doing
doing
this
exact
same
thing
in
python,
but
then
I
realized
that
padding
gets
lost
when
we
convert
this
to
an
integer
when
we
store
this
in
the
span
context,
so
I
don't
see
a
way.
D
D
C
So
we
are
storing
the
traceability
scintikers,
it's
my
context
and
I
I
don't
know
if
that's
a
hard
requirement
or
if
that
specified
or
what
but.
D
C
Here
I'm
gonna
paste
a
link.
C
Go
yeah
that
line
line
265,
so
they
they
are
actually
making
sure
that
the
padding
is
there.
So,
of
course,
we
can't
do
that
because
our
pattern
gets
lost.
A
Think
I
might
be
missing
something,
but
would
it
would
it
be
like
not
equivalent
to
just
inject
those
zeros
in
the
when
we
inject
the.
A
Propagator,
sorry
yeah.
Let
me
rephrase
that
when
sorry,
when
the
propagator's
inject
method
gets
called,
could
we
not
just
do
the
padding
again.
C
That's
not
actually
the
issue
here.
Let
me
see
if
I
can
point
you
to
where
this.
D
C
B
D
Yeah-
and
this
is
this-
is
an
issue
with
the
this
is
trying
to
address
the
issue
that
open
tracing
headers
have
only
been
64
bits
in
the
past
and
we're
trying
to
put
it
into
a
format
that
makes
sense
for
open
telemetry,
which
is
128.
But
but
I
mean
I
guess
like
as
long
as
the
exporter
does
the
right
thing
when
we're
exporting
this
value
which,
like
I
don't
think
it
really
matters.
If
we're
left
padding
with
zero.
C
B
C
They
always
have
is
that
if
they
put
them
by
padding,
they
are
kept
because
they
are
string.
They
are
stored
as
strings.
They
don't
store
the
trace
ids
as
integers.
Let's
see.
B
I,
I
guess,
could
you
like
kind
of
explain
an
example,
the
the
the
end
to
end?
What
would.
A
Yeah
so
like,
if
something
comes
in
it's
too
short,
you
store
it
as
an
n.
It
doesn't
change
anything,
but
then
when
you,
because
the
the
padding
is
just
zeros
on
the
left,
which
get
erased
right
so
in
the
exporter,
when
you
want
to
add
those
zeros
back,
you
can
just
add
them
as
a
string.
If
that's
what
the
open,
like
whatever
export,
is
expecting,
but
the
value
is
the
same
whether
or
not
the
padding's
there
right.
F
C
D
So
my
point
was,
I
think
what
aaron
was
just
saying
is
that
you
know
where
do
we
care?
So
if
we're,
if
you're
extracting
the
trace
id
from
the
the
headers,
and
now
you
have
like
a
span
with
a
trace
id,
that's
like
64
bits.
The
only
the
only
people
that
will
care
about
this
trace
idea
is
either
the
propagators
when
you're
passing
that
information
along
or
the
exporter,
when
you're
trying
to
export
the
data
right.
C
D
C
D
F
F
A
A
Adding
it's
still
a
valid
id
in
the
propagator
right.
C
Right
so
I'll
guess
I'll
be
removing
that
this
case,
because
I
don't
think
it
makes
sense.
B
F
B
Okay,
cool:
if
there's
no
more
comments
on
that,
I
guess
we
could
just
keep
moving
along.
Oh,
I
guess
we
already
finished
that
pr,
so
yep.
B
Your
name
yeah,
I
just
want
to
put
myself
everywhere.
I
guess
you
could
just
open
the
first
one
and
see
what's
up
with
that:
oh
right,
yeah,
okay,
so
recently
the
environment
variables
for
hotel
exporter
has
been
split
up
thanks
for
cons
for
adding
this
issue.
B
Originally
we
thought
this
was
an
rc2
case,
but
technically
it
will
be
breaking
users
if
they
start
using
this,
because
we
we
expose
it
right-
and
I
think
right
alex
was
was
this
for
the
one
that
was
in
the
district
or
like?
Was
this
in
other
places
too
yeah?
This
was
inside
the
distro
because
it
was.
B
Right,
I
see
okay,
I
think
the
reason
why
I
changed
it's
like
right
now,
if
you
guys
take
a
look
at
the
feature
matrix
and
the
specs,
it
says
that
there's
a
note
saying
that
environment
variables
are
completely
optional,
meaning
that
well.
A
B
Yeah,
so
if
you
go
down
to
the
environment
variable
section
at
the
top,
the
excerpt
says
note,
support
for
environmental
variables
is
optional,
so
this
means
that
like,
if
we
do
include
it
in
our
you
know
in
our
release,
then
the
stuff
like
hotel
span
event
count
limit
span,
link
account
limit.
That
stuff
is
like
exposed
to
customers
and
if
they
start
using
that,
and
if
this
ever
changes
it
would
be
a
breaking
change.
B
So
we
need
to
have
like
the
confidence
that,
like
is
either
this
stuff.
Won't
change
and
it'd
be
marked
as
stable,
which
is
not
currently
the
case.
E
Yeah
they're
changing
very
frequently.
I
agree
with
that.
B
Right
right
exactly,
and
so
it's
either
like
we
don't
expose
any
environment
variables,
which
is
what
dot
net's
doing
and
or
we
take
a
gamble,
and
we
just
keep
what
we're
doing
right
now,
because
we
support
a
lot
of
them
and
hope
that
none
of
them
change.
So
I
was
just
wondering
what
you
guys
thought.
B
B
B
B
B
B
If
we
actually
take
a
look
at
the
like,
there
should
be
a
spec
document
for
environmental
variables
specifically,
and
this
is
not
marked
as
stable,
yet
so
like
as
long
as
it's
not
marked
as
stable,
like
it's
open
to
change,
and
you
know
we
would
have
to
make
a
decision
on
whether
or
not
we
would
include
it
as
part
of
our
1.0.
B
D
Yeah
I
mean
I,
I
think
it's
very
confusing
if
it's
in
the
compliance
matrix,
even
if
it's
marked
as
optional-
and
it
then
shows
up
as
not
released
in
1.0,
I
feel
like
that
would
be
very
confusing.
Yeah
like
as
a
user.
I
would
probably
just
search
for
that
environment
variable
and
then
see
it
in
the
environment
matrix
or
whatever
in
the
matrix
in
the
environment
section,
and
then
I
would
just
make
an
assumption
that
it
may
or
may
not
be
implemented,
but
I
wouldn't
expect
that
it
would
change.
A
Yeah,
my
understanding
was
that
any
environment
variables
like
that
are
specified
if
they're
optional
just
means
the
support,
for
them
is
optional,
but
they
shouldn't
be
changing
after
the
1.0.
If
they're
in
the
spec
and
like
case
in
point,
I
think
there
was
one
for
otlp
protocol
or
maybe
it
was
zipkin
or
something
the
protocol
that
they
removed,
because
they
weren't
sure
if
they
were
going
to
change
it.
So
they
just
didn't
want
to
have
it
in
the
1.0.
B
E
B
So
at
least
for
action
items
for
us
I'll,
probably
like
follow
up
with
ted
or
something
to
see
if
we
can
mark
the
environment
variables
as
stable
explicitly
if
there
is
still
discussion-
and
it
is
the
case
in
which,
like
we're,
not
actually
releasing
this
as
1.0,
then
you
know
we
will
have
to
probably
make
those
changes.
B
Cool
nice
yeah
in
terms
of
other
issues-
I
I
didn't.
I
don't
remember
what
I
was
gonna
say
for
that
other
comment,
but
all
the
rc1
stuff
right
now
is
either
assigned
or
in
pr's.
D
I
think
there's
only,
I
think,
there's
only
one
issue:
that's
currently
still
kind
of
open
right,
the
the
one
about
concurrent,
ascending
or
whatever.
I
think
there's
right.
D
D
Like
most
of
the
stuff
is
in
progress,
I
think
there's
only
so
the
ones
on
the
left
that
don't
have
anybody
assigned
to
them
yet
is
the
hotel
trace
exporter,
hotel,
metrics
exporter
and
then
the
there's
someone
who
is
interested
in
implementing
the
concurrent
sending
for
tlp
exporter.
But
I
think,
there's
still
some
questions.
B
B
Interesting,
oh
okay,
yeah!
I
see
it
yeah
so
yeah.
This
is
apparently
a
yeah,
a
must-have
alex.
Were
you
going
to
look
through
his
comments
and
everything
because
I
I
didn't.
I
didn't
really
take
a
look
at
this
issue
at
all.
D
Yeah,
I
I
haven't
had
a
chance
to
spend
any
time
on
it.
I
may
be
able
to
later
this
week,
but
I
don't
know
if
I'll
be
able
to
get
to
it.
Just
yet.
Okay,.
B
A
B
B
A
Yeah,
it
seems
like
it
should
be
pretty
straightforward,
but
my
only
concern
is
the.
If
we're
running
multiple
threads
in
the
exporter
it
might
be.
I
don't
know
like
alex,
remember
that
lambda
discussion,
where
we're
talking
about
you,
know
not
having
multiple
threads
for
stuff,
like
that.
I
guess
it's
a
setting,
so
it
should
be
okay.
B
D
B
Nice,
okay,
cool-
I
think
that's
a
pretty
much
it
for
this
week.
Does
anyone
else
have
any
other
topics
they
want
to
bring
up.
A
One
real
quick
question:
are
we
publishing
the
trip
docs
on
read
the
docs
anywhere
at
all,
because
it
seems
like
that
stuff's
kind
of
gone
missing
and
there's
a
bunch
of
broken
likes.
D
B
D
D
A
B
D
A
B
B
E
A
D
B
That
was
from
like
way
before,
oh,
my
god,
yeah,
okay,
cool
anything
else
from
from
anyone.
Any
other
topics.