►
From YouTube: 2022-01-18 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
Good
day,
sir,
how
are
you
doing
well
doing?
Well?
How
was
your
weekend
yeah?
It
was
good,
it's
good,
I'm
working
on
a
new
laptop,
so
I'm
like
spending
my
morning
being
like
all
right.
I
need
to
install
go
1.17
and
all
sorts
of
fun
give
permissions
yeah
weekend
was
good
moving,
mostly.
A
A
I
think
I
think
francis
left,
like
one
small
comment,
but
I
think
other
than
that
should
be
good
to
go.
But
yeah
a
lot
of
people
have
been
on
vacation
is
the
underlying
reason
here
that
it
hasn't
merged.
A
Oh
and
amir
I
saw
I
got
to
be
honest.
I
didn't
read
your
whole
message.
I
saw
in
javascript,
you
were
like
getting
yelled
at,
but
you
were
fighting
or
something
I
didn't
really
like.
I
gotta
read
this
stuff
and
I
can
comment
but
yeah.
I
didn't.
I
just
saw
a
wall
of
text
and
it
was
like
my
weekend.
That's
like
I'm
not
doing
this,
I'm
not
looking
at
it.
So
sorry.
C
A
It
right
I
wrote
the
original
implementation,
the
propagation
stuff
my
colleague
had
written.
I
think
I
reviewed
it
or
something
at
the
time,
but
I
didn't
actually
write
the
like
sqs,
probably
I'm
familiar
with
it,
but
yeah
I
can
chime
in
it
sounds
like
people.
So
what
is
the
context
that
essentially
customers
or
end
users
are
being
like?
Hey
this
is
broken,
and
then
you
have
to
be
like
it's
not
broken.
It's
just
like.
There's
no
right
way
to.
D
C
Feedback
or
something
yeah
but
never
mind,
yeah.
A
C
A
No
big
deal,
I'm
just
saw
an
excuse
for
me
to
talk
about
that.
I
have
an
m1
computer
design,
the
new
apple,
it's
like
the
apple
silicon.
You
know
it's
faster,
I
don't
know
it's
all
the
same.
Crap.
A
I
don't
know
it's
fine,
nothing,
there's
a
bunch
of
stuff
that,
like
doesn't
work
on
m1,
yet
like
a
bunch
of
so
that's
been
annoying
like
jaeger
doesn't
run
the
jaeger
like
distro
doesn't
run.
A
E
A
A
Yeah
I
have
one
one
I
haven't
looked
at
this
keyboard,
it's
it
is
weird.
My
old
macbook
was
like
look.
It
was
just
like
obscenely
large
for
some
reason,
and
so
now
the
keyboard's
like
smaller,
and
so
I'm
just
like,
have
a
lot
of
typos.
I'm
typing.
E
All
right,
the
spec
sig
was
refactored
ever
so
slightly
from
the
actual
thing.
So
we
started
off
with
this
vlog
sig
update
and
it
sounds
like
the
log
sig
is
pretty
happy
with
what
they
have
and
they're
starting
to
kind
of
solicit
feedback
from
the
wider
world.
E
So
they
have
a
data
model
and
then
kind
of
like
sdk
and
then
there's
just
kind
of
a
milestone
if
you're
interested
in
the
other
things
that
are
going
on,
but
they're
asking
for
please
review
and
I
looked
at
this
stuff-
it's
already
kind
of
like
aren't
full.
So
I
don't
know
that
they're
meant
to
be
reviewed
in
in
that
way.
E
This
bullet
point
here,
it's
kind
of
says:
please,
join
the
logging
stick
if
you
want
to
learn
more,
have
feedback,
but
I
expect
there
to
be
lots
of
feedback.
I
guess
I
just
don't
know
what
the
exact
channels
are
other
than
joining
the
sig
at
this
point,
but
there
is
a
data
model.
I
think
the
only
thing
that
I'm
aware
of
is
the
24
levels
of
severity,
because
that
was
fairly
surprising
to
me
when
I
first
saw
that
a
while
ago,
but
there's
a
lot
more
in
in
the
in
the
spec.
E
E
I
mean
both,
so
this
thing
is
an
o
otap.
Technically
the
model
seems
to
merge,
but
they
definitely
want
some
feedback
on
it.
E
So
that's
that
it's
exciting
news,
but
I
think
it
means
that
always
probably
have
a
little
bit
of
reading
to
do
in
order
to
have
a
reasonable
conversation
about
it.
E
There
was
a
brief
discussion
about
metrics
stuff.
This
issue
keeps
kind
of
coming
up
and
it
really
took
a
good
portion
of
the
last
meeting
and.
E
E
We
don't
yet
have
a
matrix
implementation
in
ruby,
but
kind
of
the
way
that
you
obtain
a
meter
is
kind
of
the
same
way
that
you
obtain
a
tracer.
It's
very
analogous.
You
have
a
meter
provider
and
then
you
request
a
meter
by
name
but
and
then
the
meter.
Basically,
you
know,
helps
you
name
your
metric.
E
It
gives
you
like
a
prefix
for
your
metric
and,
like
the
the
hope
there
is,
that
you
always
kind
of
end
up
with
like
a
unique
metric
name,
no
matter
what
without
having
to
have
knowledge
of
other
libraries,
just
by
the
way
that
that
works
out.
E
E
E
It
seems
like
a
bit
of
a
problem
and
maybe
not
something
so
much
worth
getting
into,
but
this
is
something
that
the
metric
sig
is
focused
on
and
trying
to
come
up
with
a
solution
to.
E
There's
some
discussion
about
this.
I
think
it's
still
a
little
bit
a
little
bit
up
in
the
air.
The
main
discussion
was
it
sounded
like.
E
Maybe
there
was
not
a
ton
of
people
interested
in
exemplars
right
now,
but
then
there
was
like
the
counter
argument
that
there
are
some
groups
that
are
interested
and
maybe
it's
a
chicken
and
egg
problem,
whereas
like
we
really
don't
have
definition
and
they're,
not
something
that
is,
is
being
widely
used,
but
if
they
were
out
there,
people
would
want
them
and
be
a
little
bit
more
interested.
E
E
Kind
of
what
what
this
group
intends
to
do
not
so
much
stop
how
they're
gonna
do
it
just
yet,
but
I
think
they're,
just
looking
for.
E
This
second
issue
is
more
about
how
things
are
going
to
work,
and
this
is
the
span
structure
for
retries
and
redirects,
and
if
I'm
understanding
this
properly,
you
would
create
a
span
for
each
for
for
each
one
of
these
parts
of
an
http
request.
So
you'd
make
a
stand
for
the
original
request.
If
there's
a
retry,
you
would
make
an
additional
span.
If
there's
a
redirect,
you
would
make
an
additional
span
and
then
you
will
link
them
together.
F
They
were
saying
to
use
links,
not
parent
contacts
right,
that's
what
is
it?
That's.
The
suggestion.
A
E
So
yeah,
just
while
we're
on
here,
it
does
look
like
the
idea
is
just
links
not
using
not
making
them
a
child,
so
this
would
kind
of
take
them
outside
of
the
flow
of
of
your
waterfall.
E
If
anybody
does
have
ideas
of
how
those
would
look,
I
think
yeah
kind
of
with
the
ideal
implementation
of
of
links
from
like
a
ui
perspective,
I
think
that'd
be
a
good
conversation
sometime
at
least
one
I'd
be
interested
in.
H
I
think,
like
jaeger,
has
it
and
now
in
the
later
releases
of
jager,
like
their
ui
and
the
way
they
do.
It
is
pretty
simple,
but
it's
just
like
at
the
bottom
of
your
span,
you
have
like
a
span
link
like
like
a
deep
link
to
the
span
itself
and
then
like
a
list
of
links,
and
you
just
click
on
it,
and
it's
just
a
deep
link
to
the
span
that
it's
referencing
and
I
don't
know
if
it's
like
a
really
good
way.
But
it's
like
very,
very
simple
and
easy
to
kind
of
grok.
H
You
know
I
thought
that,
like
that
is
like
pretty
reasonable
in
terms
of
what
I
would
expect
out
of
like,
because
that's
what
you're
asking
right
like
how
to
use
like
actually
use
these
links.
H
I
think
it
needs
to
be
all
that
complicated
right.
It's
like
it's
just
hey
this
span
references
another
span
and,
like
I
guess,
like
the
ui,
can
maybe
get
a
little
bit
ugly.
If
you
have
for
some
reason,
your
span
has
like
links
to
100
different
other
spans
right,
because
you
can
have
like
many
links,
so
that
could
look
weird,
but
in
a
one
to
one.
It's
like
just
a
little
click
here.
You
know,
I
think,
that's
nice.
G
Yeah,
I
think,
there's
interesting
things
that
you
could
do
with
kind
of
a
preview
of
what
you're
jumping
to
so
you
can
get
to
see
that
span
in
context
also
defining
some
kind
of
semantic
conventions.
Around
links,
given
that
links
can
have
attributes,
might
allow
you
to
build
different
uis,
depending
on
kind
of
the
nature
of
the
link.
E
There
was
a
discussion
around
adding
links
after
spam
creation,
so
I
think
this
will
probably
be
relevant
to
us
at
one
point
in
time
links
were,
you
could
have
links
after
spam
creation,
like
the
rule
that
they
could
only
be
added
at
span
creation.
Time
was
added
at
some
point
and
I
believe
the
reasoning
was
around
sampling.
E
This
is
like
a
decision
that
you
want
to
provide
to
the
sampler,
which
needs
to
be
there
at
span
start
time,
so
I
could
be
recalling
that
incorrectly,
but
I
kind
of
think
that's
what
happened
and
the
argument
was
made
that
well,
you
also
provide
attributes
that
can
be
used
by
the
sampler
at
span
start
time.
You
can
also
add
them
later,
so
it's
you
should
well.
You
should
provide
things
that
start
time
that
you
can
at
start
time.
There
is.
E
Since
it's
okay
to
add
attributes
later,
people
were
not
opposing
adding
links
later,
so
I
think
that
the
person
who
kind
of
brought
this
issue
up
was
going
to
work
on
some
we're
going
to
expect
pr
to
to
re-enable
this
functionality.
C
G
That's
right:
we
have
that
example
in
kafka,
libraries
as
well
kafka
instrumentation,
where
we
have
to
take
like
we
have
to
record
the
time
stamp
before
calling
the
receive
function,
and
then
you
call
the
receive
function
and
then
you
find
out,
like
all
the
messages
that
you
received,
you
create
spans
and
or
you
create
a
span
at
that
point
with
all
the
links
that
you
need
and
also
the
start
time
that
you
recorded
earlier
so
yeah.
G
We
have
examples
that
are
very
similar
to
that,
where
it
would
be
nicer
if
you
could
build
your
span,
the
normal
way,
so
with
a
block
structured
thing
and
then
add
the
links
once
you
know
what
they
are.
G
I
also
wanted
to
point
out.
You
can
change
the
name
of
the
span
after
it
started
as
well.
So
if
the
sampler
is
using
the
span
name
to
as
part
of
its
sampling
function,
then
that
can
also
change
subsequently.
C
Yeah
we
suggested
to
have
a
delay
spam
for
these
cases.
The
issue
is
that
maybe
this
receiver
has
http
spam
underneath
it
and
then,
if
you
delay
the
spend
creation,
then
this
http
it
gets
like
it
starts
a
new
trace
and
it
has
no
sampling
the
decisions
and
have
to
work
really
hard
to
capture
all
the
things
and
then
create
it.
When
you
get
back
the
response,
there
were
a
lot
of
discussions
around
it.
J
After
creation,
like
in
the
block
scenario,
that
francis
was
talking
about
you're
going
to
do
some
work
in
there
and
then
maybe
that
work
involves
linking
to
something
else,
maybe
it
doesn't
and
so
having
to
figure
all
that
stuff
out
at
creation.
Time
like
precludes
a
bunch
of
use
cases
for
spam
links.
E
Yeah
there
is
not
like
a
lot
of
resistance
to
this
at
all,
so
I
don't
know,
maybe
maybe
restricting
this
to
span
start
time
was
like
a
premature
optimization
that
really
wasn't
thought
through,
but
most
people
kind
of
recognize
that
this
is
a
common
thing.
E
A
Real
briefly,
I
had
last
week,
one
of
our
action
items
was
figuring
out
like
what's
standard
practice
to
do
with,
like
version
versioning,
for
things
with
like
a
potential
vulnerability,
but
maybe
only
affecting
like
a
very
small
subset.
I
had
asked
about
it
in
the
spec
channel
and
didn't
get
any
feedback.
So
that's
my
update,
so
there's
no.
I
have
no
update
on
that.
I
can
maybe
I
probably
am
in
the
wrong
channel,
though
I
can
maybe
ask
or
dm
like
morgan
or
someone.
A
You
know
on
the
management
side
and
see
if
I'm
sure
it
sounds
like
there's
not
an
answer
off
top
people's
head,
though.
E
Cool
robert
was
there
anything
from
the
instrumentation
seg
that
or
have
you
been
no
instrumentation
site
where
anything
interesting
has
happened.
H
E
Cool
all
right,
so
I
do
see
that
we
have.
We
have
at
least
one
burning
question,
which
is
this.
A
Yeah,
I
put
sorry
the
hot
link
didn't
work.
I
think
it's
kind
of
already
been
just
but
yeah.
It
just
was
a
polite
request
for
reviews
from
maintainers
for
that
sqs
pr
from
andy
van
emir,
which
francis
did
in
the
time
between
me
posting
that
this
meeting
so
yeah,
I
don't
know
tldr.
I
think
it's
pretty
much
good
to
go.
A
J
I
just
popped
a
it's
a
simmering
question,
as,
as
as
we
are
at
honeycomb
wrestling
with
baggage
and
how
vague
it
is,
it's
specked
at
the
w3c,
but
the
propagation
of
it
is
enjoy
headers.
J
We
have
experimented
with
a
thing
called
multi-span
attributes
our
proprietary,
the
b
lines,
the
thing
the
the
honeycomb
specific
tracing
tools
have
a
thing
called
trace
level
fields
where
you
could
tell
your
sdk,
the
beeline
sdk
to
put
this
field
on
every
span
you
generate
and
within
a
trace,
and
that
will
propagate
to
other
things
so
that
you
get
because
we
have
wide
events.
So
we
look
like
fields
of
fruit.
J
We've
implemented
something
similar
with
baggage,
because
baggage
gets
propagated
across
services.
We
have
a
baggage
span,
processor
that
says
any
keys,
any
key
values
that
are
in
baggage
put
it
on
the
put
it
on
the
span.
So
if
there's
something
in
baggage,
we
do
that
stuff
on
spans,
so
that
you
can
say
once
you
know
the
user
id.
You
could
apply
that
user
id
on
every
span
on
every
child
span
in
that
trace,
distributed
across
systems
problem
is
now
you're,
sending
the
user
id
in
a
header
to
every
third-party
web
request.
J
I
haven't
seen
in
any
of
the
the
sdk
implementations.
I
looked
at
ruby's
and
I
looked
at
a
few
other
languages.
I
haven't
seen
a
way
for
for
because
it's
not
specced,
so
it's
totally
reasonable
that
this
feature
does
not
exist
but
a
way
to
say
a
way
to
configure
or
control
when,
when
a
an
http
request
is
being
considered
for
propagation
outgoing.
A
way
to
like
allow
deny
a
list
who
receives
propagation
headers,
it's
totally
unspecced.
It's
understandable!
J
That
feature
is
not
in
the
sdks,
but
there's
a
glimmer
in
my
eye
that
maybe
it
ought
to
be
so
that.
G
It
definitely
ought
to
be
yes,
we,
our
proprietary,
like
shopify,
internal
tracing
library,
had
that
allow
this
mechanism.
I
don't
think
we
have
no.
We
haven't
implemented
that
for
open
telemetry
ruby.
Yet
so
yes,
it's
a
it's
a
concern.
We
should
build
that
kind
of
thing.
Does
it
need
to
be
in
the
spec?
G
Probably
not,
but
it's
something
that
we
should
experiment
with
in
the
http
instrumentation
at
least
you
know
providing
some
kind
of
you.
J
You
don't
think
it
ought
to
be
in
the
spec
say
as
like,
at
least
a
configurable
item,
so
that
if
you're
in
a
multi-language
environment,
each
of
the
sdk
you
can
much
like
the
prop
hotel,
propagation
hotel,
propagators
environment
variable
is
how
you
can
say,
trace
parent
and
baggage.
I
think
those
are
the
two
default
values
that
say:
sdk
is
yes,
please
propagate
these
things.
J
I
could
see
a
world
in
which
it
expects
to
configure
what
like,
where
you
specify
that
allow
list
so
that
in
a
multi-language
environment,
you're
you're
still
conf
the
configuration
api,
I
guess
for
the
propagation
code
receives
the.
G
C
G
Yeah
prove
it
out,
get
a
sense
of
what
it
should
be
and
then
go
to
the
spec,
probably
through
the
instrumentation
sig
saying:
hey,
here's
a
common
feature
that
we
need-
and
we
think
you
know
here-
are
the
environment
variables
that
you
probably
need
to
configure
it.
And
then
people
can
bike
shed
that,
as
opposed
to
bike
shedding
the
need
for
the.
C
J
F
It's
like
the
halfway
point
between
the
resource
attribute
and
the
span
specific
attribute
yeah.
It's
a
trace,
attribute
sort
of
kind
of,
but
it's
but
is
it?
Is
it
a
trace,
attribute
across
boundaries,
or
is
it
only
within
a
single
service.
J
As
implemented
in
our
proprietary
in
the
b
lines,
the
honeycomb
specific
stuff-
it
is
it's
across
services
and
to
replicate
that
it
is
also
we
use
baggage
to
implement
this
as
an
experiment.
It's
it's
see
how
it
feels
yeah.
G
So
the
alternative
is
that
you're
doing
some
kind
of
like
kind
of
like
tail
sampling,
you're
accumulating
the
entire
trace
in
a
stream
processing
engine
of
some
kind
and
then
you're
propagating
certain
fields
through
every
span
in
that
trace
before
you
store
it
in
your
back
end,
which
is
also
a
totally
reasonable
approach.
J
G
Yeah
so
other
unnamed
vendors
take
that
approach
yeah
the
approach
here
you
know,
if
you
don't
propagate
it,
then
you're
doing
potentially
expensive
joins
in
your
back
end
for
honeycomb
they're,
creating
a
kind
of
a
wide
event.
So.
J
J
G
Yeah
we
had
some
experiments
with
forcing
tracing
using
baggage
and
it's
basically
for
the
debug
use
case
right
where
you
say:
okay
like
so,
if
you're
doing
any
down
sampling,
make
sure
you
don't
down
sample
this
guy.
J
It's
also
real
fun
that
if
having
added
our
little
baggage
fan
processor,
that
says
any
fields
that
are
in
baggage
add
them
to
the
span.
It's
great
when
you
receive.
J
If,
if
your
ingress
is
not
stripping
out
propagation
from
other
systems,
now
people
can
throw
baggage
into
your
spans
from
outside
your
system,
but
that's
a
that's
a
the
path
to
solve.
That
is
more
well
worn,
because
everybody's
got
an
ingress
point
that
they
could
strip
headers
out
with
not
everybody
has
an
egress
header
stripper.
J
E
This
was
all
reminding
me
just
a
little
bit
of
josh
mcdonald.
Did
this
resource
scopes
prototype
a
long
long
time
ago,
but
it
sounds
to
me
like
oh
yeah.
Kind
of
kind
of
the
idea
is
that
you
could,
you
know,
start
a
scope
within
your
code
and
just
say
that
everything
underneath
this
gets
this
stuff
attached
to
it,
and
I
think
this
is
also
a
good
way
to.
E
It
was
a
good
way
to
basically
have
multiple
resources
within
the
same
app.
So
there's
like
this
multiple
tracer
provider
use
case
thing
that
we
sometimes
talk
about,
which
I
think
is
meant
to
be
kind
of
denote
like
two
logical
applications
within
a
single
actual
application,
but
yeah
just.
G
Yeah
we
have
some
stuff
right
now
in
our
http
instrumentation
helpers,
for
example.
That
allows
you
to
propagate
some
attributes
to
child
span,
so
that
handles
the
case
where,
like
faraday,
is
wrapping
that
http
and
you
want
to
ensure
that
all
http
client
spans
have
certain
attributes
set.
So
the
resource
scope
is
a
similar
concept,
like
a
more
generic
version
of
that.
That
would
apply
to
everything.
G
Get
rid
of
spam.
What
yeah
span
wouldn't
be
a
it
wouldn't
be
exposed
in
the
api
right,
it's
more
of
an
artifact
behind
the
scenes,
but
yeah
it
was.
H
So
we
we
talked
about
this
last
week,
like
what
is
it
going
to
take
to
get
the
otl
exporter
to
1.0?
I
just
like
quickly
added
the
things
from
last
week.
I
said
I'd
go
over
the
spec
again
and
I
have
I
found
one
that
is
kind
of
like
loosely.
H
I
don't
know,
I'm
still
not
totally
convinced
it's
the
the
first
tick
box
there,
the
remove
failure,
time
out
like
or
not,
failure
remove
timeout
status
code.
I
don't
have
to
rename
that,
but
essentially
like
the
spec,
doesn't
have
anything
about
timeout
as
a
return
status
from
an
exporter
it
does,
as
francis
pointed
out,
it
makes
mention
and
force
flash
that
there
should
be
a
way
to
let
the
caller
know
whether
it
succeeded
failed
or
timed
out.
H
So,
even
though
they
don't
say
that
these
are
the
expected
results,
these
two.
They
also
do
reference
it
like
it's
a
little
bit
of
inconsistency.
There,
however,
we're
not
actually
using
it
really
anywhere
in
the
otlp
export,
except
for
one
place,
and
it's
not
even
really
being
looked
at
in
the
batchvan
processor,
which
I
think
is
appropriate
because
matchband
processor
doesn't
have
a
concept
of
needing
timeout
statuses.
H
So
I
put
up
a
pr
to
remove
it.
That
looks
like
is
failing,
gloriously,
which
I'll
look
at
look
into
after
I
don't
know.
If
anyone
has
any
thoughts
on
that
one,
they
can
just
leave
like.
If
anybody
wants
to
talk
about
now,
we
can-
or
you
can
just
leave
a
comment
on
the
pr.
E
My
only
question
would
be
if
we've
taken
a
glance
at
just
a
couple,
other
languages
to
make
sure
that
that
it's
just
a
successor
failure.
That's.
H
H
The
other
thing
on
the
issue
is
something
francis
has
brought
up
in
the
past
and
recently
brought
up
when
we
talked
about
this.
H
H
We
don't
support
anything
other
than
http
protobuf
right
now
right,
but
we
should
make
sure
that
the
repo
is
set
up
in
such
a
way
that
we
support
the
environment
variable,
even
if
it
does
just
return
an
error
in
the
event
that
someone
requests
grpc
so
that
we're
positioned
to
add
it
in
at
a
later
date
and-
and
I
think
like
what
this
flat
combo
with
francis,
if
I'm
interpreting
it
right.
H
The
idea
is
the
outcome
of
this
is
like
once
we
have
this
environment
variable,
even
if
we
don't
implement
the
grpc
stuff,
we're
positioned
to
say
that,
like
our
current
otlp
exporter
is
1.0,
because
the
the
spec
doesn't
actually
have
any
hard
requirements
on
which
protocols
are
implemented.
G
Yeah
the
spec
is
the
spec
says
that
you
must
have
the
http
protobuf
implementation.
You
should
have
the
grpc
implementation
and
the
http
json.
Is
you
know
if
you
want
it,
but
I
think
the
the
main
issue
here
is
that
we
need
to
support
the
environment
variable,
so
you
can
select
which
protocol.
G
Even
if
we
just
return
an
error
saying
you
don't
like
that
one's
not
available,
we
should
have
the
ability
to
write
the
grpc
implementation
as
a
separate
gem,
so
that
people
don't
have
to
take
a
dependency
on
grpc
if
they
don't
want
to,
and
there
might
be
that
might
require
renaming
the
existing
gem
so
that
we
have
this
kind
of
consistency
rather
than
having.
You
know
the
otlp
exporter
as
http
protobuf,
and
then
you
know
a
separate
like
otlp
exporter
grpc,
as
the
alternative.
E
I
think
that
makes
sense.
I
was
just
gonna
clarify
that
that's
actually
the
approach
that
we
were
going
to
take
where
these
would
be
implemented
as
separate
packages
and
if
and
really
kind
of,
the
only
way
I
would
see
that
this
environment
variable
would
come
into
play
is
if
you,
if
you
had
like
an
export
or
all
package
or
something-
and
you
actually,
you
know
included.
You
know
three
different
gems
with
with
each
of
the
exporters
in
it.
Then
you
could
switch
between
them.
E
But
if
you
just
kind
of
included
a
single
package,
you
would
and
set
the
environment
variable
differently.
You
would
just
get
an
error.
G
Yeah
I
mean
until
recently
we
had
our
rapper
jam,
containing
both
the
jaeger
exporter
and
otlp
exporter,
so
that
you
could
use
it
for,
like
local
development,
to
a
jaeger
role
in
one
instance,
and
you
could
use
it
in
production
to
you
know
exporting
otlp.
So
I
can't
see
quite
the
same
use
case
for
otlp
grpc
versus
http,
but
yeah
like
there.
G
There
are
definitely
cases
where
you
might
want
to
do
that,
and
there
are
also
the
cases
where
customers
just
want
to
use
the
same
environment
variable
regardless
of
what
language
their
application's
written
in.
E
This
environment
variable,
I
think,
really
comes
from
a
lot
of
the
compiled
languages
where
you
end
up
just
having
everything
bundled
in
and
it's
it's
hard
to
kind
of
like
pick
and
pull
the
packages
that
you
actually
want
for
your
application.
But
I
think
for
for
the
sake
of
having
standard
behavior
between
the
different
sdks,
it's
it's
something
that
we
need
to
implement,
but
yeah.
G
So
there
is
that
complication
that,
if
you
like,
if
we
have
the
http
and
the
grpc
implementation,
even
if
somebody
has
chosen
to
include
the
the
grpc
gem
in
their
kind
of
require
list
to
actually
select
it,
they're
going
to
need
to
use
the
environment
variable
to
do
that
or
they're
going
to
have
to
do
explicit,
sdk
configuration.
But
now
we're
never
going
to
default
to
the
grpc
exporter.
G
Because
the
default
is
the
http
protobuf.
H
Yeah,
so
we
just
mentioned,
like
our
other
perk,
was
up
to
date.
I
checked
the
proto
repo
it
says
like
0.11
is
the
latest
and
francis
had
bumped
it
to
that
a
few
days
after
they
had
released
it.
So
it
looks
to
be
up
to
date
in
that
regard.
So
really,
I
think,
just
that
previous
point
we
were
talking
about
is
the
primary
thing
we
should
have
done
prior
to
the
1.0
release,
assuming
that
this
doesn't
require
like
a
tc
review.
H
I
forget
who
said
that
they
would
dig
into
that,
but
in
terms
of
like
combing
over
compliance
and
like
making
sure
that
we're
doing
this
right,
I
believe,
that's
all
that's
left
and
then
we
could
push
for
1.0
again,
that's
predicated
on
like
assuming
that
we
don't
need
some
other
group
to
review
it.
E
Cool
yeah,
I
think
I
was
supposed
to
ask
carlos
if
it
was
totally
necessary
and
I
have
yet
to
do
that.
But
I
I
will-
and
I
will
maybe
comment
back
on
this
issue
but
to
to
let
everybody
else
know.
H
Yeah,
if
anything
comes
up
like
anybody
identifies
anything
that
they
do
think
should
block
one
point
of
release,
like
just
add
comment
to
this
issue,
we'll
just
try
to
keep
what
needs
to
be
done.
Localized
on
this
one.
A
I
I
think
carlo
had
responded
in
tristan's
thread
and
he's
we
haven't
been.
He
says
we
haven't
been
requested.
A
formal
review
for
the
otlp
exporter
specifically
happy
to
do
it
if
needed.
A
I
did
a
previous
review
of
the
api
sdk.
I
think
that's
a
non-answer
kind
of
it
sounds
like
he's
saying
he
doesn't
think
it's
necessary
either.
E
G
There
is
some
language
in
the
spec
around
versioning
and
stability
that
deals
with
that
particular
case,
where
you
have
an
unstable
signal
that
you
want
to
support
I'll,
have
to
go
and
re-read
that
and
we'll
either
need
to
for
a
while,
create
a
a
separate
metrics
exporter,
gem
or
we'll.
Do
it
within
the
existing
one
but
label
the
metric
support
as
experimental
and
not
subject
to
the
semantic
versioning
constraints.
H
G
Think
that's
true.
Well,
that's
certainly
true
for
the
api
and
sdk,
I'm
not
sure
how
that
applies
to
an
exporter
that
happens
to
be
both
that
happens
to
be
exporting
both
signals.
The
it's
probably
not
onerous,
to
have
a
separate
gem,
because
the
way
the
exporters
are
configured
you
have
to
have
separate
exporters
anyway
for
like
separate
exporter,
instances
for
the
metrics
and
traces.
So
for
the
separate
signals.
G
G
G
Yeah,
the
overhead
of
setting
it
up
is
going
to
be
work.
Maintaining
it
is
probably
less
work
overall,
there's
going
to
be
a
lot
less
churn
in
the
main
repo
than
there
will
be
in
the
contrib
repo.
But
that's
true,
for
I
think
every
part
of
open
telemetry
at
the
moment.
H
G
Early
anybody
had
yeah,
I
mean
I
other
than
the
overhead
of
setting
it
up.
The
main
concern
I
would
have
is:
do
we
have
enough
people
who
are
actively
engaged
and
willing
to
be?
You
know
maintain
as
approved
as
whatever
on
the
contrib
repo.
Once
we
split
that
up.
I
I
F
Same
here,
I'd
be
willing
to
be
the
shepherd,
a
shepherd
of
this
soft
lock
and
then,
but
I
think,
like
from
the
mindset
of
where
I'm
at
right
now
with
what
the
contrib
repo
is.
It's
things
that
are
not
part
of
the
official
sdk
and
nothing
and
everything
that's
pre
1.0,
so
instrumentation
at
some
point.
F
Might
you
know
I
might
we
we
might
want
to
revisit
and
say,
like
the
instrument,
auto
instrumentation
repo
is
like
a
blessed
repo
when
it
reaches
a
1.0
status,
but
for
now
it's
kind
of
like
here's,
the
here's,
the
packet
drawer,
where
we
put
all
of
the
extra
catch
up
and
stuff.
H
Yeah,
like
resource
detectors
and
instrumentation,
would
all
go
in
there.
I
think
it
would
make
sense
to
like
for,
like
even
france,
myself
matt
just
also
still
do
maintainers
on
the
other
one
just
to
facilitate
like
like
it.
I
don't
think
it'll
hurt.
I
don't
know
if
everybody
like
it
might
be
weird
if
there's
just
like
15
maintainers
in
there
but
like.
H
E
Yeah,
I
think
that
sounds
good
sounds
like
we
do
have
volunteers.
It
sounds
like
I
know
the
biggest
obstacle,
or
the
biggest
reason
we
don't
yet
have
contrib
is
we're
just
kind
of
like
waiting
for
the
point
in
time
where
it
started
to
make
sense
where
having
the
combined
repo
was
starting
to
become
enough
of
an
issue,
and
it
sounds
like
we're
kind
of
we've
reached
that
threshold,
but
but
yeah
the
setup.
The
setup
and
initial
organization,
I
think,
is
the
the
biggest
hurdle
but
yeah.
F
Proposals
like
for
the
the
migration
process
itself
or.
E
H
Yeah
that'd
be
a
good
idea
like,
though
someone
can
open
an
issue
for
splitting
the
two
repos
having
a
clearly
defined
list
of
what's
here.
What's
there
might
be
a
good
time
to
even
try
to
like
daniel
again
to
see
if
he
wants
to
swoop
in
and
just
set
it
all
up
for
us
again,
because
he
was
pretty
good
about
that.
The
first
time
I
don't
know,
if
he's
opposed
to
doing
it
a
second
time,
but
it
won't
hurt
to
ask
ever
so
nicely.
F
I
shared
a
link
to
the
discussion
where
we
first
brought
this
up
and
a
bunch
of
questions
that
came
up
as
a
result,
and
we
can
continue
to
flesh
this
out.
We
can
convert
this
to
an
issue
and
then
know
grind
it
out
a
little
bit
more.
E
Yeah
sounds
like
a
good
plan.
I
know
when
we
discussed
this
last
week.
I
think
we
at
least
talked
a
little
bit
about
the
js
repo
and
I'm
not
sure.
If
we
are,
we
want
to
use
that
kind
of
as
an
example
or
if
there
were
any
deviations
we
would
have
from
from
their
setup.
E
A
Yeah,
I
would
say
it's
a
secondary
thing
to
just
like
the
initial
work
of
getting
stuff
set
up.
I
do
think
it's
important
long
term,
like
even
if
it's
a
person
from
every
vendor
it
just
becomes
really
hard
to.
You
know
maintain
some
of
the
stuff,
if
you
just
don't
have
day-to-day
like
actual
experience
with
it,
and
so
some
of
the
and
by
and
large
people
contributing
some
of
the
stuff
are
just
gonna,
be
like
hey.
A
I
use
falcon
as
my
http
server
like
here's,
a
here's,
an
instrumentation.
Do
you
want
to
own
this
weird
async,
ruby
web
framework
forever,
and
it's
like
no
so
code
owner
or
component
owners
could
be
good
for
that.
But
I
think
it's
a
far
it's
a
a
minor
thing
to
the
major
thing,
which
is
that
yeah.
I
just
agree
with
what
robert's
saying
we
should
just
like:
try
to
get
the
set
up
and
yeah.
J
Later,
what
what's
the
ownership
of
all
the
instrumentation
today?
It's
basically
the
approvers
and
maintainers
right.
That's
that's
the
default
in
the
new
repo.
I
imagine
and
then
yeah.
If
there
are,
if
there
are
volunteers
who
are
like,
I
really
know
this
wacky
edge
case.
Async
web
framework
cool
you
get
it
yeah,
you
get
it.
You
get
a
code,
an
entry
for
that
and
you'll
get
tapped
for
reviews.
It.
A
Also
lowers
the
bar
toward
what,
in
a
good
way
of
saying,
like
I
feel
less
worried
about
accepting
this
I'll
see
you
because
hey
you're,
saying
you
have
some
responsibility
here,
where
it's
like
the
bar's
higher.
If
you
want
me
to
own
this
me,
whatever
the
royal
we
forever
well,
then
it's
like.
Do
I
have
the
bandwidth
to
learn
the
subscription.
G
Yeah
we
had
a
question
from
a
vendor
a
while
back,
who
wanted,
who
had
a
customer
who
wanted
support
for
a
really
old
version
of
rails,
and
our
answer
at
the
time
was
sure
we'll
accept
it.
If
you
maintain
it,
but
at
which
point
they
backed
off.
But
we
didn't
really
have
a
good
way
of
like
enforcing
that
notion
that,
like
this
person,
is
the
maintainer
of
this
instrumentation.
A
J
There
is
a
it's
probably
good
to
set
a
policy
that
the
instrumentations
are
going
to
follow,
what's
supported
by
the
thing
being
instrumented
and
like
not
we're
not
not
gonna
like
when,
when
a
rails
version
goes
end
of
life.
G
That
gets
dropped.
That
is
our
policy
at
the
moment.
I
think
we've
stated
that
somewhere,
I
don't
remember
where
he
suddenly
stayed
at
intern.
I've.