►
From YouTube: 2022-06-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
C
A
All
right
there
will
be
the
monthly
spec
release
movie
this
week.
A
There
was
a
long
conversation
about
otlp
1.0
and
when
and
just
generally
kind
of
discussing
how.
A
There
have
been
changes
that
have
been.
I
don't
know
like
on
the
json
side.
There's
definitely
been
changes
that
have
been
backwards
incompatible.
I
think
there
have
been,
I
think,
the
instrumentation
library
that
instrumentation
scope
change
was
questionably
backwards,
compatible
for
proto
users
and
just
generally,
some
frustration
inventing,
I
think
around
like.
When
is
this
thing
actually
stable,
and
what
is
it
going
to
take
for
there
to
be.
A
No
more
changes
that
are
going
to
cause
pain
and
I
think
that
was
kind
of
up
to
debate.
What
that
actually
meant.
But.
C
A
Yes,
on
the
vendor
side,
I
think
we
would
love
love
for
that
as
well.
I
think
it's
like
this
pr
here,
I
guess,
is
maybe
one
of
the
last
levels
of
pain
people
are
expecting
to
inflict
and
it
was
a
bunch
of
renamed
enums.
A
Tristan
had
quite
a
few
questions.
One
was
on
behalf
of
a
datadog
user,
but
basically
was
it
it's
a
database.
Instrumentation
was
encountering
an
an
error,
but
it
was
not
being
flagged
as
such
by
the
data
dog
ui.
A
I
think
the
pain
that
this
person
going
is
going
through
is
somewhat
universal
between
different
back
ends,
and
I
feel,
like
the
I
feel,
like
exception
handling,
was
like
a
a
challenging
thing
to
reach
agreement
on
and
it's
hard
to
know.
I
think
what
what
actually
constitutes
an
error
now
in
in
hotel.
It's
like.
Is
it
just
an
error
event
on
the
span?
A
Is
it
a
combination
of
error
event
on
the
span,
plus
the
span
status?
I
think
the
second.
The
second
one
is,
is
what
it
is.
I
think
there
is
a
status
component
and
likely
looking
for
an
event
on
on
this
fan
as
well.
A
I
know
we
have.
I
think
we
have
a
recorded
exception
method
in
ruby
and
I
forget,
if
it
actually
kind
of,
does
both
of
those
for
you
or
not.
I
think
at
one
point
in
time
it
tried
it
tried
to
do
the
right
thing
so
that
you
didn't
have
to.
A
Be
aware
of
all
these
fine
details
but,
like
I
said
that
was
all
in
the
past
and
it
was
kind
of
somewhat
complicated
and
where
things
stand
today,
I
guess
is
anybody's.
Guess.
C
A
C
B
All
right
isn't
that
at
the
risk
of
extending
the
debate
about
what
even
is
an
error,
the
it
has
been
useful
to
have
a
span
have
multiple
span
events,
if
you're
doing
retries
and
those
retries
might
fail,
but
the
span
doesn't
fail
unless,
like
your
recovery
is
never
like,
if
the,
if
ever,
there's
an
unhandled
exception
by
the
time
you're
ending
the
span
is
when
you
maybe
set
the
span
status
to
error,
but
I
don't
I
I
I
too
do
not
remember
the
nuances
of
our
handling
and
whether
we
do
that
well,.
C
I
think
you
certainly
could
use
our
stuff
to
do
it
that
way.
Yeah
yeah,
like
an.
B
That's
what
I
mean,
I
don't
know
how
automatic
we
could
even
make
that,
but
as
a
convention
that
would
be
good.
A
I
think
that
makes
sense,
and
I
think
it
it
illustrates
why
there
is
at
least
some
some
relationship
between
the
span
status
and
the
events
in
the
span
and
why
that
does
a
little
more
get
a
little
bit
more
complicated
in
that
you
could
have
a
series
of
of
errors
that
end
up,
ultimately
successful
all
in
the
same
span,
and
that
would
be
a
successful
span
in
the
end.
A
A
A
The
next
one
was
talking
about
having
a
before
end
callback
for
processors,
and
I
think
this
is
to
work
around
with
the
fact
that
on
span
end,
it's
like
you
end
up
with
a
span
data
which
is
an
immune
immutable
and
changing
this
process
of
pipeline
is
a
challenge,
but,
depending
on
who
you
talk
to,
I
think
people
see
that
as
like
a
feature
and
not
a
bug,
and
so
I
think
this
before
end
is.
A
I
guess
this
is
a
discussion
that
has
been
here
for
a
while
would
be
a
way
to
work
around
that
and
be
able
to
get
access
to
like
a
right
only
span
right
at
the
end,
and
I
think
in
general
this
is
somewhat
unpopular.
I
know
they
were.
The
suggestion
was,
if
you
need
to
mutate
a
span,
why
not
just
wrap
your
exporter
and
do
it
in
the
exporter,
but
it
just
seems
like
that's.
Maybe
not
the
right
place
to
do
that.
C
B
Yeah,
I'm
in
the
camp
of
grumpy
that
it's
immutable
on
end.
I
understand
it's
dicey,
but
it
is,
after
a
span
has
collected
a
whole
bunch
of
state
that
I
might
want
to
make
a
decision
about
adding
further
state
or
mutating
it.
A
A
B
I
I
will
say
sorry
not
sorry.
This
is
coming
from
a
honeycomb
feature
in
our
instrumentation
that
that
the
person
who
opened
this
issue
is
trying
to
enable
an
hotel,
which
is
the
ability
to
to
declare
something
that
you
want
when
this
is
the
baggage
case,
the
baggage
and
carry-on
shenanigans.
It's
it's
that,
but
done
with
a
processor.
E
I
I
I
think,
if
I'm,
if
I'm
reading
tristan's
comment
here
correctly,
is
you
can
have
a
your
own
processor
that,
when
it
receives
the
span
on
on
end,
it'll
create
a
new
instance
of
a
writable
span
and
copy
all
the
attributes
over
do
all
its
mutations
and
finish
it
and
then
pass
that
on
to
a
processor
pipeline.
B
Yeah
we
we'd
have
to
re-implement
our
pro
in
in
the
hotel,
ruby
case.
I
don't,
I
don't
think
our
processors
act
like
a
pipeline
like
the
thing
that
processor
a
and
processor
b
a
doesn't.
E
If
you,
because
it's
because
when
it
calls
the
doesn't
it
doesn't,
this
fan
itself
call
the
processor.
B
You
know
when
I
got
to
go
revisit
the
code.
I
my
mental
model
for
how
our
processors
are
implemented
or
more
like
middleware,
where
each
processor's
onstart
gets
started.
E
E
And
then
you
had
the
exporter
so
that
you
had
a
a
sub
processor
so
to
speak
and
that
received
the
on
end
or
the
the
closed
call.
It
can
copy
the
span
and
pass
that
on
to
the
batch
fan
processor
to
close
it
up,
but
thinking
about
it
conceptually
but
thinking
about
it
also
was
like.
Does
the
span
cue
that
the
batch
bin
processor
have
in
it?
E
E
A
E
No,
that's!
That's
what
I'm!
That's
all
I'm
saying.
So
what
that,
what
the
end
result
of
that
is.
Is
you
end
up
with
duplicate
object,
n,
a
a
an
additional
object
instance
for
each
span,
not
events.
The
events
you
can
probably
just
copy
over
but
you'll
get
a
duplicate
object,
instance
of
a
span
every
time
you
do
this
and
the
attribute
copying
you
end
up,
probably
generating
a
new
hash
and
a
new
set
of
attributes
enumerators
every
time.
E
E
E
A
A
Yes,
yep
and
yeah,
like
I
will
at
least
say
this
man.
I
shouldn't
say
this,
but
I
will
say
this
that
there
was
at
least
like
a
conscious
decision
to
have
a
distinction
between
the
api
and
sdk,
specifically
so
that
you
could
have
alternative
sdk
implementations.
It's
like
a
huge.
Ideally,
your
kind
of
reference
implementation
would
have
all
the
things
that
you
would
want
and
but.
A
But
you
could
make
like
a
tito's
open,
telemetry
ruby
yesterday,
for
example,
that
did
have
this
pipeline
concept
that
matched
the
collector
and
people
could
use
it.
It
would
work
with
all
of
the
you
know,
instrumentation
from
from
hotel
ruby.
It
would
just
have
some
extra
special
sauce.
E
A
But
yeah
that
that
is
an
option
and
maybe
someday
hotel
will
either
change
or
fix
this
or
alternative
implementations
could
crop
up.
I
guess
in
ruby
it
could
just
be
like
a
a
monkey
batch
on
the
default
sdk
in
the
end,
so
you
don't
have
to
rewrite
everything.
B
B
As
soon
as
possible
man,
when
the
contrib
settles
down
with
the
stuff
that
we
want
to
migrate
to
it,
I'll
be.
B
E
E
Could
do
it
again?
I
I
I
think
that
that's
come
up
before
and
I
think
tigran
there's
been
like
a
lot
of
like
discussion
about
that
with
t
grin
and
the
collector
team
that,
like
they
don't
want
the
sdk
to
behave
like
a
collector
and
I'm
still,
I
haven't
looked
into
those
conversations.
It's
a
justification
for
that.
A
Kind
of
drawing
out
the
the
spec
signal
recap,
but
I
feel
like
that
was
useful
discussion
and
I
think
yeah
we're
getting
pretty
close
to
the
end
here.
Just
was
saying:
instrumentation
scope
loses
information
when
not
used
as
instrumentation
library.
A
I
think
he
was
kind
of
saying
when
users
create
their
own
scope,
if
they
don't
add
in
kind
of
the
same
instrumentation
library,
instrumentation
version
attributes
well
adding
in
additional
ones,
you
kind
of
end
up
losing
those
along
the
way.
I
think
I
think
that
was
what
the
discussion
was
and
I
think
the
response
was
that
somewhat
intended
and
easily
fixed
by
by
the
user.
If
that
is
a
problem
for
them,.
A
A
B
I
don't
totally
know
what
the
outcome
of
this
was.
What
would
what
would
be
neat
is
an
instrumented
proxy
that
tells
you
in
the
trace
that
hey
I
was
in
here.
The
client
was
requested
to
talk
to
the
actual
endpoint
and
in
your
trace
you
get.
I
went
through
a
proxy,
but
wherever
yeah,
but
then
we're
gonna
have
to
then
we
have
to
have
instrument
proxies,
which.
B
Maybe
aren't
in
high
use.
A
Yeah,
I
think
I
think
the
goal
is
if
open
telemetry
is
successful,
that
that
proxies
will
start
to
bake
it
in
and
and
generates
fans,
and
you
just
point
them
wherever
and
they
would
you
open
your
traces?
I
know
it
seems
like
open
up
toxies
already
emit
metrics.
B
Open
telemetry,
cpp
c
plus
there's
a
module
for
nginx
and
I
think
apache
yeah
there
you
go
the
the
service
meshi
things
like
sdo
are
emit
jaeger.
So
if
you've
got
a
collector,
that'll
translate
jaeger
to
hotel
you
can
you
can
get
spans
for
the
traffic
flowing
through
them.
I
think
aha.
C
Proxy
does
open
tracing
actually.
A
All
right
sam
is
here
to
shut
us
down,
since
the
spec
sync
has
definitely
gone
over
over
10
minutes.
Tito's
is
getting
their
money's
worth
yeah.
Let's
hurry
up.
I
think
I
think
that
was
actually
it.
This
last
issue
did
not
get
we
did
not
get
to
because
there
were
so
many
other
discussions
on
things,
but.
A
Yeah
there,
I
guess
they
see
some
clarification
on
on
the
spec
about.
A
Tracing
and
metrics,
I
think,
to
not
be
able
to
use
a
map
as
a
value
in
for
for
attribute
types,
no
map
value
attributes,
but
everything
else
is
fair
game,
but
I
think
in
logging
that
is
not
the
case,
but
we
did
not
actually
get
to
this
issue,
and
I
did
not
read
read
this
so
if
you're
interested,
maybe
look
into
that.
But
yes,
since
we've
been
busted
by
sam,
we
can
wrap
up
the
spike
sig
recap
and
move
on
to
the
geez
sam
party
pooper.
D
A
Yeah
we
definitely
talked
about
code
aria
was
giving
us
the
tito's
private
island
recap.
So
we're
not
supposed
to
talk
about
the
private
island.
That's
the
first
rule
about
tito's
private
island
yeah.
This
is
recorded.
B
C
On
the
agenda,
yes,
yes,
I
did
in
fact,
if
you'd
like
to
click
into
that
issue,
the
open
telemetry
project
now
has
an
official
demo
web
store
and
in
the
time
between
I
added
it
to
the
meeting
notes,
and
today
I
went
ahead
and
just
did
it
so
now
there
is
a
pr
that
has
merged
a
little
bit
further
down
that
we
can
also
click
on.
C
There
was
really
not
much
to
talk
about
other
than
to
say
I
did
it
and
we
should
feel
free
to
add
or
change
or
modify
this
service
to
show
off
open
telemetry
as
best
we
can.
There
is
a
particularly
nice
comment
in
there
about
grpc
and
protobuf.
If
you'd
like
to
read
shade
from
me,
I
love
that
essay
that
you
wrote
there.
C
I
had
to
stop
writing
it
after
a
while,
because
I
just
got
angry
there's
a
kind
of
stuff
but
yeah
there.
There
was
initially
discussion
about
like
first
in
the
in
the
slack
there
was
discussion.
Well,
why
not?
Why
are
we
replacing
a
service
and
I'm
like?
Well,
that's
because
what
me
and
some
of
the
other
maintainers
talked
about
actually
and
then
there
was
like
ygr.
Why
not
grpc,
and
I
was
like
well
technically,
we
can
make
it
work
like.
C
I
am
aware
of
how
to
do
it,
but
like
I
would
vastly
prefer
not
to
for
all
of
the
reasons
I
listed
out
there.
Fundamentally,
though,
at
the
end
of
the
day,
all
of
those
issues
aside
http
is
where
ruby
shines
like
we
have
so
much
built
around
that
ecosystem.
That
is
just
not
a
good
demo.
Unless
we
yeah.
B
E
E
A
E
C
Yeah,
but
that
it
yeah,
I
have
lots
of
feelings
about
that,
none
of
which
I
want
on
youtube,
but
it
it's.
I
agree
that,
like
diversity
and
sort
of
like
what
we
show
off
in
this
demo
is
kind
of
important,
I
I
had
to
actually
restrain
myself
from
making
the
full-blown
rails
app
because
we
really
shine
with
rails,
like
we
have
some
really
nice
things,
but
I
just
I
thought
you
know-
maybe
maybe
that
wouldn't
get
merged,
especially
because
it's
like
a
seven-line
sinatra
app,
so
it
felt
like
I
did.
I
did.
B
C
Yeah
but
anyways,
that
was
that
was
that
I
wanted
to
let
people
know
it's
happening,
we'll
probably
get
pinged
every
now
and
again
I
promised
them
that
as
we
implement
logging
and
metrics
over
time,
we'll
come
back
and
we
will
enhance
this
to
show
that
off
as
well.
D
C
C
D
A
A
C
Has
anyone
tried
to
spin
spin
up
the
full
example
yeah
it
works?
I
mean
it
takes
a
few
minutes
to
build
all
the
images
so
like
I
don't
know
if
you
could
do
it
live,
but
it
really
depends
on
how
fast
your
internet
is.
What
kind
of
computer
you're
working
on?
I
guess
but
yeah
the
whole
thing
works
and
then
it's
completely
functional.
As
far
as
I
know,
like
I
clicked
around
it
did
things
I
had
traces.
I
think
it
works.
C
C
E
Yeah
so
there's
a
problem
is
that,
like
I
freaking
this
release,
process
is
gives
me
a
headache
all
the
time
and
the
thing
is
like
it
did
like
a
minor
bump
for
all
these
gems
and
I'm
sorry,
bug,
bug
fix
bump,
and
these
should
have
all
been
minor
bumps.
But
that's
what's.
Holding
us
up
is
like
my
my
thing
about
having
to
reopen
this
one
more
time
where
all
these
jumps
gems
get
a
minor
bump.
E
But
really
I
wanted
to
kind
of
like
run
a
couple
ideas,
past
y'all,
which
is
essentially
going
getting
instrumentation
back
to
a
single
version
number
across
all
the
instrumentations
keeping
them
lockstep,
because
these
individual,
like
the
individual
release
management
for
all
these
gems,
is
a
little
bit
of
a
headache
and
in
particular
for
like
trying
to
release
all
those
and
then
the
the
all-in-one
or
the
all-gym.
E
Getting
that
release
and
some
food
for
thought,
which
is
us
considering
releasing
the
all
gem
with
all
of
the
source
code
embedded
in
it,
as
opposed
to
it,
doing
the
spread
out
dependencies
and
having
to
constantly
do
like
minor
version
bumps
of
its
dependency
tree.
E
So,
if
you
think
about
like
how
other
programming
languages
might
do
this
like
in
java,
you
know
you
can
have
a
maven
all-in-one
gem,
sorry,
a
jar
that
you
package,
all
your
dependencies
inside
of
and
you're
only
releasing
that
one
version
or
you
could
have
your
little
piecemeal
once
only
because
I'm
finding
it
to
be
onerous
to
have
all
of
these
artifacts
constantly
getting
managed
for
what
we're
trying
to
do
and
so
like.
E
E
And
you
know
at
least
at
least,
let's
keep
that
going
until
we
get
to
a
1.0
version
of
instrumentation
and
then
we
can
start
making
decisions
about
release
management
for
individual
gems
going
forward.
I
don't
know
how
people
feel
about
it,
but
I
kind
of
wanted
to
get
some
go
ahead.
There.
E
Okay,
so
you
want
to
release
a
gem,
you
might
make
a
bug
fix
right.
So
now
we
have
these
gems
in
all
these
different
versions-
and
I
say
I
and
I
want
to
release
some
of
these
gems
right
so
every
time
I
do
our
tooling
tells
us
hey.
Look.
You
want
to
release
n
number
of
jumps,
so
all
those
gems
are
going
to
get
released,
they
all
get
bumped
out
and
they're
either
minor
version,
or
they
are
a
bug
fixed
version
and
they
either.
E
You
know,
depending
on
what
the
conventional
commits
figures
out.
It's
gonna
say
this
specific
gem
is
gonna,
get
a
minor
version
and
the
rest
of
your
stuff's
gonna
get
a
bug
fix
release
when
you
get
them
out.
So
if
somebody
did
not
properly
use
conventional
commits,
it's
like
you
might
get
the
wrong
version
number
bump
when
you're
trying
to
release
something-
and
in
our
case
right
like
the
bass.
E
Gem
is
the
one
that
got
the
minor
bump
and
it
didn't
cascade
that
commit
down
to
the
rest
of
the
gems
that
need
to
get
released
now
right.
C
E
And
then
you
got
the
situation
where
it's
like.
Now
you
have
the
all-gym
and
the
all-gym
has
all
like
many
different
versions,
because
they've
all
diverged
in
their
version
numbers
and
now
I
gotta-
go
and
bump
the
all
gem,
but
I
totally
forgot
you
know
which
gems
I
need
to
bump
inside
of
the
all
in
order
to
get
all
to
be
up
to
date.
C
So
I
mean
I
know
we
didn't
want
to
have
everything
operating
in
lockstep
before
at
least
before,
meaning,
I
think,
maybe
more
than
a
year
ago,
at
this
point
just
because
we
didn't
think
all
instrumentations
would
move
at
the
same
rate.
But
I
can
see
why
you
would
want
to
because
that
would
make
it
a
lot
simpler.
E
Dude
until
we
get
to
version
1.0,
I
kind
of
feel
like
I
want
to
kick
this
cane
down
the
road
if
we
ever
get
to
1.0
with
what
these
instrumentations
are
supposed
to
do,
yeah
and
then
and
again,
it's
kind
of
like
you
know
and
that's
an
orthogonal
problem
to
saying
like
I
want
to
release
all
the
gems,
the
latest
version
of
all
the
code
at
some
point
and
make
it
available
through
the
all
gym
and
it's
like
for
people
who
are
trying
to
manage
dependencies
upstream.
C
I
don't
feel
too
strongly
either
way
about
embedding
it
or
not.
I
think
my
perspective
on
it
is
just
that,
like
our
release,
tooling,
is
annoying
and
makes
it
hard
to
deal
with
our
problems,
and
maybe
we
should
do
something
different
about
that
entirely
that
like,
but,
but
I
guess
with
regards
to
bundling
them
all
together.
I
I
don't
know
that
doesn't
really
bother
me.
It
could
work.
I
think
it
would
just
be
like.
C
I
think
honestly.
I
think
it
would
be
a
nightmare
to
try
and
make
it
work
with
the
current
release
system.
Like
I
don't
know
how
well
that's
gonna
work
like
that
it,
I
don't
know
if
we
can
get
out
of
that,
like
our
release
system
doesn't
work
very
well
problem,
like
I
think,
we'll
just
run
into
that
still.
C
A
Is
right
so
just
to
re-recap,
so
ultimately,
all
ends
up
being
a
huge
problem
when
you
get
a
number
of
instrumentation
version
bumps,
because
it's
hard
to
know
what
to
put
into
all
as
as
the
actual
versions
so
like,
if
you
just
copy
the
source
code
in
it,
it
would
solve
that
problem.
A
Is
this
really
or,
alternatively,
if
we
could
just
generate
a
different
gem
spec
for
all?
Would
that
also
be
as
good.
E
Yeah,
I
think
the
the
side
effect
is
like
hey.
I
tell
somebody
to
use
the
all
gem
they
do
all
and
then
they
get
like
23.
You
know,
gems
that
get
imported
and
they're
like
wait
a
minute.
What
all
these
gems
right-
and
it's
kind
of
like
that,
that's
that's!
That's,
raising,
alarms
that
don't
need
to
be
there.
E
E
I
know
you
know
we,
don't
we
don't
introduce
security,
no,
not
at
all.
C
A
C
C
C
B
I
I
also
did
a
bad
job
of
summarizing
the
one
two
three
options
in
in
the
agenda.
Somebody
wants
to.
E
Oh,
I
think
that's
all
good,
we'll
revisit
this
conversation.
Okay,.
C
Here's
a
question
for
you:
what
if
we
had
what
if
we
changed
our
tooling
or
something
to
what,
if
we
just
like,
specified
the
version
numbers
of
each
gem,
that
we
want
them
to
be
in
a
yaml
file
or
something
whenever
we
made
changes,
we
just
went
in
and
we
like,
updated
that
and
said.
Okay,
we
want
to
bump
these
versions.
C
This
dependency
like
what,
if
we
like,
centrally
manage
the
dependencies
somehow
in
versions
in
one
file
and
then
as
part
of
the
release
process,
you
went,
and
you
said,
okay,
these
numbers
need
to
change,
and
that
means
this
other
dependency,
because
it's
in
this
file,
I
know
it's
gonna-
have
to
be
this
version.
I
don't
know
if
that's
any
better
or
not,
but
like
it's.
C
E
E
C
I
guess
the
downside
of
putting
them
all
at
the
same
version
number
is
that
people
who
are
pinning,
or
only
installing
certain
instrumentation
they're,
going
to
get
updates
for
things
that
just
aren't
actually
updated
they're
just
going
to
get
a
lot
of
like
oh
version,
is
updated
again.
What
are
the
changes?
Oh
there
aren't
actually
any
changes
to
this.
It's
just
a
unified
bump,
but
I
mean
if
it
makes
our
lives
a
lot
easier.
A
I
feel
like
that's
why
we
stepped
away
from
the
unified
bomb.
I
feel
I
think
we
did
have
unified
versions
at
one
point
in
time.
Bush
robert
was
here
to
confirm
or
deny
this,
but.
C
That's
cool,
I
think
our
releasing
process
is
painful
right
now
and
has
been
so
for
a
bit
and
is
worth
the
discussion
in
the
sake
like
that's
what
we
should
be
talking
about.
Maybe
we
just
need
to
lean
on
robert
to
come
next
time
and
give
us
more
history.
A
Yeah,
I
think
it
does
seem
like
we're
really
seeing
these
pain
points,
so
I
don't
know
if
it
makes
sense
to
get
like
a
discussion
going
on
on
github,
where
we
can
actually
like
yeah
asynchronously
talk
through
some
of
these
and
kind
of
come
up
with,
maybe
some
some
some
actual
tangible
tasks
that
we
can
go
through
and
and
fix
this
because
I
feel,
like
I
don't
know
it
seems
like
we
can
automate
our
way
out
of
this
one
way
or
another.
C
E
C
D
C
C
Yeah,
although
fewer
of
them
than
j
ruby,
the
j
ruby
issue
actually
has
a
lot
more
gems
in
it,
truffle
ruby.
There
was
only
a
handful,
I
was
actually
pleasantly
surprised.
They
seemed
to
have
the
c
extension
story
fixed
somehow,
and
I
I
think
this
is
probably
because
I
don't
entirely
understand
what
truffle
ruby
does.
I
thought
it
was
a
jvm
thing,
but
apparently
there's
like
a
native
thing,
so
I
guess
it's
better
for
c
extensions,
it's
unclear
to
me,
but
it
ran
in
ci
and
it
was
fairly
happy.
So.