►
From YouTube: 2022-04-12 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
Oh
yeah,
you
you
don't
think
you
know,
I'm
muted,
the
the
the
auto
collector
does
lightstep
plan
on
releasing
a
receiver
for
it
on
the
control
package.
C
And
right
now
we
have
deployments
with
micro
satellites,
but
we
want
to
start
using
collectors
so
that
we
can
have
a
more
rich
experience
for
doing
things
like
attribute,
processing
and
generating
metrics
from
some
of
our
traces
and
some
log.
Events
right
like
taking
span
events
and
converting
them
to
logs.
A
C
So
we
want
to
do
all
that
stuff
in
the
collector
pipeline,
but
this
is
making
a
little
bit
difficult
for
us
with
the
fact
that
you
know,
though
the
collector
doesn't
receive
lights
up
format
in
either
that
you
know
http
or
json
or
in
grpc,
for
a
lot
of
our
older
goal.
Links
of
I
know
that
that
doesn't
have
to
do
with
anything
with
this
meeting,
but
I
figure
since
I
have
your
ear.
B
B
All
right
yeah,
I
I
will
go
back
to
people
and
talk.
B
D
But
what
is
open,
tracing-ish
eric?
It's
like
I
mean
it's
just
apis
right,
really
is
open
tracing.
Essentially
it's
a
definition
for,
like
the
sdk
like
there
is
no
format.
That's.
D
C
B
B
Oh
no:
well,
we
have
the
usual
crew.
Shall
we
go
ahead
and
get
started.
A
B
B
There's
a
question
about
metric
reader
force
flush
somewhere
in
the
metric
spec.
There's
some
verbiage
saying
you
must
call
force
flush
on
all
metric
readers,
blah
blah
blah
blah.
But
then
the
metric
reader
api
does
not
specify
a
force
flush.
So
diego
was
asking
this
question
and
there
was
no
answer,
but
the
one
thing
that
I
did
learn
that
I
probably
should
have
known
before
is
there's
a.
B
B
There
is
this
issue
about.
As
I
understand
it,
the
idea
is
like
right
now.
Semantic
conventions
are
really
kind
of
siloed.
In
that
you
have
like.
You
have
attributes
that
go
on
on
spams.
You
have
attributes
that
go
on
metrics
and
then
you
have
attributes
that
go
on
logs
and
in
many
cases
these
are
the
same
attributes,
but
they
are.
B
They
are
siloed,
at
least
from
a
spec
perspective,
and
I
think
the
goal
is,
or
the
hope
is
to
be
able
to
just
define,
like
a
set
of
like
common
common
ash,
reducing
conventions
that
can
be
applied
to
all
three.
B
B
B
E
I
haven't,
I
haven't
been
in
a
while.
To
be
honest,
I
haven't
been
able
to
go
well
that
that's
what
it
was.
I
don't
know
if
it's
changed
like
it's
been
probably
a
couple
months
since
I've
been.
B
B
The
community
page
maybe
they're
like
winding
down
that
instrumentation
sig
and
rolling
this
back
into
like
a
spec
sig.
I
didn't
totally
catch
what
was
going
on
so
so
we
will
gloss
over
this
bullet
point
and
move
on
to
hdp
required
versus
optional
attributes.
We
talked
about
this
a
little
bit
last
time.
I
think.
B
This
is,
there
was
kind
of
like
a
bunch
of
basically
a
refactoring
of
the
http,
the
http
attributes,
and
I
think
a
lot
of
them
were
being
removed.
A
lot
of
them
were
being
changed,
and
I
think
this
has
been
like
a
round
of
feedback
and
I
remember
at
least
the
feedback
being
like
this
changes.
Almost
everything
initially,
I
don't
know.
B
There
has
been
some
discussion
on
here.
I
think
semi
relates
to.
B
B
Do
you
know
if
that
has
an
effect?
Yet
robert.
E
It's
not
for
us
like,
because
none
of
our
instrumentation
is
marked
as
stable
right,
like
it's
all
unstable
and
so
then
there's
like
kind
of
pat
different
paths
to
stability.
If
we
mark
one
as
stable
but
don't
introduce
a
schema,
then
it's
considered
a
fixed
schema
instrumentation
and
it
can
never
change
ever.
E
I
think,
if
a
new
schema
is
published,
then
you
can
use
that
because
I
guess
the
idea
is
then
like
back
ends
will
know
how
to
transform
them.
So
then
you
get
some
some
mobility
in
changing
and
again
the
the
restrictions
don't
apply
to
things
that
are
additive
like
adding
an
attribute
is
not
breaking.
E
Changing
or
removing
is
it
also
has
kind
of
some
like
the
implication
that
any
of
the
optional
stuff
we're
doing
should
be
in
the
spec
right,
like
so
anything
behind
a
config
variable
to
add
or
like
turn
on
or
offer
an
attribute
should
still
be
in
the
spec
flagged
as
an
optional,
optional
thing.
So
like
yeah
it
just
it's
adding
a
lot
of
like
structure
and
ceremony,
but
that
structure
in
ceremony
only
takes
effect
once
we
start
saying.
E
Oh,
this
instrumentation
is
in
fact
stable,
yeah
and
then
things
that
are
dynamic
by
nature.
Let's
say
you
have
something
that
can
like
conditionally
append
some
attribute
of
your
choosing
then
like
that.
That's
not
protected
in
any
sense,
because
it's
like
you're
you're
doing
it
like
the
application
owner.
It's
not
us.
B
Right,
yeah,
all
right
that
that's
useful,
so
so
as
long
as
your
instrumentation
is
unstable,
we're
fine
at
least
for
now.
As
soon
as
it
goes
stable,
you
should
introduce
a
schema
and
not
change
it
until
april.
First
2023.
B
But
the
other
gotcha,
I
guess
I'm
just
summarizing
what
you
just
told
us,
is
that
any
kind
of
like
configuration
for
the
for
instrumentation
should
be
should
be
specced
things
that
allow
you
to
kind
of
like
toggle,
whether
or
not
you're
collecting.
B
E
Okay,
it
doesn't
need
to
document
the
flag,
it
just
says
it's
optional,
I'm
sure
it'll
eventually
get
there,
but
as
of
right
now,
that's
like
my
interpretation,
and
I
think
I
talked
about
this
a
little
bit
with
francis
earlier
yesterday.
Last
week.
I
don't
know
whenever
that
got
posted
in
the
ruby
channel
yeah
we
talked
about
it.
E
That's
kind
of
the
conclusion
we
came
to
and
then
like
kind
of
things
that
we
we
as
like
hotel,
ruby
people
should
follow
on
with
is
like
we
should
have
bring
back
some
sort
of
like
chart
in
repo.
That
says
like
these
are
all
unstable
right.
D
I
think
it's
like
personally,
I
don't
think
there's
a
ton
of
benefit
to
marketing
stuff
staple
and,
like
a
lot
of
the
benefits,
are
like
product
content
marketing
and
not
like
as
maintainers
like
we're
monkey
patching
other
people's
libraries,
it's
a
little
bit
like
presumptuous
to
be
like
this
is
stable.
Instrumentation
like
we
don't
contr.
You
know
like
what
we're
doing
is
inherently
like
a
little
janky
and,
like
I
don't
know,
I
it's
unclear
to
me
what
the
what
the
real
benefits
are
here.
D
Besides,
like
being
a
check
box
on
some
vendor
user,
you
know
vendor
rf
request
for
proposal
from
a
customer.
Like
that's
my
opinion,.
E
What
I
took
away
from
it
is
like
I
like,
I
totally
agree
with
you,
but
I
think
the
idea
is
like
this.
Stability
is
meant
to
infer
the
attributes,
aren't
changing
not
like
the
instrumentation
can
never
break
right
like
because,
obviously
like.
I
totally
agree
because
it's
like
what
we
do
is
inherently
unstable
right.
Someone
does
a
patch
fix
that
breaks
the
underlying
api
and
then
our
instrumentation's
worked
right,
but
I
think
the
idea
is
like
if
we
say
it's
stable,
it's
like
our
dot.
E
Http.Status
code
isn't
gonna
like
disappear
on
you
yeah,
but
again,
if,
like
the
underlying
implementation,
blows
up
in
some
way,
then
yeah,
but
I
think
it's
like,
I
think,
there's
some
level
of,
like
forgiveness,
that
has
to
exist,
is
like
we're
agreeing
to
not
randomly
disappear.
Your
attributes,
if
you
commit
to
using
this
instrumentation,
I
think
that's
like
fair
yeah.
I
think
that's
that's.
D
A
good
point
and
yeah
like
if
the
goal
is
like
people
want
to
be
able
to
start
to
alert
and
you
know
generate
metrics
on
the
fly.
They
need
expected
formats
and,
like
that's,
I
think,
that's
fair.
I
worry
a
lot
of
that
gets
lost
in
translate.
You
know,
people
see
a
status
on
the
top
page
and
they
just
skim.
They
don't
care
about
the
saturday
but
yeah
like
it
is
important
because
you
just
can't.
If
you
can't
rely
on
consistent
span
formats,
then
you
can't
generate
requests
per
second
or
whatever
cool
so
good
point.
A
To
pile
on
here,
maybe
on
the
other
side,
as
I've
been
working
in
the
redis
instrumentation
lately,
and
it
seems
possible
that,
like
a
minor
version
because
we're
like
monkey
patching
like
a
minor
version,
release
might
end
up
rendering
some
attribute
totally
useless.
So
for
like
we're,
calling
super
on
some
method
and
expecting
a
response
to
have
certain
things
that
we
then
use
to
certain
characteristics
or
properties
that
we
then
use
to
generate
an
attribute.
There's
really
there's
very
little.
Stopping
like
redis
rb
from
being
like.
A
Oh
no,
like
we
changed
the
entire
api
and,
like
you,
no
longer
have
access
to
like
the
chokepoint
that
you
were
using.
No
longer
has
the
the
properties
required
to
like
satisfy
a
theoretically
stable
attributes
list.
But
I
mean
I
don't
know,
maybe
like
the
open,
telemetry
police
would
come
to
come
to
to
like
take
us
away,
but
that's
definitely
been
interesting.
E
E
Now,
let's
say
it's
like
a
silent
kind
of
like
failure
where
the
attribute
just
goes
missing
and
we
don't
know
right,
someone
bumps
it
assuming
people
care
gets
reported
back
to
us
and
we
either
find
a
fix
forward,
or
we
say
that
like
through
whatever
mechanisms,
this
is
no
longer
possible
and
yeah.
You
say
that
like,
as
of
whatever
version
like
you
wouldn't
say
that
the
instrumentation
is
unstable,
you'd
say
like
reddest
versions,
x,
y
z
and
up
or
whatever
are
are
no
longer
able
to
right.
E
Do
that
and
it's
like,
I
don't
know
I
feel
like
it's.
I
I'm
not
worried
about
like
the
open,
telemetry
police,
it's
more
like
as
long
as
we're
being
conscious
to
do
the
right
thing
and
like
yeah.
B
Yeah
so
bring
that
all
back
around.
I
think
that
adds
a
little
bit
more
context
to
some
of
tigrin's
comments
on
this
one,
and
I
think
he's
basically
saying
that
if
20
2180,
which
we're
just
looking
at
gets
accepted,
then
they'll
have
a
formal
stance
and
can
say
that
all
instrumentations
are
unstable
and
then
they
can
make
the
changes
introduced
by
spr
so
so
yeah.
I
guess
it's
good
that
everything
we
have
is
unstable
so
that
we
can
still
kind
of.
I
don't
know.
B
Solidifier
attributes
make
sure
we're
happy
with
them,
but
at
the
end
of
the
day
this
pr
exists.
It
will
have
some
kind
of
impact
on
our
on
our
http
instrumentation
and
yeah.
We'll
probably
have
to
make
some
updates
to
do
some
renaming
and
other
such
and
I
don't
know
I
kind
of
feel
like
that-
might
be
a
good
chance.
I
know
as
as
we've
worked
through
this
instrumentation,
there
has
been
some
opportunities
and
some
desires
to
have
like
some
more
like
common
shared
stuff
between
them.
B
Kind
of
independently
and
we
can
consider
trying
to
clean
a
little
bit
that
up.
If
we
haven't
already.
E
One
of
the
things
like
I'm
thinking
when
I
think
about
like
stability
around
instrumentation,
like
it's
there's
like
a
slippery
slope
for
like
ending
up
in
like
bike
hell,
but
like
it's
hard
for
me
to
feel
like,
I
would
want
to
mark
any
of
our
instrumentation
stable
until
there
is
some
sort
of
conventions
around
configuration
right
because
like
if,
like
you'd,
almost
need
like
attribute
stability
guarantees
and
then
like
configuration
stability,
guarantees
right,
because
if
we
say
that
say,
http
stable
and
we
just
kind
of
run
wild
with
whatever
configuration
options
that
we
have
available
for
it.
E
Even
if
we
try
to
do
the
right
thing
and
then
the
spec
comes
up
with
like
this
is
how
configuration
works
for
instrumentation.
It
needs
to
be
able
to
read.
A
file
needs
to
be
able
to
do
this
if
you're,
using
this
type
of
naming,
prefer
this
like
wordage
blah
blah
blah
like.
If
that
comes
out,
we
already
say
we're
stable,
then.
Does
that
mean
we
have
to
wait?
What,
like
the
three
years
before
we
can
break
all
of
those
configuration
options?
So,
like
I
I
don't
know.
E
This,
maybe
is
like
a
comment
about
nothing,
but
I
I
just
maybe
will
just
change
my
perspective
as
time
goes
on
with
this
work,
but
like
I'm,
going
to
be
pretty
apprehensive
to
call
any
instrumentation
stable
until
we've
like
defined.
What
configuration
is
actually
supposed
to
look
like
in
open
telemetry.
B
No,
I
I
think
that's
definitely
a
good
point,
I'm
not
sure
if
anybody
is
thinking
that
far
ahead
yet,
but
if
those
conversations
do
do
come
up
I'll
make
a
note
to
at
least
read
the
room
in
terms
of
what
you
are
thinking
in
terms
of
of
configuration
and
maybe
at
least
make
sure
to
raise
that
point.
B
Yeah,
I
guess
that
was
the
the
end
of
the
spec
segment.
So
I'm
not
sure
if
we
want
to
continue
talking
about
instrumentation
and
instrumentation
stability.
If
there's
something
else
on
folks
minds.
C
More
around
the
for
specific
attributes
that
we
add
that
are
not
part
of
the
semantic
conventions.
I
don't
know
what
the
if
there
is
a
defined
process
for
us
to
extract
those.
So
I
notice,
for
example,
like
in
our
instrumentations,
we
don't
name
space,
particularly
attributes
that
may
or
may
not
be
useful
for
other
frameworks.
C
C
It
doesn't
seem
like
it's
sensible
for
let's
say
the
http
namespace,
but
perhaps
some
sort
of
namespace
like
that
and
then
also
publishing
the
existing
attributes
in
some
way,
so
that
people
know
what
to
expect
because
right
now
they
have
to
dig
through
code
in
order
for
them
to
figure
out
what
the
published
attributes
are,
or
they
have
to
look
at
the
end,
result
right
and
scan
them
and
and
and
see
was
there.
So
it's
a
little
bit
of
a
discoverability
problem.
B
I'm
just
trying
to
think
through
this,
and
one
thing
that
is
on
my
mind,
is
that
you
know
we
have.
We
have
a
semantic
convention
gem
for,
like
the
official
official
semantic
adventures
that
we're
using
I'm
just
kind
of
wondering
if.
B
If
we
had
like
some
formal
way
to
define
kind
of
the
unofficial
semantic
conventions
that
we're
using
it's
like,
you
could
kind
of
like
auto
generate,
you
could
probably
auto
generate
the
the
attributes
that
are
used
at
least
out
of
the
code.
B
If
you
wrote
it
in
such
a
way
that
you
were,
you
ended
up,
you
know
having
some
some
constants
or
name
spaces
that
you
could
kind
of
iterate
through
and
output
into
a
table.
D
Data
dog's
approach
was
somewhat
similar
to
this
and
it
was
fine,
but
I
don't
know
it's
mostly
just
a
matter
of
like
it's
still
just
like
mania.
At
some
point.
It
just
becomes
like
kind
of
manual
work,
no
matter
what
for
a
little
bit.
Sorry,
then
that's
fine
to
have
but
yeah.
I
think
that
that
would
be
useful
and
we've
seen
internally.
C
Because
you
know
part
of
it
is
really
wanting
to
for
me
to
wrap
my
head
around
publishing
schemas
and
how
these
attributes
and
the
schema
and
schema
urls
come
into
play
for
individual
instrumentations.
D
I'm
happy
to
sink
offline
or
something
I'm
happy
to
talk
about
like
some
of
the
road
bumps.
What
are
they
called
that,
like
we've
hit
with
this,
if
we
shared
experience,
although
I
haven't
looked
in
like
a
month
so.
B
Yeah
just
kind
of
like
off
the
top
of
my
head
like
something
I
think
that
could
work
is.
You
could
just
have
like
some
kind
of
like
defined
convention
macro
that
you
could
start
kind
of
like
littering
in
the
kind
of
top
level
of
your
instrumentation
kind
of
name
space.
And
then
you
would
that
would
kind
of
define
a
constant
for
you
that
you
could
use
in
your
instrumentation
and
then
that
would
be
a
way
that
we
could
basically
introspect.
E
C
Because
we,
we
do
have
like
the
semantic
conventions,
gem
and,
if
that's
a
feature
that
we
can
have
somehow
to
hook
in
and
say
I
am
registering
this
new.
This
instrumentation
is
registering
this
convention
in
some
way
and
in
the
end,
to
be
able
to
process
that
and
use
that
that
might
be
a
way
to
do
it.
C
B
That
sounds
good,
it
sounds
like
eric
has
some
ideas
and
if,
if
everyone
wants
to
discuss
and
come
up
with
some
proposals,
I
think
all
of
us
would
be
on
board.
So
maybe
we
can.
C
I
think
really.
This
was
like
feedback
from
francis,
so
if
anybody
has
a
line
on
him
to
just
paint
give
him
a
little
gentle
notch.
Look
at
this
again.
He
was
just
concerned
about
it
being
very
noisy
with
too
many
log
error
messages.
So
I
made
a
change
and
then
I
made
robocop
happy.
So
I
don't
know
these
commits
are
are
unhelpful
that
are
live
the
code
changes
with
me
or
something
like
that.
You
know,
but
there
if
any
of
y'all.
C
C
A
B
We
talked
about
this
quite
a
bit
last
meeting
and
I
think
we
were
talking
about
whether
we
needed
to
check
gem
loaded,
specs
and
a
constant
or
just
a
constant
or
prefer
the
constant
and
then
do
more
fancy
things.
C
Otherwise,
I
think
the
last
like
discussion
can-
and
I
don't
want
to
use
the
word
contentious,
but
it
was
the
thing
that
required.
Some
agreement
was
that
if
we
found
someone
the
the
thing
that
I
was
at
the
same
time,
considering
introducing
with
this
pr
was
dropping
end-of-life
versions
of
library
and
specifically
around
aws
and
the
aspect
io
team
said
hey.
We
really
would
like
for
these
to
stick
around
and
so
recorded
in.
There
is
a
decision
and
a
comment
that
is.
C
C
I
asked
for
some
feedback
from
aws
and
see
if
maybe
nathan
might
be
able
to
connect
us
with
people
at
aws
to
find
out,
what's
the
most
appropriate
way
to
implement
the
you
know,
versioning,
because
aws
has
this
other
component
in
it,
where
you
register
all
of
your
where,
where
the,
where,
where
you're
supposed
to
register
hooks,
which
is
called
the
seahorse
client,
and
that
is
a
sub
gem
as
part
of
the
the
big
jam
and
you
it's
it's
they're
sort
of
like
observer
as
part
of
the
as
part
of
their
sdk.
C
But
I
haven't
heard
back
from
them
yet
and
but
so
I'm
all
of
that
being
said,
we're
leaving
support
for
the
aws
gem
in
cases
where
there
isn't
a
version.
Constant,
we're
going
to
look
in
the
gem
loaded
specs
anyway
and
github
will
not
use
any
of
those
instrumentations
and
that's
kind
of
where
I
left
it.
C
And
so
this
is
literally
go
back
and
read
through
a
couple
of
hundred
lines
of
gem
files
and
functions
and
be
like.
Is
that
all
right.
D
A
B
Yeah
so
go
ahead
and
take
a
look
at
this.
I
think
eric
and
I
have
already
put
some
green
check
marks
on
it.
It's
looking
good
to
me.
D
Or
approver
I
I
it's
good
news,
which
is
I'm
going
on
paternity
leave
in
like
a
week
and
a
half
or
so
depending
on
when,
when
things
you
know,
decide
to
happen
so
and
I'm
already
pretty
low
in
terms
of
bandwidth
of
being
able
to
keep
up.
So
I'm
not
trying
to
be
selfish
here
and
I'd
like
to
either
replace
me
as
a
contrib
maintainer
or
consider
adding
someone
else,
especially
while
I'm
kind
of
m.I.a
yeah
I'll
try
to
stop
into
these
meetings.
During
the
leave
like
every
now.
D
Just
to
say
hi,
but
yeah
the
chances
like
of
me
being
able
to
contribute
actually
review.
Things
is
like
really
really
low
and
I
don't
want
the
I
don't
want
ariel
stuck
on
an
island.
So
you
know
if
people
could
or
if
people
want
to
just
fill
in
in
the
meantime.
But
this
is
more
just
to
mention
to
know
that
I'll
be
effectively
either
an
emeritus,
maintainer
or
happy
to
be
subbed
out
and
put
out
the
pasture
as
well,
but
yeah.
D
B
Cool
congratulations.
Yeah
thanks.
We
I
think
we
probably
have
some
some
good
options
for
a
maintainer
or
approver
over
there.
I
don't
know,
I
don't
know
how
you
want
to
handle
this
robert.
We
can
either
talk
about
it
here.
We
can
talk
about
it.
Kind
of
out
of
band.
E
I
don't
know
I
feel
comfortable
nominating
sam
yeah.
I.
B
Was
all
right
going
to
say
the
same
thing
so
great?
Let's,
let's
nominate
sam,
and
so
I
can.
E
C
B
Great
so
yeah,
I
guess
after
this
meeting
we
can
do
all
of
the
permissions
things
to
get
that
official.
A
E
E
So
I
think
I
talked
about
this
at
some
point.
There
was
a
push
to
like
get
the
otlp
exporter
to
like
a
1.0,
and
we
kind
of
came
up
with
this.
E
Like
rough
list
of
things
to
do,
I
think
there's
only
two
items
and
it
was
basically
add
an
environment
variable
in
the
configuration
under
the
configurator
to
say,
like
or
sorry
not
add,
the
environment
variable
we're
supporting
the
environment
variable
that
allows
you
to
select
the
otlp
protocol,
the
supported
ones
not
by
us,
but
by
open
telemetry,
are
http
or
protobuf
over
http,
json
or
http.
E
E
So
I
spent
a
little
bit
of
time
just
seeing
like
if
we're
going
to
support
multiple
ones,
and
we
want
to
extract
that
common
functionality.
What
like,
what
is
actually
common
between
these
two
things
right,
so
I
just
went
through
a
little
exercise
of
actually
roughing
out
a
grpc
exporter.
E
E
E
Then
there
will
be
an
otlp
hdp,
which
is
going
to
be
the
same
as
the
otlp
exporter
that
we
know
and
love
with
the
exception
that
the
encoding
is
now
being
pulled
from
this
common
gem,
otherwise
they're
copy
pastes
of
each
other,
including
like
changelog
as
you'll,
see
from
francis's
comments.
So
I
guess.
E
Does
anybody
think
that
this
approach
is
like
kind
of
the
wrong
way
to
go
about
it?
Like
any
concerns
with
this,
I
there's
different
approaches
that
have
been
taken
by
different,
like
implementations
like
if
you
look
at
javascript,
they
have
like
they,
they
have
a
package
for
each
of
them.
As
I
understand
it,
so
there's
like
otlp
trace,
http
otlp,
trace
grpc,
so
they've
actually
splitted.
E
E
They'd
be
separate
classes
like
it
wouldn't
be
one
size
fits
all,
but
you
for
all
your
otlp
http
protobuf
exporting
needs
you'd
grab
this
one
jam
and
then
you
would
set
up
the
one
you
need
because,
like
ideally
that
they're
they
would
share
the
same
dependencies,
but
the
rest
would
be
like
plain
ruby
right
like
if
one
of
them
needed
some
other
obscure
junkie
library
that
was
kind
of
a
toiley
thing
to
bring
on.
Obviously
we
wouldn't
want
to
do
that,
but
I
don't
predict
that
that
will
be
the
case.
C
C
So
the
reusability
might
be
might
be
troublesome
there
because
the
interfaces
are
different.
Then
you
might
do
some
sort
of
like
switch
logic
in
there
to
be
like
if
it's
this
type
do
this.
If
it's
that
type
do
that
and
then
you
then
you're
injecting,
but
then
the
same
thing
might
happen
with
the
encoders
and
then
you
and
then,
if
I
don't
know
so,
the
role
of
the
encoder
is
to
take
like
ruby
objects
and
map
them
to
proto
objects.
C
Correct,
that's
right,
and
so,
if
we
wanted
to
implement
the
json
format
for
exporting,
then
the
encoder
still
does
the
proto
mapping,
but
we
call
2json
basically
on
the
proto
objects
and
then
the
exporters.
C
So
I
feel
like
there's
like
a
lot
of
moving
parts
there
and
if
they,
where
they
lack
symmetry,
I'd
like
replace
conditional
logic
with
polymorphism
in
those
cases.
So
I
think
that's
where
I
would
lean
towards
more
fine
grain
components.
D
C
E
Yeah
yeah,
that's
where
I'm
like,
I'm
trying
to
think
ahead
a
little
bit
of
the
metric
stuff
as
well
to
see
where
it
fits
in
all
of
this,
but
yeah
that's
one
of
the
things
I
just
want.
I
don't
want
to
like,
because
even
the
transition
here
is
going
to
be,
it
won't
be
like
messy
per
se,
but
it's
like
it's
going
to
require
like
some
additional
logic
in
the
configurator.
That's
like.
If
this
new
named
gem
is
there
use
that
one
check
for
the
old
one
that
we're
gonna
be
deprecating.
E
E
I
don't
know
I
I
personally
feel
comfortable
with
the
current
approach.
I've
taken,
obviously
like
I
wouldn't
have
taken
it.
If
I
thought
it
was
going
to
be
messy
or
hard
to
work
with
yeah.
So
like
these,
this
pr
is
open.
If
everybody
anybody
wants
to
like
bike
shot
on
it
like
by
all
means,
I'm
gonna
keep
cleaning
it
up,
but
I
obviously
want
feedback
from
what
everybody
thinks
here,
the
other
pr
I
think
I'd
wanna,
just
like
do
a
quick
point
at
and
call
out
on.
E
I
don't
have
a
lot
of
internal
pressure
from
like
my
day-to-day
job
to
spend
time
like
production,
hardening
a
grpc
exporter
like
what
we
have
were
content
with
at
this
time
and
like
there
isn't
demand
for
grpc.
But
I
like
I,
I
don't
know
if
you
want
to
like
look
at
the
pr.
Maybe
it's
the
the
other
one.
I
had
open
at
the
top
there
right,
yeah
that
one
so
there's
just
like
the
exporter.
Rb
file
is
probably
the
one
to
look
at.
E
So
what
I've
added
here
is
like
the
most
bare
bones:
it
works.
If
there's
a
failure
response,
it
doesn't
check
it,
but,
like
I
have
tested
this,
it
can
emit
to
a
collector
on
the
correct
port.
If
you
provide
it
the
end
point
it
exports
spans
like
it
works,
but
I
would
never
deploy
this
to
production
because
it's
not
looking
looking
for
like
failure,
responses
or
anything
like
that
right.
It
just
assumes
it
works
and
tries,
and
like
just
fires
off
the
next
one,
it
doesn't
have
the
same
metrics.
E
It
doesn't
have
any
of
the
same
thing,
because
I'm
I'm
personally
not
feeling
familiar
with
grpc
beyond
whatever
this
is
right,
so
I
I
don't
know
if
anybody
in
here
knows
of
anybody
that
would
like
to
be
using
this
and
wishes
they
could
use
this
because,
like
I
basically
I'd
like
to
commit
this,
but
not
publish
this
there's
a
little
bit
of
cleanup,
but
I'd
like
to
commit
this
code
to
the
repo
as
like
this,
this
thing
that
someone
could
pick
up
and
continue
like
if
someone
comes
in
asking
for
a
grpc
exporter,
it's
like
behold
like
it's
here
for
you
to
finish,
but
I
don't
know
how
people
feel
about
that.
C
I
love
stone
soup
and
we
can
definitely
like
do
things
like
omit
the
rake
build
so
that
the
gem
isn't
included
in
the
output
essentially
and
isn't
published,
omit
it
from
toys,
but
I'm
a
big
fan
of
stone
soup.
So,
if
we
could,
like
you
know,
I
know
that
that
might
frustrate
some
people
in
the
sense
that
here's
this
incomplete
thing,
but
it's
kind
of
like
we,
you
can
write
all
those
things
in
the
readme
and
be
like.
We
did
this
to
try
to
help.
C
You
know,
inform
our
decisions
about
xyz
and
then
we
could
really.
This
is
something
that
needs
help
and
we
could
use
your
contribute.
The
community
contribution
here.
So
I'm
a
vote
of
a
yes
to
it's.
I
think
it's
okay
to
merge.
It.
E
And
the
same
thing
would
eventually
be
for,
like
http
json,
like
now
that
we
have
two,
it's
like
it's
a
lot
easier
to
like
break
ground
on
a
third
right
for
different
protocols,
and
I
just
I
want
to
make
it
easy
for
people
to
contribute
this
if
they
they're
a
second
demand
for
and
if
it
just
like
kind
of
lingers
and
bit
rots
over
time
like
so
be
it.
Hopefully
that
doesn't
happen,
but
like
it
may
right
so
cool.
E
I
don't
know
like
how
much
more
I
have
to
say
with
it,
without
just
repeating
myself.
Basically,
if
this
is
my
crack
at
breaking
things
apart,
there's
a
very
rough
like
skeleton
of
a
grs
pc
protocol
exporter.
E
E
So
these
files
will
get
probably
renamed
it'll,
be
like
trace
exporter
and
then
eventually,
there
would
be
like
a
metric
exporter,
whether
or
not
they
would
get
included
during
the
early
unstable
life
of
metrics.
Is
like
they
might
start
as
a
separate
gem
and
then
once
they're
like
good,
they
would
get
kind
of
merged
into
this
one,
but
yeah
that's
like
kind
of
the
direction
I'm
going
with
all
of
this
stuff,
and
I
think
it
feels
good.
It
feels
organized.
E
It
feels
like
the
nitty
bits
have
been
like
of
encoding
have
been
ripped
out
encapsulated.
I
need
to
move
some
tests
around,
but
yeah,
and
then
I
also,
I
think,
just
to
like
add
to
my
own
sanity
and
confidence
that
I'm
not
gonna
burn
the
entire
open
elementary
community.
If
they
try
to
adopt
this
we'll,
probably
well,
we
will
switch
over
internally
to
the
new,
like
refactored
version
before
I
kind
of
start
notifying
that
the
old
ones
deprecated
and
people
should
use
this
new
thing.
So.
B
Yeah,
if
and
in
terms
of
merging
this,
as
kind
of
a
a
functional
work
in
progress,
I
think
thumbs
up
there.
We
should
just
get
like
an
issue
in
in
the
repo
for
help
wanted
to
kind
of
finish
this
thing
off
and
just
kind
of
describe
where
it
is,
and
maybe
maybe
somebody
who
does
want
it
will
come
along
and
and
harden
it
for
us.
B
E
Something
I
think
I
saw
like
related
to
that
thought
demonstrated.
I
think
it
was
one
of
the
kind
folks
from
aspecto
were
showing
something
the
javascript
repo
that
they
like
assign
code
owners
to
specific
packages.
Is
that.
C
I
still
don't
know
why
I
haven't
looked
into
why,
because
code
order
nurse
is
like
here's
some
file
pattern,
and
here
are
the
teams
you
notify.
I
think
it's
because
you
have
to
like
give
you
have
to
give
these
people
specific
security
capability
in
the
repo
you
add
them,
as
contributors
as
either
read
or
write
or
whatever
to
the
repo,
and
I
think
we
can
manage
that,
and
I
think
we
could
get
away
with
code
owners
without
having
to
dig
into
component
owners
and
add
something
else
for
us
to
maintain.
Personally
speaking,.
E
Like
that,
the
motivation
for
this
question
was
just
thinking
of
like
the
contrib
repo
it's
like,
and
even
just
like
this
stuff
of,
like
someone
started
contributing
to
the
the
grpc
one,
and
it
wasn't.
Many
of
us
it'd
be
nice
if
we
could
like
flag
them
when
a
pr
gets
opened
against
it
and
or
same
for
like
contrib.
E
I
think
it's
like
distributing
that
that
bit
of
ownership
a
little
bit
like
I
don't
know
it's
something
that
I
think
would
be
interesting
to
see
as
contrib
gets
set
up
same
with,
like
the
aspecto
folks
and
like
aws
right
like
we
were
talking
about
that
earlier
and
like
dropping
potentially
end
of
life
versions,
it's
like
well.
If
they
want
to
keep
it
around
a
dad
it's
like
well,
then
it
would
make
sense
that
we
could
put
them
at
an
office.
C
Yeah
and
that's
what
code
owners
will
do
so
code
owners
will,
whoever
you've
listed
in
the
code
owners
for
that
subdirectory
will
assign
them
as
reviewers,
but
those
reviewers
have
to
have
access
to
the
repo
and
we
can
give
those
reviewers
access
to
the
reply's
read-only
permissions,
so
they
wouldn't
be
able
to
commit
directly
against
the
repo
they'd
have
to
open
pull
requests
until
they
were
upgraded
to
be
maintainers,
and
then
at
that
point
they
can
get
a
right
role
or
an.
If
we
got
them
approvers
role,
maybe
they
could
write.
C
You
know
we
can
kind
of
define
all
those
all
those
things.
If
that's
okay.
E
B
Some
sums
up
there,
I
think
you
know
the
collector
contrib
repo
works
this
way
as
well.
So
it's
it's
always
nice,
especially
if
we
start
getting
more
and
more
donations
from
people,
and
we
just
want
to
like
kind
of
trust
that
they're
going
to
be
responsible
for,
for
you
know,
maintaining
stuff
going
forward.
It's
nice
to
have
somebody's
name
attached
to
it,
and
hopefully
you
know
they
will
be
responsive.
B
A
I
had
a
quick
one.
I
wasn't
well,
maybe
not
quick,
but
it'll
have
to
be.
I
noticed
in
the
redis
instrumentation,
our
appraisals
are
out
we're
out
of
date,
which
is
totally
fine.
I
made
pr
and
updated
them.
I
was
curious
if
folks
had
strategies
used
strategies
to
keep
appraisals
up
to
date
in
ruby,
gems
elsewhere
or
if
we
thought
about
this
and
made
a
choice
that
I
don't
know
about.
C
E
C
Yes-
and
I
think
that
what
we
ca
we
would
be
able
to
do
is
maybe
write
an
action
that
would
periodically
maybe
like
every
month
or
something
run
through
and
regenerate
the
appraisals
or
reinstall
the
appraisals
and
anything.
That's
changed
open
up
a
pr
to
merge
them
in.
A
Cool,
I,
that
makes
a
lot
of
sense
to
me.
Do
you
the
action
could
also
like
go
and
look
for
new
releases
of
whatever
jam
it's
dependent
on
or
no.
A
B
Yeah
this
this
would
be
awesome
to
automate
and
as
we
as
we
get
contribute
set
up.
I
think
these
are
all
great
ideas.
C
B
A
C
B
No,
like
my
it's
no
cheaper
than
portland
at
least
wild.
So
that's
how
it
goes.