►
From YouTube: 2022-01-11 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
C
C
E
D
Yeah
it's
good.
I
got
it
was
my
birthday.
My
wife
got
me
a
raspberry
pi
4..
So
I'm
excited
to
make
something.
I
don't
know
yet.
If
anyone
has
good
project
ideas,
let
me
know.
D
Yeah,
I
mean
it
was
a
little.
It
was
like
last
week,
but
thank
you.
I
appreciate
it.
It's.
It
was
it's
january
6
which
really
sucks,
because
there
was
this
whole
political
thing
in
the
us
on
january
6..
So
now,
like
my
birthday,
is
all
this,
like
you
know,
weird
news
car,
it's
just
like
a
loaded
day
and
meanwhile
I'm
just
like.
I
just
want
my
cake
and
I
just
want
to
like
sit
alone
and
eat
my
cake
and
not
have
to
like
do
listen
anyway.
E
I
have
a
new
laptop
come
on.
I
was
forced
to
upgrade
from
my
2019
macbook
to
a
2019
macbook
from
from
our
new
employer.
This
one
has
a
physical
escape
key
though
it
also
has
a
bunch
of
weird
things
like
I
need
to
request
admin
permissions
for
two
hours.
There's
like
a
button
that
I
have
to
press
for
this
stuff.
D
E
C
We
do
have
a
few
burning
questions.
I'll
add
one
more.
E
So
the
specs
sig
was
almost
exclusively
I
mean
we
did
touch
on
metrics
but,
like
the
main
item,
is
we've
kind
of
rambled
about
this
a
little
bit.
It's
the
discussion
over
what
we're
calling
the
thing.
That's
reporting
telemetry,
like
we've,
been
going
with
service
name
since,
like
the
beginning
of
open
telemetry
and
that's
worked
out
pretty
well,
but
as
people
from
client-side
and
mobile
and
more
less
traditional
applications
are
starting
to
participate.
E
I
don't
know
they
have
suggestions
around
how
we
could
make
this
a
little,
how
we
could
accommodate
those
other
applications
a
little
bit
more,
so
this
discussion
has
been
kind
of
going
on
a
little
bit
at,
I
suspect,
say.
Over
the
past
couple
weeks,
t
grin
made
this
more
recent
comment
and
I
think.
E
Service
name
has
been
one
of
these
kind
of
special
semantic
conventions,
in
that
it's
required
and
like
most
back
ends,
really
kind
of
need.
Something
like
this.
In
order
to
like
to
work
properly,
like,
usually
your
spans
are
organized
and
you're
tracing
back
in
some
way.
There's
you
know,
like
a
map,
a
map
of
things
of
applications
that
fans
aren't
coming
from
or
just
kind
of
a
anything
to
segment.
E
Your
stands
by
so
service
name
has
been
the
thing
that
has
been
used,
but
tigran,
I
think,
was
suggesting
that
maybe
we
just
get
rid
of
service
name
and
that
everybody
knows
what
the
thing
is
that
is
generating
the
spans
from
the
application
side.
I
think
that's
true,
but
for
the
back
end
we
still
need
to
kind
of
have
some
some
idea
of
what
the
label
is
of
the
thing
that's
generating
the
telemetry.
I
guess
so.
This
was
not
a
super
popular
idea,
but
it
did
lead
to
a
lot
of
bike
shedding.
E
Their
the
point
was
being
made
that
we
can
just
call
this
thing's
service
name.
Maybe
it's
not
the
most
appropriate
name,
but
a
lot
of
tracing
back-ends
have
gotten
by
calling
this
service
name
from
mobile,
apps
and
client-side
things
for
a
long
time
and
it
hasn't
been
a
big
deal.
E
But
then
there
was
a
kind
of
pushback
that
it
it's
not
the
best
term
for
things
that
are
client-side
and
it
makes
the
client-side
people
feel
like
they're
kind
of
second-class
in
hotel
and
the
most
constructive
thing.
I
think
that
I
heard
during
this
discussion
was
that
we
have
these
schema
urls.
E
You
could
have
like
a
service
schema
and
then
you
could
have
a
client
schema,
and
then
you
can
call
the
thing:
that's
generating
the
telemetry,
whatever
you
want,
but
the
schema
would
kind
of
determine
what
what
the
actual
label
you
want
to
use
in
your
back
end
is
if
that
makes
sense,
but
I
don't
know
that
it
was
enough.
There
was
a.
E
And
as
long
as
I
made
that
one
like,
I
don't
know
if
I
captured
everything,
but
it
was
a
fairly
long
and
heated
discussion,
I
think
the
I
think
there
is
a
a
rum
sig
real
user
monitoring,
sig
and
that
was
kind
of
the
outcome.
I
think.
E
Ted
was
one
of
the
people
pushing
back
saying
that
service
name
is
good
enough.
He
was
gonna
attend
one
of
these
calls
and
hear
from
the
people
saying
that
it's
not
good
enough
and
see
what
compromises
might
be
reasonable.
D
I
I'd
be
curious.
What
the
swift
open,
telemetry
swift
people
have
to
say
it
doesn't
look
like
they're
involved
in
this,
but
I
think
practically
speaking,
they're.
Probably
the
only
are
people
really
using
like
the
js
stuff
client
side.
It
feels
like
that's,
maybe
the
people
with
the
most
practical
experience
but
yeah.
I
would
hate
to
see
service
theme.
D
It
feels
like
at
this
point
it
just
a
lot
of
the
spirit
of
like
compatibility
with
open
tracing
and
open
census
and
zipkin
and
whatever
it's
like
well,
service
name
is
sort
of
required
for
that,
so
I
don't
know
it
would.
It
would
seem
like
a
dramatic
change
very
late
to
suddenly
drop
service
or
make
it
not
required,
which
is
tigran
proposed.
It
seems.
E
Yeah
yeah,
so
I
I
think
all
those
discussions
are
going
on.
I
haven't
been
going
this
thing,
so
I
don't
really
know
all
the
details,
but
just
kind
of
some
of
the
things
that
I've
some
of
the
discussions
that
I've
heard
in
the
specs
it
sounds
like
they're.
E
I
don't
know
they're
they're,
developing
their
ideas
and
plans
around
this,
but
I
think
one
of
the
things
one
of
the
backdrops
to
this
is
yeah.
I
I
think
what
you're
mentioning
is
like
open
tracing,
zipkin
jaeger.
I
think
all
these
things
have
historically
used
service
name,
and
it's
it
all.
I
think,
comes
generally
from
open
tracing,
and
this
has
been
like
good
enough
for
for
all
the
things
that
you're
reporting
stands
from
in
those
systems.
D
E
E
There
was
a
little
bit
of
time
for
metrics
at
the
end,
I
think
the
biggest
question
was
whether
or
not
I
had
like
separate
metrics
sig
meetings
or
just
kind
of
piggyback
them
on
the
spec
sig,
and
I
think
the
answer
is
piggyback
on
the
spec
sig
meeting
so
no
longer
be
a
separate
metrics,
sig
meeting.
E
I
think
this
is
the
board
for
the
metrics
api
sdk
becoming
stable.
E
E
A
Has
anyone
else
taken
a
look
at
this
yeah
I've
been
I've
seen
this
a
few
times,
it's
all
fairly
reasonable.
I've
mentioned
it
a
little
bit
in
the
past,
but
basically
one
of
the
things
we
should
do
is
see.
If
like
we
can
actually
adhere
to
something
specifically
around
redirects.
Well,
like
all
the
http
library
instrumentation
packages,
we've
written
actually
be
able
to
link
redirect
attempts
together
things
like
that.
A
This
is
about
like
that
proposal,
or
or
whatever
you
want
to
call
it
has,
is
pretty
long-running
like
there's
been
a
lot
of
discussion
around
and
they've
done
quite
a
few
revisions,
and
I
think
it
makes
a
lot
of
sense
every
time
I've
seen
like
a
portion
added
or
discussed
or
demonstrated,
it
sounds
like
even.
B
A
Redirects
actually,
really
really
like
that
approach.
My
only
concern
with
it
was
that
like
will
we
be
able
to
actually
do
it
in
all
these
libraries.
I
don't
know
if
that's
the
case,
I've
looked
at
some
of
them
like
cursory,
just
like
glanced
over
a
few,
and
it
seemed
feasible
for
like
net
http,
but
I
think
like
that,
just
the
http
gem
it
seemed
like
it
might
be
a
little
bit
difficult,
but
again
just
a
cursory
glance.
E
Yeah,
okay,
so
I
think
I
misread
the
title
and
I
was
almost
as
I
looked
at
this
in
the
the
rich
diff.
It
does
look
familiar.
I
thought
that
maybe
we
had
gone
the
next
step
and
we
actually
had
some
specs
for
the
semantic
conventions
for
http,
but
it
looks
like
this
is
just
the
roadmap
for
the
eventual
specs
that
would
constitute
a
stable
http,
so
we're
still
kind
of
in
the
the.
This
is
what
we
want
to
specify
phase
and
not
so
much.
This
is
what
we're
specifying.
A
Yeah
yeah,
that's
exactly
it
and
like
right
now,
like
in
the
repo.
There
is
like
semantic
conventions
around
http,
but
they're
not
considered
stable
they're
like
what
what
would
v1
look
like?
How
can
we
declare
this
stable
so
that
people
can
start
depending
on
some
of
the
signals
emitted
as
part
of
this,
some
of
the
things
that
got
punted-
and
I
think
the
last
time
I
talked
about
this-
was
like
certain
fields-
can
potentially
contain
sensitive
information
right,
like
your
http
target,
you
might
jam
in
a
secret
into
the
url
right.
A
What
should
we
do?
Should
there
be
specs
around
that
should
be
omitted?
Should
we
like
be
sanitizing
it?
I
think,
like
I
kind
of
pushed
for
it?
Is
that,
like?
I
think
it
has
to
be
punted,
because
that
falls
into
a
bigger
story
around
like
conventions
for
configuration
options,
and
we
don't
want
to
drag
this
out,
because
another
part
needs
to
be
determined,
because
if
we
own
it,
the
target
people
will
ask
for
it
to
be
added,
and
then
that's
a
bad
experience.
A
But
if
we
don't
or
do
at
it,
then
it
might
contain
secrets-
and
it's
like.
What's
the
right
thing
to
do
blah
blah
blah,
but
just
for
the
sake
of
actually
getting
something
pushed
out
it
where
I
think
we're
saying
like
we
were
gonna
kick
the
cat
on
that
one
because
it
just
by
virtue
of
what
it
is.
It
requires
something
around
configuration
options
which
we
don't
have
any
conventions
for
people
are
just
adding
whatever
we're
guilty
of
it.
A
A
We've
kind
of
talked
about
it
in
the
past,
like
we
collectively
is
like
this
group,
the
contrib
repo,
that
other
language
implementations
have
done
like
there's
like
the
js
and
go
contrib,
and
all
that,
and
maybe
we've
kind
of
reached
the
point
where
it
makes
sense
for
us
because
we're
seeing
more
churn
and
more
prs
coming
up
in
instrumentation
than
we
are
seeing
in
like
the
the
core
stuff
there.
I
know
myself,
I've
been
distracted.
A
I
know
I've
been
a
blocker
unintentionally
on
a
lot
of
work,
that's
being
done
by
a
lot
of
wonderful
people,
and
maybe
now
is
a
good
time
to
have
like
a
separate
repo
and
people
who
are
more
active
on
the
instrumentation.
Can
you
have
like
an
additional
set
of
maintainers
and
things
like
that
yeah?
So
that's
something
I
think
we
should
talk
about.
C
A
I
think
I
think
it
does
make
sense
at
this
point
because,
like
even
though
we
haven't
grown
substantially,
it's
like
we
could
probably
take
on
some
additional
maintainers
for
instrumentation
right
and
right
now.
It's
like
it
just
feels
like
if,
if
we're
not
like,
if
I'm
not
being
responsive
or
francis
or
matt,
it's
like
we're
kind
of
blocking
everyone,
but
we're
more
focused
on
the
like
myself
and
I'm
more
focused
on
the
fundamental
parts
of
things
right
now.
A
I
still
do
care
about
the
instrumentation
stuff,
but
the
day
job
has
been
taking
up
a
lot
of
time
right
and
it's
I
don't
want
to
like
just
like
talking
about
feelings,
which
is
always
weird
on
a
publicly
recorded
call.
I
don't
want
to
feel
like
I'm
blocking
people
anymore.
It
feels
bad.
E
Yeah
I'm
on
board.
With
this
I
know
it's
kind
of
always
been
like
a
discussion.
I
think,
going
going
way
back
in
hotel,
ruby,
it's
just
always
kind
of
been
a
matter
of
like
when
is
it
just
kind
of
like
the
the
overhead
in
managing
a
trip
repo?
Is
it's
not
trivial,
so
I
think
it's
just
always
kind
of
been
a
question
of
like
when
is
the
right
time
and
if,
if
everybody's
trying
to
feel
like
now
is
the
right
time,
it's
probably
actually
the
right
time.
I
feel
like
we've
gotten.
E
We've
had
a
pretty
long
runway
without
having
to
get
to
this
point,
but
I
could
definitely
see
it
being
beneficial
for
the
project.
A
A
A
I
think,
unless
like
this
is
just
like
a
right
off
the
cuff
thing
like
I
don't
know
if
that
makes
sense
like
if,
if
we
don't
want
to
set
up
all
the
ci
and
deployment
stuff
on
a
new
repo
repo,
like
can
we
split
permissions
in
a
single
repo
where,
like
some
people,
can
merge
to
these
code?
Yeah,
I
don't
know,
I
don't
know
if
that's
possible,
but
because
I
don't
think
we
need
to
be
as
strict
or
as
like
blocking
with
instrumentation
yeah.
I.
F
Think
other
other
language
sigs
also
segment
instrumentation
into
the
its
own
repository
separate
from
a
contrib
repository.
So
it's
kind
of
like
there's
like
what
I'm.
What
I
think
I'm
hearing
you
say
is
that
there's
different
tiers
here,
one
of
them
is
kind
of
like,
what's
official
as
part
of
the
sdk
one
part
of
it,
which
is
language,
specific
instrumentation
and
another
part
of
it,
which
is
like
how
do
we
handle
experimental
things
and
contributions
that
does
that
doesn't
impact
our
official
release,
process
and
maintenance
process
and
also
how
do
we
scale
reviewing?
F
And
how
do
we
scale
management
of
this
project?
Because
now
it's
like
there's,
we
have,
thankfully
so
many
more
contributors
participating
and
we
don't
have
the
domain
expertise
of
every
area
of
every
library
that
we're
trying
to
maintain
either
right.
F
So
you
know,
I
think
it's
a
great
idea
for
us
to
move
to
a
contribution,
or
maybe
it's
even
to
the
point
where
maybe
we
mirror
what
some
of
the
other
language
facts
are
doing,
which
or
you
know
language
implementation
are
doing,
which
is
have
the
contrib
have
the
instrumentation
and
have
the
the
the
main
sdk
repos
you
know
is
is
is
maintaining
multiple
workflows
and
actions
and
releases.
F
I
think
that's
manageable
right.
If,
if,
if
we
need
to
roll
out
of
changes
to
toys
for
some
reason,
I'm
sure
we
can
I'm
sure
we
can
handle
that.
But
for
the
most
part
you
know,
keep
the
process
the
same
in
all
of
them.
F
Right
just
know
that
what
the
contrib
package
means
is
that
it's
experimental
and
you
know
and
then
I'll
take
another
step
back
we're
still
at
zero.
We
haven't
gotten
a
one
point
overlease
on
any
of
the
instrumentation
either,
so
it
might
be
safe
to
just
say
start
with
a
contrib
repo,
that's
everything,
that's
unstable
right
now
or
pre-release
pre
1.0
and
keep
that
stuff
in
there
which
might
segue
into
the
otlp
exporter
hotline
item
that's
on
here,
but
that's
my
my
my
one
and
a
half
cents.
F
D
Could
just
jump
in
I
mean
you
know.
We
also
have
a
maintain,
like
daniel's,
doing
work
in
a
similar
space
right
now
on
like
but
he's
practically
not
involved
in
the
project.
So
should
we
just
be
if
we're
concerned
that
we
don't
you
know
robert
you
and
francis
and
matt
like
whatever
like
last
week?
Okay,
do
we
shopify
the
week
off
and
matt's,
like
god
forbid,
on
pto
or
something
like?
Should
we
just
have
another
maintainer?
D
Would
that
help
but
yeah
I
mean
broadly
and
then
drop
daniel
or
move
him
to
whatever
to
prove
so
I
I'd
love
to
have
him
be
involved
still
if
he
wants-
and
I
realize
there's
like
other
larger
political
applications.
So,
like
that's
one
thing
to
think
about,
and
then
the
other
is
like,
I'm
not
super
concerned
about.
If
every
other
sig
can
do
the
mechanics
for
the
contributor,
you
know
in
some
way
like
surely
we
have
enough
prior
art
in
context
that
we'll
be
able
to
get
something
out
the
door?
D
It's
more
like.
I
I'd
like
to
see
a
contribution
just
to
be
clear.
Like
I'm
on
same
pages,
or
I
think
it's
I
think
it's
a
useful
thing,
it
signals
the
right
things.
One
thing
I
think
is
worth
clarifying.
It
might
not
be
specific
to
this.
Sig
is
what
like
what
the
actual
code
owners
mean
for,
like
let's
say
we
have
a
you
know,
someone
wants
to
add
a
google
cloud
trace
exporter.
D
Someone
from
google
comes
along
like.
Is
that
something
the
code
owners
like
in
the
collector?
You
know
the
vendor
or
whoever
the
contributor
is
like?
Is
a
code
owner
of
that
thing?
It's
not
just
like
there's,
approvers
and
maintainers,
for
let's
say
the
collector
contrib
thing,
but
the
individual.
You
know,
processors
or
you
know
the
span
to
metrics
processor.
D
I
think
the
code
owner
is
some
guy
from
like
logs
io
or
something
so
like
is
that
the
path
we'd
want
to
take
with
contrib,
where
we'd
still
like
the
code
owners,
although
there's
approvers
or
maintainers,
like
the
code
owners
of
individual,
instrumentations
or
exporters
or
whatever
resource
detectors
would
be,
you
know,
could
just
be
some
per
you
know
whatever
it
is.
Maybe
amir
and
eve
have
a
aspect.
I
o
specific
exporter.
D
F
Right
because
it's
like
the
the
person
who
introduced
it,
may
not
have
the
capacity
to
maintain
in
the
future
right.
It's
like
it's
like
it's
it's
essentially,
this
person's
feedback
is
important
to
us.
We're
making.
D
D
It
would
be
up
to
the
code
owner
to
kind
of
like
come
with
that
fix
and
if
there's
a
period
of
enough
time,
that's
elapsed
where
they're
not
being
responsive
or
whatever
they
win
the
lottery
and
they
decide
like
you
know
like
sorry,
I'm
not
managing
tracing
repos
like
they
have
there's
like
sort
of
a
grace
period,
but
then
either
they
have
to
find
a
new
code
owner
willing
to
take
it
on
or
they
pull
it
from
the
you
know,
or
they
I
think,
maybe
they
just
label
it
as
like
super
experimental,
don't
you
know
like
good
luck,
you're
on
your
own
and
so
but
the
trade-off
there
is
like
stuff
that
might
be
more
controversial
if
someone's
willing
to
be
a
code
owner
for
it.
D
It's
a
lower
bar
to
entry,
because
they're
saying
like
I
accept
the
responsibility
of
maintaining
this
thing
and
dealing
with
the
downs
you
know
whatever
stuff
pops
up
over
the
next
couple
years,
whereas
if
someone
just
comes
in
out
of
left
field,
it's
like
hey,
I
had
a
hack
day.
I
put
this
together,
it's
a
total
mess.
D
Do
you
want
to
own
this
forever?
The
bar
is
still
higher
because
then
you
know
we
would
us
lucky.
Folks
here
would
essentially
have
to
own.
So,
like
I
think,
that's
it
kind
of
is
a
separate
question
from
you
know,
physically
moving
to
a
contributor,
which
I
just
think
is
a
good
idea,
but
if
we're
going
to
do
it,
I
think
it's
worth.
D
If
people
could
it
would
be
a
reduced
workload
to
have
you
know
folks
own
one
or
two
things
so
anyway,
that
that's
the
the
only
other
thought
I
have
on
how
many
I
still
have
to
get
them
to
my
average
stuff
to
speak
for
another
20
minutes
in
this
meeting.
But
that's
so
far
it's
all
good.
B
Please
so
in
javascript
we
had
the
same
issue.
We
started
having
a
lot
of
instrumentations
and
then
we
like
the
maintainers,
cannot
maintain
all
of
them
and
we
initially
thought
of
the
code
owners.
But
the
issue
with
code
owners
is
that
the
person
with
their
permission,
can
also
help
staff
and
run
get
objections
and
like
if
someone
comes
and
donates
an
instrumentation
and
wants
to
be
owner
of
it.
But
we
can't
give
permissions
to
the
repo
to
like
people
that
are
not
very
well
known,
so
we
ended
up
doing
something
called
component
owner.
B
It's
like
a
github
action
that
it
has
a
configuration
file.
Each
directory
has
some
on
the
sign
and
when
someone
opens
a
new
pull
request,
we
look
at
this.
I
think
it's
in
a
github
directory.
If
you
want
to
open
it
and
then
yeah
component
owners
yeah,
so
where,
for
each
instrumentation,
people
can
open
fpr
and
assign
themselves
as
a
component.
A
B
So,
even
though
it's
not
technically
possible
for
everyone
to
merge
their
own
pros
once
it's
marked
as
revealed
by
component
owner
someone
just
does
it
the
technical
part
of
merging
it
and
releasing
it,
and
it
seems
to
work
very
well
so
far.
F
Here,
do
you
mind
if
we
chat
about
this
offline
sometime,
I'd
love
to
dig
into
more
about
how
code
owners
didn't
do
what
you
were
looking
for
and
and
why
the
component
was
necessary
in
this
case,
I'd
like
to
as
a
as
a
employee
of
github
I'd
like
to
learn
why
this
was
a
challenge
for
you,
but
that
would
not
be.
We
don't
have
to
talk
about
that
during
this
meeting.
But
I
appreciate
that
you
brought
this
out.
B
So
actually,
daniel
dayla,
if
you
know
him
from
javascript
thing,
he
wrote
all
this
stuff.
So
he's
the
one
to
give
you
the
best
consoles.
D
E
Yeah,
so
I
think
we
can.
I
think
this
is
this
is
going
to
be
a
probably
an
ongoing
project
trying
to
get
a
contrib
repo
up
and
running
and
kind
of
all
of
our
processes
around
it.
E
E
A
Yeah,
I
think,
like
we
don't
have
to
decide
anything
right
now,
but
I
think
it's
like
a
good
time
to
start
thinking
about
it
again
and
what
what
makes
sense
just
to
kind
of
like
re-echo,
like
the
motivation
here,
is
like
the
the
core.
Maintainers
right
now
are
more
focused
on
the
non-instrumentation
parts
and
it
probably
makes
sense
to
have
a
new
repo
with
like
a
new
set
of
maintainers
that
are
gonna
watch
over
lovingly
of
the
instrumentation
right.
A
It's
not
that
like
we'll,
be
completely
disconnected
or
that's
the
intention
it's
just
like
just
to
unblock
and
make
this
like
a
healthy
project
where
people
feel
that
they
have
autonomy
to
like
push
things
forward
and
stuff
like
that,
that's
like
the
main
motivation
trying
to
push.
But
again
I
don't
think
we
should
try
strive
to
decide
like
right
this.
Second,
because
it's
something
worth
thinking
on
a
little
bit
but
yeah
next
meeting.
E
Yeah,
I
think
ultimately
like
in
my
mind,
I'm
just
kind
of
wondering:
when
is
the
right
point
to
request
a
repo
and
actually
get
a
repo
set
up.
I
feel
like
we're
a
little
early
on
that,
but
I
think
we
know
we're
going
to
want
it
and
then
I
think
we
kind
of
just
had
decisions
as
to
next
step
is
what
do
we
is
there
anything
today?
That
is
in
our
main
repo,
that
we
want
to
move
there
and
then
like?
A
Yeah
that
makes
sense
to
me.
I
I
don't
know
if,
like
I'm
misunderstanding
it,
but
I
thought
when
people
do
like
the
contrib
split
out,
usually
what's
not
in
the
contributor
like
in
just
like
the
dash
language,
repo
is
usually
things
that
are
required
as
part
of
the
sdk,
so
like
the
exporters
that
are
required
would
be
in
there.
Exporters
that
exists
like
outside
of
like
these
are
required
to
be
like
stable
1.0
would
be
in
contrib
right.
A
So
like
eric's
example,
I
think
of
like
the
google
exporter
or
something
like
that.
If
it's
specific
to
google
and
it
wasn't
defined
anywhere
and
like
the
open,
telemetry
specification,
then
it
would
exist
in
contrib.
A
F
Because
so
yeah,
maybe
instrumentation
resource
detectors
and
any
other
like
extensions
like
people
trying
to
do
stuff
with
logging
packages
or
testing
packages
or
whatever.
E
E
E
Have
we
discussed
this
enough
for
this
week.
A
C
E
I
was
going
to
jump
into
the
burning
questions
really
quick.
This
first
one
is
from
me
by
a
tristan.
He
was
just
kind
of
asking
me
like.
Why
is
the
otp
exporter
not
1.0?
I
think
they
would
like
to
use
it
at
splunk
but
they're
for
the
benefit
of
their
customers.
They
really
don't
want
to
recommend
anything.
That's
not
1.0,
so
I
yeah,
I
didn't
want
to
give
them
bad
info.
E
E
I
don't
know
if
they're
all
like
tracing
has
been
pretty
has
been
stable-ish
for
a
long
time,
so
they
might
effectively
be
fine,
but
it
might
not
be
a
horrible
idea
to
update
those
and
consider
slapping
a
1.0
on
this
at
some
point
but
yeah.
I
was
just
going
to
ask
if
there's
a
good
reason
why
things
wouldn't
be
able
to
be
a
1.0
and
what
would
need
to
be
done.
I
guess
to.
A
A
Yeah,
I
I
don't,
I
don't
know
if
we
do.
Does
anybody
know
if
we
do.
E
A
Yeah
because,
like
we've,
been
like
consuming
this
for
oh
quite
a
while
now
like
the
predecessor
to
this,
because
it's
like
the
otp
exporter
was
like
kind
of
a
rewrite
of
something
we
had
internally,
which
that's
been
used
for
a
while.
So
I
think
we've
been
like
using
this
for
a
couple
years
like
it
feels
stable.
A
We
have
hundreds
of
apps
using
it
right
so
but
again
like
I,
don't
know
the
formalities
right.
That's
the
part
that
I
think
we
need
to
double
check
like
I
can.
I
could
take
the
action
item
of
going
through
the
spec
for
it
again
to
see
if
we're
spec
compliant,
but
I
don't
know
like
the
formal
process
like
if
we
need
someone
to
sign
it
with
blue
ink
or
something
like
that.
D
The
the
I
don't
know
if
the
schema
url
stuff
is
1.0
for
no
tlp
exporter,
but
that's
missing
currently.
E
My
gut
feeling
is
that
if
our
products
are
kind
of
out
of
date,
we
should
consider
getting
them
on
something
a
little
bit
more
current
but
figuring
out
like
what.
What
that
version
is,
is
the
most
recent
or
is
it
the
most
appropriate
to
the
one
point
onus
of
our
sdk?
If
that
makes
sense,
because
I
feel
like
there
have
been,
there
have
been
revs
of
things
beyond
1.0.
D
I'm
happy
to
do
I'm
not
sure,
what's
needed,
happy
to
help
do
any
of
the
actual,
like
a
work
required
from
you
know
like
feedback
or
something
can't
hurt
to
get
a.
If
we
do
get
a
tc
review,
it
might
just
be
good
to
get
it
like.
Take
what
we
can
get
you
know
and
if
they
say
there's
some
things
we
need.
F
Yeah
I
pinged
carlos
in
the
thread
in
slack
that
tc
had
posted
this.
So
maybe
he'll
have
some
feedback
for
us
about
it,
because
he's
the
one
that
did
the
tc
review
for
the
sdk
right.
E
Yeah,
I
I
was
going
to
ping
carlos
to
find
out
if,
if
we
need
a
review
and
then
if
he
says
yes,
then
I
think
that
we
should
figure
out
what
work
we
need
to
do
before
asking
for
the
review
and
kind
of
go
from
there.
A
I
think
the
last
time
I
even
heard
anyone
really
talk
about
that.
It
was
francis
and
he
did
have
some
thoughts
on
it
he's
out
today,
but
I
can
definitely
tug
on
his
sleeve
tomorrow
and
see
if
he
remembers
what
or
why
or
he
has
any
concerns
about
us
bringing
it
current
and
then
I
could
come
back
to
the
next
meeting
with
some
actual
answers
there
on
that
regard.
So
I
can
own
that
piece
as
well.
E
A
So
I
think,
I
think
we're
recalling
the
same
thing
so
I'll
have
to
dig
it
up
and
I'll
bug
them
and
see
if
there's
any.
If
he
has
any
concerns,
I
I
believe
we
should
be
okay
but
again
I'll.
Look
into
that.
A
We
should
avoid
adding
any
really
strong,
locking
around
it
just
from
practical
experience
anytime,
you
pin
it
low
or
high,
or
do
anything
like
that.
You
cause
a
lot
of
issues
for
a
lot
of
people.
A
But
at
the
same
time,
if
we
pin
this
really
high,
we
run
the
risk
of
preventing
people
from
updating,
specifically
and
so
and
then
conditionally
pinning
the
version
for
the
platform
that's
being
used.
That
feels
a
little
bit
scary
too.
It
feels
like
it
can
get
pretty
hairy
like
it's,
not
necessarily
bad,
but
again,
it's
like
eventually
someone's
gonna
forget
why
we
did
that
and
it
becomes
weird
and
then
people
will
be
afraid
to
unpin
it
or
change
it,
and
things
like
that.
A
F
Know
yeah,
we
are
constraining
to
a
minimum
version
of
three
seven,
which
is
like
a
really
old
version
versus
like
a
stable
version,
and
I
think
that,
generally
speaking,
our
attitude
towards
the
maintenance
of
our
dependencies
and,
in
particular
like
I
think
we
set
a
precedent
to
say,
we
want
stable,
secure
versions.
We
will
we
will
support
stable,
secure
versions
of
things,
so
we're
not
going
to
continue
to
maintain
a
version
that
is
end
of
life
for
rails,
right
right.
A
So
I
I
I
I
agree,
I
don't
think
we
necessarily,
I
think,
like
we
could
potentially
bring
up
the
minimum
version,
but
we
we
should
tread
lightly.
I
just
I've
played
so
much
with
this
exact
issue
of
when,
like
protobuf
had
a
memory
leak
and
I
tried
to
pin
it
lower
and
then
it
broke
a
bunch
of
apps
because
they
were
depending
on
the
later
version.
A
You
know
you
try
to
bring
it
up,
and
now
a
bunch
of
apps
are
depending
on
an
older
version
and
they
couldn't
so
it
like
it.
Just
you
really
really
find
yourself
in,
like
the
truest
sense
of
dependency
hell
for
like
localized
to
shopify
and
the
applications.
I
was
dealing
with
that
I
could
interact
with
these
people
firsthand
and
things
like
that,
and
it
softened
the
blow
a
bit,
but
it
was
like
a
huge
sense.
Like
a
source
of
toil,
I
would
feel
uncomfortable
pushing
that
out
into
the
broader
ruby
ecosystem.
C
All
yeah
I
mean
I.
D
I
don't
care
about
like
yeah,
I
think
the
different
platforms
having
different
version
you
know
pins,
is
dumb
and
not
a
practice
that
I've
really
seen
in
ruby
so
and
ariel
we're
talking
about
it.
But
yeah
I
mean
I
just
don't
know
what,
like
the,
I
don't
think
it's
really
a
choice.
D
Only
but
like
yeah
I
mean
I
don't.
I
just
don't
know
what
the
taking
off
like
taking
taking
a
step
back
from
saying
like
well,
what
would
be
the
the
best
thing
to
do
from
a
just
usability
and
friendliness
to
like
user's
perspective
like
what's
like
the
technically
right
thing?
We
have
to
do
to
abide
by
the
there's.
No
such
thing
as
a
constitution
for
open
telemetry,
but
you
know
like
by
their
guidelines
you
know,
and
if
the
guidelines
are
are
difficult,
then
that's
you
know
whatever.
F
I
was
just
gonna
say
in
this
specific
case
we're
talking
about
like
just
looking
at
google
protobuf
right
now.
We
are
declaring
that
we
only
support
minor
version,
bumps
we're
accepting
patch
and
minor
version
bumps
starting
at
3.7.
F
It's
not
open
enough
right
now
to
say
we
would
support
4.0
for
the
exporter
in
particular.
So
you
know.
Maybe
we
need
to
clarify
that
align
it
with
what
eric
is
saying
with
what
the
spec
community
would
say,
or
what
other
implementations
are
doing,
so
that
we
can
follow
that
follow
that
along.
F
But
then
there's
also
the
the
other
part
of
that
which
is
the
vulnerable
dealing
with
vulnerabilities.
And
if
we
can
do
more
things
to
you
know,
because
we
have
a
minimum
set
of
things
that
we
depend
on.
But
we
can
leverage
tooling
like
dependent
bot
to
make
us
aware
that
the
packages
that
we
depend
on
the
minimal
amount
of
packages
we
do
we
depend
on,
have
a
vulnerability
and
that
we
can
make
a
decision
about.
A
So
I
think
that's
a
good
point
like
I
think
the
reason
the
the
way
it's
set
up
as
it
is,
is
probably
just
historical
from
like
shopify,
because
we
have
said
that,
like
I'm
just
looking
at
it
right
now
or
is
it
yeah
the
three
seven
thing
that
just
came
from
shop
five
because
of
I
think
there
was
a
there,
was
a
fear
of
like
a
major
bump
because
we've
been
burned
by
it
so
many
times
that
we're
like,
let's
not
freely,
allow
major
bumps
to
occur
in
the
wild
because
we
don't
want
to.
A
We
don't
want
to
deal
with
it
right
so
when
we
or
when
francis
rewrote
it
for
open
telemetry.
He
probably
just
copy
and
paste
that
over.
That's,
like
my
honest
intuition
to
that,
but
to
the
point
of
like
the
vulnerability
like
it
would
be
different.
If
we
were
saying
that
we
depend
on
the
world
vulnerable
version.
That
would
be,
I
think,
a
very
different
narrative,
but
right
now
we're
just
leaving
it
open.
A
We're
saying
use
whatever
version
you
like,
but
because,
if,
if
we
try
to
curate
every
single
potentially
vulnerable
list
like
what
does
our
gem
spec
file,
look
like?
Is
it
just
like
a
massive
exclusion
list
of
versions
for
platforms
and
just
think
of
like
what's
like
realistic.
B
A
What
what
is
pragmatic?
It's
like
we
can
say
that
if
you
use
this
specific
version,
it'll
break
open,
telemetries
exporter
like
don't
use
below
this
version,
because
it
doesn't
work
right
but
again,
like
it's,
it's
kind
of
hard,
I'm
I'm
more
airing
to
the
side
of
like
we
should
be
leaving
it
open
because
we're
not
forcing
people
to
use
a
vulnerable
version
if
they
do
use
a
vulnerable
version.
F
Yes
I'll
add,
I
will
add
this:
let's
get
rid
of
the
platform
discussion,
because
we're
not
talking
about
targeting
specific
platforms
and
having
different
versions
for
platforms.
That's
off
the
table.
F
And
how
do
we
want
to
communicate
that
in
in
in
packages
that
we
depend
on
and
in
particular
google
protobuf,
which
is
the
only
like
real
one,
that
we
have
a
hard
dependency
on
for
the
otlp
exporter
and
dealing
with
vulnerabilities
in
those
cases?
And
that's
all
because
I
don't
think
we
have
any
other
package
that
we
depend
on
right.
F
A
So
it's
the
the
export
formats
right,
I
don't
I
don't
know,
I
don't
think
we
have
one.
I
don't
know
if,
like
open,
telemetry
has
like
a
wider
spec
around
this
stuff,
but
it's
like
to
me,
I
I
guess
I'm
trying
not
to
be
stubborn,
trying
to
be
open-minded.
It's
just
like
this
just
falls
into
package
management
for
the
owner
of
the
the
application.
That's
consuming
this
stuff
right
it
I
don't
know.
I
I
think
it's
a
slippery
slope
if
we
like
try
to
take
that
on,
but
then
again
like.
A
Maybe
something
will
come
up
in
two
weeks
from
now
and
I'll
completely
flip
my
opinion,
but
like
internally
in
shopify.
We
because
we
use
our
wrapper
gem
and
people
are
using
m1s.
Now
our
minimum
version
is
like
3.19.1
or
something
like
that
or
that's
what
it
is
yeah.
Something
like
that,
because
we're
saying
that,
like
we
just
don't,
want
everyone
to
have
to
deal
with
bumping
it
themselves
right.
A
D
I
mean
for
what
it's
worth
like.
3.191
is
literally
the
only
version,
that's
impacted
by
this,
because
it's
the
only
version
that
supports
jruby.
So
I
wonder
if
we
could
just
exclude
that
single
version
would
be
a
lower
yeah.
D
I
don't
know
I
mean
I
think,
like
I
said
like,
I
think
it
doesn't
matter
what
would
be
the
nice
thing
to
do
or
like
the
convenient
thing
to
do
if
there's
precedent
for
what's
the
expected
behavior
according
to
you
know,
ben
siegelman
and
whatever
open
telemetry
has
decided
is
like
we
might
just
be
at
the
mercy
of
like
okay.
These
are
the
I
agree
with
you,
robert
I'm
just
saying
like
I
don't
know
the.
D
If
there's
actual
you
know,
I
don't
know
if
we
have
a
choice
in
the
matter,
if
we
do,
I
tend
to
agree,
I
think
it's
like
you
know.
We
shouldn't
do
anything
if
we
don't
like
oh
we're
over
time,
but
we
yeah-
maybe
maybe
I
have
to
reach
out,
should
you
should?
Could
that
be
an
action
item
like?
Should
I
maybe.
D
A
F
Colors
all
right
well,
tc
was
talking
about
writing
a
blog
post.
That
was
something
that
we
didn't
discuss
and
then
the
last
thing
was
robert.
Please
take
a
look
at
that
gem,
specs
instrumentation
npr,
please
and
that's.
F
No
sorry:
okay,
that's
okay!
If
we
is
there,
have
you
taken
a
look.
A
F
Well,
if
you,
if
you
want,
I
could
try
to
do
something
later
in
the
week.
If
you
want
to
pick
me
on
slack,
I
can
set
up
a
zoom
for
that
sure
right,
I'm
a
balanced
piece.