►
From YouTube: 2023-02-14 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
Moving
at
a
turtle's
pace,
you
know
what
I'm
saying
but
doing
what
I
can,
how
you
doing.
A
B
C
We
I
I
have
not
noticed
that
yet
we're
not
doing
any
traces
from
browsers
right
now,
so
I,
don't
I.
Don't
have
not
seen
that
personally
myself,
yet.
B
A
Don't
we
kick
this
off
there
yeah,
let's.
B
You
took
the
words
out
of
my
mouth,
all
right,
picking
it
off
specific
recap:
Valentine's
Tito's,
Valentine's,
Day,
Edition,.
B
So
the
HTTP
semantic
convention
civility
group
has
been
using
part
of
this
vaccine,
meaning
to
go
over
some
of
the
changes
they're
proposing
hello,
doggo.
Yes,.
B
And
the
most
contentious
one
probably
change
thus
far-
is
changing
the
semantic
conventions
to
for
HTTP
duration
for
metrics
two
seconds
from
milliseconds.
B
I
was
initially
asking
some
questions
about
this.
It
seems
to
be
HTTP
metrics,
so
it
at
first
I
was
a
little
bit
for
now.
A.
C
B
Miffed,
just
because
I
was
thinking
about
users
who
upgrade
and
instantly
their
durations
change
from
milliseconds.
The
seconds
is
going
to
be
it's
going
to
kind
of
invalidate
historical
data
that
you
may
have
there,
and
your
charts
are
going
to
look
weird
moving
from
milliseconds
to
seconds
at
least
you're,
probably
not
going
to
trigger
any
alarms,
but
you're,
probably
going
to
not
get
some
alarms
that
you
wanted,
because
you're
off
bye.
B
C
A
Data
model
is
so
the
fact
that
you
have
a
counter
an
up-down
counter
and
you
have
async
measurement
or
whatever.
All
of
those
things
are
in
place.
But
nothing
is
saying
about
the
values
like
what
the
actual
semantic
values
are
and
now
they're
saying
that
they
wanted
to
be
a
unit
of
seconds
as
a
floating
point,
because
Prometheus
that's
the
recommendation
from
Prometheus.
C
C
Pr,
oh
I
am
I'm
going
to
I
open
it
up
in
a
browser.
I
happen
to
be
running
a
pretty
big
ass,
Hotel
metrics
system
at
the
moment
and
like
this
type
of
thing,
would
be
extremely
annoying,
but
like
also
we're
measuring
stuff
in
milliseconds,
not
seconds
like
there's
I'm,
just
yeah
I,
don't
know
something.
B
A
B
For
anybody
who
is
running
a
current
system
recording
things
in
milliseconds.
A
C
Or
please
do
I
mean
I
like
engagement
like
I,
don't
know:
Delta
publicity
is
bad
publicity,
Maybe
I,
don't
know
if
I
believe
that
yeah
I'll
chime
in
on
that,
because
I
I
I
just
feel
really
strongly
that
we
shouldn't
recreate
like
we
shouldn't
set
standards
just
because
Prometheus
does
it
that
way.
That
is
essentially
what
open
metrics
kind
of
is
was
in
my
understanding
of
it,
and
it's
not
to
say
it's
bad,
but
it's
to
say
that
like
I,
don't
know,
we've
already
tried
that,
but
also
we
limit
ourselves.
B
Yeah
and
I
guess
the
other
thing:
Jack
Berg
actually
brought
something
up
that
wasn't
just
a
a
grump
on
on
the
conversion
and
there's
the
explicit
bounds.
The
explicit
bucket
histogram
and
apparently
the
buckets
were
chosen
so
that
they
map
well
to
HTTP
durations
in
in
milliseconds.
So
that
would
be
another
big
problem.
B
Yeah
and
yeah
I.
Think
I,
don't
know
as
we
go
through
these
HTTP
semantic
conventions
that
there
has
been
some
kind
of
I
don't
know
there
definitely
seems
to
be
some
driving
force
that
is
like
aligned
with
Prometheus
on
things
which
I
feel
like.
We
have
resisted
a
lot
like
in
our
metrics
model
and
everything
all
the
way
along,
so
continuing
to
resist,
isn't
a
bad
idea
and
then
the
other
thing
that
keeps
coming
up
is
like
there's,
some
kind
of
conversions
on
ECS
and
some
areas.
B
I,
don't
know
if
that
is
I,
don't
know
what
to
say
about
it.
I
guess,
but
elastic
common
schema
keeps
coming
up
as
a
reason
for
some
of
the
changes.
Oh
so.
C
Yeah
about
all
this
I
guess
like
aligning
with
the
existing
standard,
isn't
completely
horrible
in
all
cases,
like
you
know,
aligning
with
parts
of
the
ECS
is
useful
and-
and
that's
not
to
say
that,
like
the
way
that
the
way
that
otel,
histograms
and
Prometheus
histograms,
like
the
the
new
native
histograms,
were
kind
of
coordinated
in
their
development.
Like
that's,
okay,
you
know,
there's
there's
I
think
like
some
amount
of
that
is
totally
fine,
you
just
we
don't
want
to
yeah
I,
don't
know
anyways.
B
All
right,
so
this
next
one
is
that
apparently
we
have
adopted
the
adopted
ucum
as
the
units
for
metrics,
which
is
a
standard.
It's
the
unified
code
for
units
of
measure
and
for
bytes
in
UC.
It's
by
and
some
people
want
the
full
word.
B
So
that's
that's
what
this
is
about
this
one
actually
tigrin
was
very
much
against.
He
was
saying
the
decision
to
use
you
see.
New
album
was
made
a
long
time
ago
and
it's
part
of
otlp
declared
stable,
so
he
doesn't
see
how
it
could
be
changed.
B
B
B
C
B
Yeah
there's
some
more.
We
talked
about
this
last
time:
generalizing
HTTP
user
agent
to
user
agent,
dot
star
it
kind
of
aligns
with
ECS
nothing
new
and
nothing
has
happened
there.
B
One
thing
that
is
slightly
new
is
that
Kristen
is
starting
to
talk
about
these
decorators
man
like
I,
have
to
search
for
this.
B
In
the
spec
there
was
some
long.
It
was
like
150
comment
thread
that
came
that
showed
up
in
the
Js
Channel
more
recently,
but
ultimately,
everybody
wants
to
use
the
processor
pipeline
to
be
able
to
kind
of
like
mutate,
some
data
on
spans
and
can
never
do
it,
and
this
keeps
coming
up
and
Tristan
must
have
read
this
fact
of
more
than
anyone
else,
because
he
has
found
this
sentence
where
decorators
are
hinted
at
so.
B
So
he's
interpreting
this,
as
this
should
be
some
mechanism
that
allows
you
to
decorate
a
span
in
the
pipeline.
I,
don't
know
that
anybody
else
actually
has
this
interpretation,
but
he
is
at
least
trying
to
talk
about
it
and
has
opened
a
spec,
PR
ior
to
add
it
to
the
Matrix,
but.
B
But
yeah
I
think
there's
a
maintainer's
meeting
yesterday
and
we
started
talking
about
these
pipelines.
A
lot
and
I
was
at
least
commenting
in
the
chat
that
it's
really
confusing,
that
in
The
Collector
that
processors
do
exactly
this.
They
allow
you
to
mutate
and
transform
data,
and
that
is
their
sole
purpose.
And
when
you
come
to
the
SDK,
you
get
none
of
these
capabilities
and
it
it's
confusing
and.
A
You
well
I
mean
you
can't
you
can't
have
some
of
those
capabilities,
it's
just
only
when
you
have
access
to
a
read
write
span
and
you
can't
chain
processors
together
through
the
results
of
their
like
to
the
results
of
like
their
function
application.
So
it's
like
because
I
think
onstart
you
get
a
read.
Write
span
right
on
finish,
you
get
a
read-only
span.
Is
that
correct?
That's
correct,
so
you
can't
mutate
this
ban
on
finish
and
you
can
and
then
this
on
spam
processor
right.
B
A
So
it's
like
you
can
only
make
changes
to
this
man
you
know
is.
C
A
Yeah
yeah
but
I
mean
and
there's
no
way
for
you
to
do
things
like
change
the
sampling
decision
for
that
particular
span,
because
sampling
decisions
are
immutable
right.
You
can't
do
you
can't
do
any
of
those
things.
You
could
only
do
that
at
export
time
to
some
degree,
because
you
have
access
to
the
export
data,
but
it's
like
the
fact
that
those
two
things
are
asymmetric
has
always
driven
me
bananas
because
oftentimes,
like
you,
don't
know
all
the
attributes.
A
I
say
you
want
to
filter
out
on
a
span
or
whether
or
not
you
want
to
drop
the
span
or
export
it
at
all,
right
like
based
on
on
on
its
state
or
whatever,
until
it's
until
the
until
you've
collected
everything
that
you
needed
to
collect
about
this
man
before
you
finish
it
off.
In
other
words,
you
know
yeah.
B
So
at
least
Java
chimed
in
they're
like
yeah.
You
can't
do
this
in
the
processors,
so
they
have
something
in
exporters.
That's
like
I,
guess
the
the
the
only
place
they
have
found
to
be
able
to
kind
of
mutate
your
spans.
So
it's
almost
kind
of
like
a
span
processor
in
the
exporter
called
something
else,
and
it.
B
B
The
one
sane
comment
that
somebody
at
least
replied
when
we
were
talking
about
this-
was
that
at
least
in
the
sdks,
the
processors
processor
pipelines
are
parallel
and
that's
the
reason
for
immutability
of
spans
in
the
processor
pipeline,
whereas
in
The
Collector,
they're
kind
of
like
a
serial
system
of
processors
and
I
was
just
saying
this.
A
B
So
that
ends
up
being
like
the
reason
and
I
was
just
kind
of
mentioning
that
it
seems
it
seems
wrong
to
be
setting
up
a
parallel
processor
in
your
SDK.
You
should
probably
do
this
in
a
collector,
anyways
and
I.
Would
I
personally
would
give
up
parallel
processing
in
the
SDK
for
mutability
in
the
processor
pipeline,
and
at
least
at
least
the
conversation
was
happening
and
I
think
people
were
acknowledging
that
this
sucks
and
we
need
to
fix
it.
B
Some
somehow,
but
I,
think
nobody
had
great
ideas
that
we're
not
breaking
changes
and
let's
bring
this
back
around.
This
is
where
Tristan
was
talking
about
these
decorators
and
hopefully,
out
of
this
conversation
at
least,
we
will
figure
out
if
there's
something
that
we
can
do
to
improve
processor
pipelines
and
in.
B
And
I
think
we're
at
time.
So
let
me
just
quickly
mention
the
other
issues.
B
And
then
the
other
quite
contentious
issue
actually
is
being
able
to
add
links
after
span
creation,
there's
an
issue
with
a
proposal
for
this:
it's
not
so
much
against
being
able
to
add
links
after
band
creation.
It's
just
that
the
however
things
are
implemented
in
go
like
they.
Don't
have
a
great
way
to
implement
this.
That
would
not
be
a
breaking
change
for
users.
I
think,
there's
an
assumption
that,
like
edited
changes
should
be
fine
for
yeah.
B
Edit
edited
changes
should
be
fine
to
the
API
or
or
SDK,
but
it
turns
out
that
this
only
works
if
you've
designed
your
code
properly
and
that
additive
changes
can
sometimes
be
breaking
and
I
think
that's
the
situation
to
go
is
regularly
finding
themselves
in
so
there's
that
Lastly.
Lastly,
Josh
McDonald
was
talking
about
having
a
way
to
configure
cardinality
limits
for
a
media
provider
doesn't
totally
affect
Ruby
today,
because
you
don't
have
a
functioning
metrics
API
yet
or
at
SDK
ad
we're
not
a
complete
one.
B
But
ultimately,
if
you
get
high
cardinality
attributes,
you
end
up
just
with
a
an
explosion
of
metric
data
produced
because
none
of
it
can
aggregate
you
roll
up
together
and
there's
a
desire
to
have
at
least
like
a
circuit,
breaker
mechanism.
It's
like.
C
B
At
least
detected
that
this
is
happening
and
instead
of
just
continuing
to
record
high
cardinality
metrics,
you
break
in
a
reliable
and
predictable
way
and
report
about
it.
So
has
issue
yeah
he's.
B
He
was
saying
that
he
was
trying
to
write
this
stuff
up,
but
the
only
thing
that
he'd
come
up
with
is
that
there
should
be
a
good
mechanism
to
have
a
circuit
breaker
for
your
language,
that
isn't
that
it
doesn't
introduce
any
additional
overhead
or
very
minimal
overhead,
and
everything
that
he
was
trying
to
propose
was
a
little
bit
too
prescriptive.
B
So
I
think
that
was
it.
He
was
just
mentioning
that
this
issue
exists
and
he
didn't
want
to
prescribe
exact
methods,
but
just
general
ideas
around
how
this
should
be
handled.
C
No,
the
configurable
cardinality
limits,
one
is
I,
think
it's
good!
We
talk
about
it,
it's
it
might
be
hard
to
implement
technically,
but
it's
a
good
thing.
I
wish
I
had
that
capability
across
my
infrastructure.
Right
now.
It's
very
handy.
B
C
Yes,
that's
what
I'm
doing
this
week
I
finished
my
infrastructure
migration,
that
I
was
doing
and
I
told
my
team.
The
rest
of
the
week
is
devoted
to
Hotel
Ruby,
so
I
will
be
working
first
this
afternoon
on
some
of
our
build
failures,
try
to
get
those
fixed
up
and
then
accessport
notifications.
That's
the
next
thing.
So
it's
really
happening
and
if
I
don't
do
it
I
request
that
you
all
yell
at
me.
A
C
A
Yeah
I
think
I
wanted
to
like
get
to
the
point
where
we
had.
What
would
what
what
kinds
of
this
simcoms
that's
upstream
and
then,
if
there's
anything
that
may
or
may
not
be
interesting,
we
would
add
those
two
but
like
I,
just
hoping
that
we
can
at
least
get
the
minimum
second,
but
not
worry
so
much
about
like
rail,
specific
ones.
C
Do
you
think
that
rails
specific
semantic
conventions
would
be
a
good
thing
to
propose?
It
is
a
very
large
and
well
used
framework.
A
Hard
to
say
like
when
I
look
again,
it's
like
when
I
look
at
like
controller
in
action
that
fits
to
code
function
parameters.
It's
like,
please,
don't
lock,
parameters
and
attributes,
so
you
know
semantic
attributes
from
instrumentation
same
for
the
HTTP
headers.
We've
already
got
that
kind
of
covered
by
rack
right.
A
The
format
like
so
like
the
controller
action
and
format
plus
method
might
allow
us
to
build
out
this
band
name.
The
way
that
we
want
right
without
having
to
do
route
parsing
at
all.
A
Right,
because
that's
going
to
give
us
like
the
attempt,
like
a
kind
of
templated
one,
it's
not
going
to
give
us
like
the
route,
the
nice
pretty
route,
one
where
it
has
like
the
user
ID
in
it,
but
I
think
most
people
will
be.
Okay
with
you
know,
get
users
show
as
like
the
as
like
the
the
span.
Name
like
that
would
be
pretty
good.
A
Oh
get
users
show
dot,
XML
or
dot
Json
or
whatever.
That
might
be
good
enough
for
our
users
yeah,
but
then
again
it's
kind
of
like
well,
let's
start
processing
action
controller
and
then
you
have
process
action,
controller
which
I
can't,
which
seems
to
be
like
the
on
end
of
the
request.
A
C
A
There
was
like
the
the
OnStar
and
the
on
end
and
the
on
end
has
like
the
HTTP
status
code.
That's
in
there
right,
so
it's
like.
We
might
only
need
to
register
one
of
them,
but
there
might
be
cases
where
it's
like.
We
see
stuff
that
we
might
want
to
record
as
a
Spam
event
right.
It
might
be
interesting
to
record
a
span
event
for
right,
fragment
or
read,
fragment
or
like
those
might
be
interesting
as
events,
but
not
as
bands
themselves.
Right.
C
C
As
the
current
span
context,
when
they're
like
in
their
controller
actions
or
whatever
so
I
mean
it
may
be
that
if
one
is
the
start
and
one
is
the
end,
then
we
may
need
to
have
some
weird
mechanism
that,
like
Bridges
a
span
between
the
two
events,
which
is
not
something
it
can
do
today,
but
it
could
be
something
we
built
I'm.
A
A
A
This
is
just
an
example
of
kind
of
like
the
kind
of
thinking
I
think
we
need
to
get
into
for
this,
and
what
which
of
these
could
be
useful
as
band
events,
but
not
necessarily
have
to
release
them
now.
You
know.
C
Yeah
it's
a
good
place
for,
like
future
work.
I
definitely
agree
like
it's.
It's
a
good
roadmap
for
now
and
then
like
having
this
mapped
out.
I
think
I
think
what
I
will
do
today.
Other
than
work
on
the
build
failures
is
like
poke
around
with
this
too,
like
it's
a
good
sort
of
idle
thing
to
do,
while
I'm
waiting
for
GitHub
actions
to
tell
me
if
I
was
successful
or
not.
B
Yeah
my
my
recollection
of
of
these
is
that
assets,
action,
action
controller
is,
is
probably
the
most
useful
one
and
I
will.
My
recollection
is
that
this
is
kind
of
like
you
know
it's
an
it's
an
around
event.
It's
not.
B
It's
kind
of
like
it's
yeah:
it
wraps
the
meaty
part
of
the
controller
execution.
That's
even
better,
but
yeah
take
everything.
I
say
with
a
grain
of
salt
and
verify
all
these
I.
Don't
I,
don't
recall,
experimenting
very
much
with
start
processing,
but.
B
To
just
to
you
know,
wire
up
subscribers
for
all
these
events
and
just
log
out
the
starts
and
ends
and
see
how
they
all
actually
kind
of
line
up
or
start
reading
through
the
code
as
well
and
just
see
see
what
each
of
these
things
is.
Signaling.
B
But
yeah
I
think
there's
there's
definitely
a
lot
of
interesting
ways
that
we
can
model
this
between
creating
spans
for
certain
things,
creating
events
or
other
things
during
the
span
and
also
exploring
what
the
current
span
would
be
in
these
different
contacts
as
well,
but
I
think
I
think
with
process
action
action
controller,
your
current
span
will
be
what
you
think
it
is
unless
some
other
span
has
started.
You
know
in
the
in
the
meantime.
B
And
yeah
I
think
we
probably
talked
about
this
before,
but
there
are
multiple
ways
that
you
can
set
up
subscribers,
but
I
think
the
one
where
you
can
actually
register
a
start
and
then
event
is
the
one
that
we
want.
Yeah.
C
And
that's
what
we
already
used
for
like
we
already
have
actually
support
for
almost
everything
we
need
to
to
do
this
writ
large
and
as
long
as
what
you
said
is
true.
That
process
action
action
controller
is
a
it's.
An
around
notification,
then
actually
very,
very
few
modifications
that
need
to
be
made
at
all
it's
what
we
use
for
the
the
action
view
instrumentation.
It's
all
done
with
notifications,
so
we
we
have
that
all
built
out.
C
Actually
one
question
about
that
that
Ariel
might
have
an
opinion
on
right
now.
The
back
of
the
support
notification
subscriber,
but
we
would
be
reusing-
is
in
the
active
support,
instrumentation
gem,
but
there
are
active
support.
Caching,
notifications
that
we
might
want
to
legitimately
instrument,
because
those
are
those
could
be
very,
very
interesting
for
people.
C
Do
you
think
we
should
move
the
span
subscriber
into
like
a
helper
Library
out
of
active
support
entirely
as
part
of
this?
So
that
way
we
can
have
active
support,
instrumentation
and
not
like
I'm
worried
about
like.
If
we
put
everything
on
notifications,
then
all
of
them
are
going
to
depend
on
active
support
and
then
one
day,
if
we
add
caching
notification
support
to
like
the
active
support
gem
proper,
then
suddenly
everyone
gets
those
spans
and
can't
turn
them
off
without
turning
off
all
of
their
rails.
C
A
C
That
is
a
generalization
of
the
problem,
I
think
and
it's
accurate
actually.
But
in
this
specific
case
like
we
have
named
a
supporting
gem
that
doesn't
directly
instrument
anything
itself
with
the
same
name
as
something
that
we
might
want
to
instrument
soon.
I
think
is
specifically
the
the
thing
so.
A
Yeah,
should
we
untangle
that
or
probably
I
don't
know
the.
A
C
I
will
write
it
up
in
an
issue
a
little
more
formally
and
lay
it
out
to
to
be
a
little
bit
more
clear
about
it.
Cc
and
we
can.
Maybe
we
can
bike
chat
about
it.
A
little
bit.
I,
don't
know
the
answer
either
like
it's
sort
of
all
answers
feel
gross.
A
B
A
B
B
A
I'm,
not
as
an
outro
user,
so
I
didn't
do
due
diligence
on
these
vrs,
but
we
had
several
like
back-to-back
PRS
from
fastly
and
CJ
bands.
I
think
is
a
person's
name
Robert
Doherty
there.
So
thanks
to
them,
they
were
working
through
some
issues
where
you
know
sometimes
a
natural
double
report-
exceptions.
Sometimes
it
wouldn't
sometimes
it
would
not
set
the
spam
status
right
or
over.
C
A
It
or
whatever,
and
so
you
know
what
ended
up
happening
as
a
result
was
more
test
coverage,
is
then
a
better
understanding
of
how
Sinatra
and
rack
impact
each
other
and
then
what
use
cases.
The
Sinatra
errors
aren't
recorded
on
the
rackspan
versus
the
cases
where
they
are
so
with
that
we've
got
this
code
here
as
a
result
and
that
effectively,
like
reverted,
a
previous
commit
that
was
a
little
bit
erroneous,
but
that
previous
commit
added
the
use
cases.
A
C
Really
great
I'm
glad
it
got
figured
out,
I
kind
of
got
lost
at
one
point:
I
looked
at
the
PRS
yesterday
and
I
was
sort
of
like
I.
Don't
actually
understand,
what's
going
on
with
it
anymore,
so
I'm
I'm
glad
you
do
and
I'm
glad
they
were
able
to
find
a
good
solution.
C
It
kind
of
ties
into
something
I
was
thinking
about
bringing
up,
which
is
how
can
we
get
more
of
that?
Because
and
I
don't
want
to
speak
on
behalf
of
Shopify,
specifically
as
a
whole,
because
I
can't
do
that
right.
It's
too
big
but
I.
Think
in
observability
the
team's
focus
is
not
going
to
be
on
otel
Ruby,
so
much
at
the
moment,
largely
because
it's
it's
doing
what
we
need.
C
You
know
I'm
going
to
keep
trying
to
work
on
it
and
I
still
want
to
keep
working
on
the
metric
side
of
things,
but
I'm
kind
of
really
the
only
one
at
the
moment.
Francis
and
Robert
are
still
working
on
it
like,
but
it's
it's
less
focused
on
the
Upstream
stuff
and
more
on
some
of
our
weird
internal
hacks
that
we
do
to
keep
things
going
and
so
I
don't
want
the
project
to
die.
You
know
I
want
to
make
sure
we
have
healthy
contributions
from
outside.
C
A
How
do
we
get
more
Community
involvement?
Well,
what
I've
done
is
for
people
who
have
submitted
PR's
I've,
sent
them
messages
and
I'm
like
you,.
C
A
Involved
and
then
they
say
you
know
pretty
much
same
thing:
yeah.
C
A
Capacity
right
now,
but
I'll
try
to
help
in
everything
that
I
can
any
way
that
I
can
and
the
only
I,
don't
know
what
happened
to
you
know
we
got
to
reach
out
back
to
thoughtbot
yeah.
You
know,
I'm,
not
sure
what
happened
there.
I'm,
not
sure
what
happened
with
was
another
person
that
showed
up
for
a
little
while
you
know
I'm
sure
that
we
can
continue
to
appeal
to
vendors,
but
yeah
I
think
it
depends
on
how
many
people
are
in
the
Ruby
adoption
Universe
right
yeah.
A
You
know,
and
it's
like
just
like
with
any
open
source
project.
You
know
how
do
we
gain
traction?
There's
no
easy
answer
right!
No,
no
easy
answer!.
C
A
C
A
So
like
as
long
as
we're
behind
we're,
never
going
to
get
market
share
right,
and
that
is
a
you
know-
that's
not
a
that's.
A
that's
like
I
see
that
as
like
a
related
problem,
whereas
like
people
are
not
at,
are
not
asking
for
the
features
that
also
Ruby's
offering
right
now
is
probably
one
of
the
things
and,
as
a
result,
people
aren't
coming
to
give
contributions
back
to
Alto
Ruby,
or
we
just
like
also
are
not
good
at
advertising
right.
Maybe
we.
C
A
C
Know
I'm
on
some
I'm
on
some
mailing
lists,
like
Ruby
news
mailing
list
and
they
sent
out
an
update
of
like
here's,
the
big
gems
that
were
released
and
like
I,
never
see
ours
on
there,
I
wonder
if
we
should
maybe
like
poke,
whoever
runs
those
and
I'm
being
vague
about
it,
because
I
don't
remember
who,
but
I
can
find
that
out
being
like
hey
cover
hotel,
please
I,
don't
know.
B
Yeah
I
think
I
think
on
one
hand
we
are
probably
cursed
a
little
bit
in
that.
What
we
currently
have
is
working
for
for
for
a
lot
of
people.
I
think
we
eventually
a
metrics
SDK
is
going
to
be
something
that
people
are
going
to
want
and
ask
for,
but
I
think
a
lot
of
people
are
still
getting
by
with
their
stats
key
so
like
it
might
not
be.
A
B
There
is
kind
of
this
long
long-term
goal
of
having
libraries
build
tracing
in
or
build
Telemetry
in
using
oh
open,
Telemetry
apis
like
we
don't
have
to
maintain
third-party
instrumentation
for
them.
I
think
that
will
be
like
the
that
will
be
the
thing
that
makes
Hotel
more
attractive
than
a
vendor.
Specific
solution
is
when
the
stuff
starts
becoming
a
built-in
part
of
of
the
Frameworks,
but
I
do
actually
see
this
starting
to
happen
a
little
bit,
not
really
so
much
in
the
Ruby
world,
but.
C
It's
happening
elsewhere,
Thanos
actually
has
Hotel
tracing
built
in
now
they
just
converted
a
or
they
just
finished
a
migration,
or
mostly,
there's
still
lots
of
weirdness
there,
but
it
will
spit
out
hotel
now,
grafana
added
it
as
like
for
tracing
its
own
internal
requests
and
things,
and
those
are
the
ones
I've
been
looking
at
recently,
but
yeah
I've
started
to
see
it,
which
is
which
is
cool
actually.
B
I'm,
seeing
it
like
I,
don't
know,
I've
been
at
least
reading
through
the
Rust
book
and
looking
at
some
Rust
stuff
and
I've.
Seen
like
Tokyo
has
built
in
open,
Telemetry
tracing,
which
is.
B
I
don't
know
they're
there's
this
Redwood
JS,
it
is
a.
It
is
a
rails
like
JavaScript
framework.
That
apparently
has
some
funding
from
one
of
the
GitHub
Founders
and.
B
It's
not
the
framework
is
not
completely
100
authored
by
Redwood
JS.
They
use
some
off-the-shelf
things
like
graphql
and
they
were
using
this
Prisma
orm
and
I
was
kind
of
looking
at
Prisma.
Prisma
appears
to
be
written
in
Rust
and
there's
tracing
in
the
rust
layer,
but
then
there's
a
it's
a
rust
native
extension
that
has
a
a
JavaScript
layer.
That's.
C
That
dovetails
with
something
I
was
going
to
ask.
Some
people
at
Shopify
were
experimenting
with
hooking
the
Ruby
API
up
to
the
rust
SDK.
C
Just
because
we
wanted
to
see
how
fast
it
would
be
if
at
all,
which
I
have
Bots
for
and
against
it's
it's
Crossing
inner,
the
memory
barrier,
whatever
it's
complicated
but
I'm
wondering
like
do.
We
think
that's
a
good
strategy
overall,
like
if
we
people
had
talked
about
like
using
the
C
plus
SDK
in
that
way
like
building
native
extensions
from
other
languages
like
if
we
don't
have
an
incredibly
large
amount
of
contributors
working
on
the
SDK
proper,
and
that
holds
us
back
in
some
ways.
C
B
Moving
forward,
these
experiments
should
definitely
be
carried
out
and
the
viability
of
having
Ruby
v
a
thin
thin
wrapper
over
a
native
extension
if
successful
and
if
it
works
in
enough
environments.
Without
you
know,
compatibility
headaches
and
I
think
right
makes
sense,
but
I
think
that's
kind
of
one
of
the
other
goals
of
open
Telemetry
and
one
of
the
the
reasons
why
there's
like
this
strict
separation
of
API
and
SDK
is
that
we
hope
for
there
to
be
many
competing
SDK
implementations
over
time.
B
I
think
you
know
each
with
their
pros
and
cons,
I'm,
sure
yeah,
but
the.
B
Be
able
to
just
like
switch
out
your
SDK
at
will
and
not
have
to
really
change
your
your
code.
The
result
is.
A
You
know
if
I
had
a
if
I
had
my
preference
of
what
I
would
like
to
see
is
for
us
to
make
is
for
us
to
have
figure
out
some
sort
of
way
to
do
like
no
touch
instrumentation.
A
However,
that
gets
implemented
where
we're
able
to
at
you
know.
Well,
the
user
doesn't
have
to
make
any
changes
to
their
code.
A
I,
don't
know
anything
anything
from
adding
a
figuring
out
a
way
to
do
injection
of
like
a
required
Library
ahead
of
time.
You
know
so
some
you
know.
Node
has
this.
You
know
where
you
can
add
in
like
a
required.
Library
Ruby
has
the
ability
to
add
required.
Libraries
I
just
don't
know
with
how
how
to
make
this
reasonable
for
people
in
the
in
the
world
of
bundle
exec.
You
know.
C
A
And
if
we
were
hitching
my
wagons
to
something
if
we
could
figure
out
how
to
use
ebpf,
that
might
be
something
the
HR
wagon
2,
as
opposed
to
like
looking
for
a
language,
specific
extension,
but
it
to
some
degree
right.
Abpf
is
like
you,
gotta
write
it.
It's.
A
And
it
requires
like
basically
binary
compatibility
rate.
So
it's
like
you
know,
I,
don't
know
what
other
constraints
there
are.
But
no
you
know
it's
all
very
experimental
yeah.
It's.
C
Like
it's
good
to
think
about
it,
and
it
may
be
like
not
the
right
time
to
do
something
like
that-
maybe
things
are
too
experimental
elsewhere,
but
I
was
just
thinking
about
it.
Like
I,
you
know,
after
I
work
on
active
support,
notifications,
I'm,
going
to
turn
my
attention
to
metrics
again
and
like
it's,
the
big
lift
and
then
logs
is
right
behind
it,
and
you
know.
A
It's
yeah
a
lot
logs
is
like
a
whole.
B
Yeah
no
I
think
good
brainstorming
session
in
the
short
term.
Anybody
who
does
come
around
and
contributes
and
seems
Seems.
You
know
like
a
person
that
we
would
like
more
contributions
from
I
think
definitely
reaching
out
to
them.
Sending
them
messages
on
slack,
encouraging
them
and,
and
all
those
just
kind
of
General
Outreach
things
that
we
can
do
would
would
be
awesome.
I
think
I
think
that's
how
we've
found
the
people
who
are
working
on
the
project
today.
C
A
A
You
know
dependency
or
have
some
gem
file
that
we
include
into
the
other
gem
files
and
then
I
thought
about
it
like
no,
because
eventually,
there's
gonna
come
a
Robocop
rule
that
we're
going
to
want
to
disable
for
some
gems
and
not
for
others
and
might
be
easier
just
to
upgrade
like
one
gem
at
a
time.
I
wasn't
exactly
sure,
but
it's
like
all
of
the
gems
seem
to
all
depend
on
say,
like
the
API
has
a
gem
or
no
sorry,
not
a
web
mock
the
code
coverage
one.
A
C
A
What
yeah
it's
like
right
right
right
now,
you
know
dependent
part's,
watching
One
gem,
every
every
gem
separately
right.
It's
not
doing
like
one
massive
PR
for
all
of
the
gems
on
the
repo.
So
it's
like,
oh
Monday
morning,
I
woke
up
and
it's
like
here's.
You
know
every
gen,
here's
a
PR
for
every
gem
to
upgrade
RoboCop
and
the
amount
of
time
that
it
takes
to
run
through
the
builds
and
merge
and
all
that
stuff
it
just
seems
like
it,
takes
forever.
C
Ryan,
the
speed
of
the
build
is
something
I
was
thinking
about
again
today,
yes
or
not
today,
yesterday
as
well,
when
you
mentioned
that
it
was
taking
a
while
for
runners
to
pick
up
our
jobs
that
seemed
like
it
was
taking
a
lot
longer
than
it
should
have.
Actually
I
was
surprised
that
it
was
taking
that
long
for
him
to
get
picked
up.
A
I
don't
know
the
other
thing.
Jobrunners.Org
has.
C
I
don't
know
either
it
would
be
nice
to
have
more
alternately.
I
will
spin
up
a
VM
on
my
home
server
and
run
in
actions
Runner
here
and
we
can
just
use
my
CI
and
Andrew's
server,
closet
and
Let
It
Go
I
was
gonna.
Ask
do
you
think
we
should
switch
dependabot
updates
to
monthly?
It
would
be
more
all
at
once,
but
then
we
would
have
three
weeks
of
nothing
and
maybe
that
would
be
less
miserable.
C
C
C
C
Ide
all
right,
well,
I'm,
gonna,
drop
off
and
go
finish,
rebuilding
my
ZFS
array.
So
all.