►
From YouTube: 2021-09-07 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).
B
A
Gotcha
matt's
out
today,
so
we
probably
aren't
gonna,
get
a
metrics
update
right
and.
A
Getting
recorded
it's
possible,
I
think
that's.
The
same
person
was
that
indrik
that
came
in
asking
for
eyes
on
that.
Pr,
maybe.
B
A
So
I
I
think
I
think
he
had,
I
think
francis
had
requested
changes
right.
So
as
long
as
francis
resolves
that
I
can't
speak
on
his
behalf
right
about
the
concerns
that
he
had
to
look
through
those
right.
A
And
he
was
out
last
week
right,
so
you
know
this
might
be
like
with
a
million
things
you
know
when
you
go
on
vacation,
you
come
back.
I
I
personally
declare
bankruptcy
from
notifications.
Whenever
I
start
I'm
like,
I
just
erase
everything,
if
you
really
want
me,
you'll
ping
me
again.
A
A
B
B
So
francis
will
not
be
able
to
speak
at
the
moment.
Okay.
A
B
B
B
Arises
there
are
you
able
to
see
my
screen.
B
B
B
A
B
B
It's
replacing
the
notifier
with
the
custom
notifier,
and
so,
if
anything,
registered
a
notification
before
that
it
gets
wiped
out.
D
B
So
we
saw
yeah,
so
we
saw
some
internal
tools
to
kind
of
go
wrong
for
a
very
specific
code
path.
It's
a
little
bit
dated
in
our
org,
but
basically
it
was
subscribing
to
some
information
on
controllers
actions
when
they
performed
and
they'd
use
it
for
logging
purposes,
and
so
at
any
time
anyone
would
use
our
instrumentation.
B
It
would
just
clear
that
out
so,
fortunately,
unfortunately,
it
only
really
impacted
some
of
the
less
maintained
apps,
because
it
was
kind
of
an
old
way
of
adding
logs
we've
kind
of
moved
on
and
replaced
that,
but
there's
still
some
apps
that
just
don't
get
that
much
attention.
So
that's
the
ones
that
saw
it
right
now.
Tim
has
a
fix
up
for
it.
C
Yeah,
I'm
sorry
I
didn't
mean
to
interrupt,
but
it
uses
delegate.
I
I
don't
know
if
it's
a
good
solution
to
wrap
a
class
in
delegate
the
reason
why
I'm
using
it
is
because
we
don't
control
the
creation
of
the
active
support
notification
fan
out
so.
A
C
A
B
B
A
About
the
about
the
internals
of
notifications
and
right,
I've
never
done
anything
like
this
before
so
I
don't
know
what
the
implications
are
of
the
windows.
B
Yeah,
I
haven't
spent
that
much
time
myself,
so
I
went
through
it
and
it
does
make
sense.
A
I
guess
would
the
other
option
be
to
extend
the
option?
Object
instance
itself,
as
opposed
to
using
a
delegate
class.
A
B
That
makes
sense.
I
think
that
becomes
tricky
too,
because,
like
realistically,
I
think
yeah.
I
guess,
if
someone's
not
using
like
they're
holding
onto
the
reference
like
you
said,
but
you
would
hope
that
they're
going
through
like
the
formal
api
of
like
reaching
for
the
notifier
instead,
but
I
mean
everybody,
does
all
sorts
of
kooky
stuff
right.
A
And
it
sounds
like
what
we
do,
because
this
would
be
different
than
the
pattern
that
we
do
now,
which
is
pre-pending.
The
existing
class
instance
right
and
so
like
the
birth
class,
would
have
like
the
it's
changed
and
any
new
object.
Instances
derived
from
that
will
have
this
functionality,
whereas
any
new
instances
of
I
found
out,
even
though
we
don't
control
the
creation,
and
we
think
that
it's
a
singleton,
I
run
time
in
this
process.
B
Yeah,
that's
why
I
guess
we're
hoping
for
our
one
of
our
experts
to
come
in
and
tell
us
why
this
is
fine
or
not
fine,
yeah,
so
we're
giving
them
some
time,
but
short
of
that,
I
guess
we'll
have
to
become
experts
in
it
ourselves.
A
Which
understood
yeah-
and
this
is
specifically
because
the
active
view
active
view
spans-
are
dependent
on
notifications.
B
Correct
so
that
leads
into
another
pr
here
that
tim's
been
working
on,
and
so
the
idea
is
that
we
have
some
teams
that
arbitrarily
subscribe
to
notifications
and
they
want
to
generate
spans
off
of
it
and
that's
functionality
that
we
supported
with
our
bespoke
tracing
framework
but
isn't
currently
supported
in
what
we
have
here.
B
So
the
idea
is
that
originally
this,
this
action
view
or
the
active
support
notification
code
lived
in
the
rails
gem
I
moved
it.
I
stepped
into
action
view
because
that's
the
only
place
it
was
being
used,
but
now
we've
kind
of
hit
the
point
where
there
are
other
potential
consumers
of
it,
and
there
are
subjects
like
there
are
ideas
that
come
up
like
well.
What,
if
we
have
other
instrumentation
libraries
like
for
action,
packs
say
that
depend
on
notifications.
B
They
should
be
able
to
depend
on
it.
So,
like
active
support,
instrumentation
becomes
the
kind
of
this
cross-cutting
dependency,
which
is
fine
because
that's
how
it
is
in
rails
as
well
right
like
if
you
look
at
rails,
it's
like
they
have
all
their
gems
and
active
support
cuts
across
most
of
those
gems.
It's
just
expected.
So
I
don't
think
it's
unreasonable
for
our
instrumentation
to
be
structured
in
the
same
way.
B
One
of
the
things
that
came
up-
and
I
was
just
kind
of
bouncing
ideas
back
and
forth-
is
that,
like
action
view,
it's
like
well,
if
you
have
the
action
view
gem
like
what
is
it
actually
doing?
It's
just
subscribing
to
a
couple
notifications
like
our
instrumentation
is
anyway,
so
it's
like
should
it
exist,
and
after
some
back
and
forth,
I
think
we
landed
on
like
yeah
it's
consistent.
B
So
there
is
some
work
being
done
here
to
extract
this
out,
there's
some
stuff
that
needs
to
be
sorted
out
in
terms
of
how
do
we
make
sure
that
this
thing
doesn't
get
set
up
multiple
times,
tim's
been
working
on
that
I
kind
of
encouraged
him
to
focus
on
fixing
it
before
we
push
any
further
on
this,
because
with
our
fix,
we
don't
know
how
that
will
impact
this
exactly
right,
and
we
still
don't
know
if
the
delegate
approach
is
going
to
stick.
B
But
the
idea
is
here:
is
that
we'll
be
extracting
this
into
a
gem
that
anyone
can
use
and
subscribe
to,
but
it'll
get
pulled
in
by
rails,
just
like
everything
else,
and
then
action
view
will
depend
on
it
as
well,
and
then
anything
else
that
needs
to
subscribe
to
notifications
as
part
of
its
instrumentation
will
depend
on
it.
A
B
So
I
think
this
is
pretty
useful,
because
I
know
that
there
has
been
some
requests
for
active
support
notifications,
whether
it's
indirectly
like
saying
I
want
to
instrument
some
active
record
calls
I'd
like
to
use
active
support
notification
and
then
the
connect
record
instrumentation
doesn't
quite
support
that.
So
it's
like
it's
going
to
make
that
possible,
and
I
think
this
is
like
a
really
useful
pr
for
the
rails
community
in
terms
of
instrumentation,
but
it's
kind
of
blocked
by
the
the
fix
right
now.
B
Another
pr
came
up
the
other
day.
I
looked
at
it,
but
I
am
not
as
familiar
with
faraday,
so
I
needed
to
dig
into
it
a
little
bit
so
they
they
came
in
to
try
to
fix
a
specific
issue,
but
I
think
they
ended
up
fixing
it
like.
I
don't
know
if
this
fix
needs
to
be
actually
pushed
in
already,
but
the
idea,
as
I
understand
it,
is
they
changed
the
way
the
patch
works,
so
that
it
happens
before
any
other
faraday
middleware.
C
B
So
then
the
headers
are
looks
like
they
have
like
something
about
like
headers
being
hashed
to
like
create
a
signature,
and
if
your
middleware
isn't
added
before
something
else,
then
that
breaks.
But
ultimately
I
don't
know
if
this
this
change
makes
sense
still
right.
D
Yeah
in
general,
it's
better
if
it's
the
last
middleware
to
run,
I
mean,
basically,
you
want
to
do
your
tracing
as
close
to
the
wire
as
possible.
I
mean
there
are
obviously
interesting
use
cases
where
you
want
to
trace
your
middleware
performance,
but
by
and
large,
by
default.
You
want
your
tracing
as
close
to
the
wire
as
possible,
so
the
solution
that
they
came
up
with
of
telling
the
aws
middleware
to
ignore
signing
the
or
ignore
the
the
tracing
headers
for
signing
purposes
is
probably
the
the
correct
one
here.
D
D
D
A
B
Cool,
I
think
then,
we'll
probably
end
up
closing
this
vr.
He
just
said
feel
free
to
close
it.
If
we
don't
want
to
do
it.
A
I
think
providing
reasoning
makes
sense
or
and
giving
them
the.
B
A
B
I
think
ariel
has
this
handled
with
this
pr.
Johnny
is
going
to
change
the
ridiculous
spec.
A
A
Part
of
me
well
actually
well
part
of
me
wanted
to
talk
about
like
tone,
and
I
interpreted
the
tone
as
being
very
harsh,
and
I
don't
want
to
like
constantly
be
digging
people.
I
don't
know
how
y'all
felt
about
it,
but
when
I
read
it,
the
tone
seemed
harsh
to
me
and
seemed
to
run
contrary
to
what
we
would
expect
out
of
contact
with
people
who
are
trying
to
contribute
to
this
project.
A
So
this
is
the
first
instance
where
I
see
something
like
this.
I
just
want
to
get
your
take
on
it.
B
It
it
this
has
actually
come
up
in
the
past
with
this
like
exact
person,
and
I
think
the
what
I
remember
at
least
might
take
away
from.
It
is
like
this
person's
very
direct,
and
it
could
just
be
a
cultural
difference
and
like
it
is
hard
to
infer
tone
over
text
and
short
of
anything
that
is
like
actually
explicitly
harsh
like
using
name
calling
or
anything
like
that,
and
it's
like
I'm,
not
gonna.
I
personally
am
not.
B
B
That's
crossed
and
him
being
critical
of
like
a
technical
decision,
and
I
think
that's
kind
of
fair
game
like
people
are
allowed
to
have
opinions,
and
it's
not
too,
like
inflammatory,
like,
I
think
ridiculous,
is
kind
of
a
not
the
best
choice
like
I
agree
what
you're
saying,
but
it's
just
like
it's
not
directed
at
any
individuals,
it's
not
being
rude
to
any
individual.
It's.
A
A
There's
a
difference
between
between
being
openly
aggressive
or
insulting
to
an
individual
versus
to
a
thing,
but
I
think
that,
like
I
don't
want
to
create
an
environment
where
people
are
like
this
code.
Submission
you
gave
me
was
garbage
right
because
that's
not
that's
not
creating
an
inclusive
environment
here
for
us
or
wanting
to
get
other
people
to
contribute.
A
So
I
don't
know.
I
think
I
I
think
if
this
comes
up
one
more
time,
I
will
point
them
to
that.
B
A
B
Yeah
like
that,
honestly,
I
think
it's
fine
to
point
to
the
code
of
conduct
like
it's
just
for
for
them,
like
the
history
has
just
been
like
very
direct
terse
comments,
and
it's
it's
easy
to
assume
now
intent,
but
anyways,
you
know
I
I
don't
know
I
don't
for
like
this
particular
example.
It's
like
he's
very
passionate
and
offended
that
jesus
is
not
the
default
and
that's
how
I
take
the
tone,
and
I
think
that,
like.
A
B
It's
just
like
it's
not
directed
at
any
one
individual.
He
just
thinks
that
he
wants
things
to
be
better
and
he
believes
that
gzip
by
default
is
better
and
that's
okay,
even
if
the
tone
is
a
little
bit
unnecessarily
aggressive
for
a
pull
request
so
anyways.
I
think
that,
like
we'll
leave
that
open,
because
he
wants
to
push
the
spec
change
and
that's
fine,
we'll
see
how
that's
received,
I
think
we've
already
talked
about
using
default
here.
B
This
is
like
it
got
reverted,
so
we
have
to
wait
till
that
settles.
I
think
I
just
need
to
merge
this
one
right.
A
B
If
you
want
to
rebase
it
and
then
ping
me,
because
I
can't
usually
there's
like
the
update
branch
button,
I
don't
know
why
it's
not
there,
but
if
you
want
to
do
the
rebase
and
then
being
new
once
it's
green
I'll
just
go
ahead
and
merge
it.
It
looks
good.
B
A
Tracing
back
and
come
up,
yeah,
okay
and
yeah
robert
I'm
sorry,
I
haven't
looked
back
at
this
yet,
but
essentially
what
let
me
just
walk
you
all
through
what
happened
I
got
together
with
rob
kid.
We
took
the
the
startup
guy
that
was
on
honeycombs
docs
and
brought
him
over,
and
then
she
started
like
re-drafting
it
to
see
what
it
would
look
like.
But
I
think
where
we're
gonna
land
on
this
is
it's
gonna,
be
the
minimum
thing
that
you
need
to
get
the
tracer
configured
with
auto
instrumentation
on
and
then
it's
like.
A
Do
you
want
to
visualize
these
traces?
Where
do
you
want
to?
Where
do
you
want
to
see
them
and
then
we'll
take
them
to
a
step
to
give
them
the
option
to
like
use
yeager,
for
example,
and
to
run
it
locally
so
that
they
can
see
what
the
traces
look
like
and
then
from
there
hop
into
another
guide,
which
is
going
to
be
advanced
configuration
references
to
the
auto,
collector
and
so
on
and
so
forth?
But
what
we're
going
to
start?
A
Is
I'm
going
to
get
back
on
this
this
week
and
again,
change
essentially
change
the
index
markdown
to
be
I'm
just
getting
the
sdk
configured
and
okay?
It
may
not
export
traces
anywhere,
but
it'll
just
be
that
as
our
first
pr
to
pull
in
and
then
I'll
go
back
to
open,
telemetry
io
and
I'm
gonna
configure
it
to
be
to
pull
this
these
docs
in
as
a
sub
module,
which
it's
not
do,
which
is
what
it
does
with
other
with
other
projects.
A
A
So
I'm
going
to
look
to
expand
on
that
too,
which
is
to
like
talk
about.
Hopefully
we
can
expand
on
auto
instrumentation
and
customizing,
auto
instrumentation
as
a
subsection,
but
I
went
on
vacation
and
then
I
came
back
and
I
did
all
this
other
stuff
and
then
I
didn't
look
back
at
this.
So
that's
my
apologies
to
everybody.
B
B
B
So
they
reached
out,
as
we
pointed
out
earlier,
I
think
francis
had
requested
changes
somewhere
along
the
way
they've
since
updated.
I
don't
know
I
should
go
over
through
this
as
well.
I
haven't
to
be
honest.
I.
D
I
need
to
go
back
and
take
a
look.
It's
basically
a
recommended
changes
using
the
propagators
so
basically
defining
a.
I
think,
we're
defining
a
new
propagator
and
it
turns
out
that's
really
annoying
on
the
extract
side.
It's
fine
on
the
inject,
but
not
extract
so
yeah.
I
just
said
this
looks
terrible
on
the
extract
side.
So
let's
just
do
the
explicit
thing.
Instead,.
D
Sorry
it
it
does
it's
an
api.
It's
sorry
not
come
on
man.
Indrex
code
is
awesome.
This
is
great,
but
it
our
api
forces
terrible
things
right
forces.
D
To
do
terrible
things
and
yeah
like
it's,
it's
a
problem
really
with
with
our
api,
it's
basically,
if
you
have
to
loop
over,
let
me
pull
up
the
code
actually.
Can
you
pull
up
the
code
here
from
that
pr
just
so,
I
can
insult
myself
accurately
sure.
D
The
api,
the
the
key
api,
uses
a
tags
array,
and
that
means
that,
on
the
extract
side,
you
need
because,
like
yeah
anyway
on
the
extract
side,
you
have
to
iterate
over
the
entire
array
and
the
way
the
extract
api
works.
You're
handed
the
key
that
you're
looking
for
and
potentially
your
propagator
may
require
multiple
keys,
in
which
case
multiple
header
keys,
in
which
case
the
api
is
going
to
be
iterating
over
this
array
multiple
times
it's
just
going
to
be
for
every.
D
Tags
array,
and
so
the
solution
to
that
was
well.
Let's
create
this
cached
like
turn
the
array
tags
array
into
a
hash
once
cache
it
in
the
extractor
or
the
getter
sorry.
But
that
means
that
the
getter
is
not
reusable
and
the
getter
is
intended
to
be
reusable
right
in
the
api,
so
yeah.
This
is
just
really
unfortunate.
The
api
really
assumes
that
you're
given
a
an
efficient.
D
You
know
hash
data
structure
or
something
you
know
an
efficient,
an
efficient
map
from
keys
to
values,
and
in
this
case
we
don't
have
that
efficient
data
structure,
understood
so
yeah
you're,
you're,
basically
forced
to
jump
through
hoops,
and
my
feedback
was:
let's
not
jump
through
hoops
by
adding
the
get
her
abstraction.
Instead,
just
do
the
conversion
to
the
hash
up
front
and
use
the
defaults.
D
I
appreciate
the
the
insights.
Thank
you
yeah,
so
injection
super
easy
because
you're
just
appending
it
to
the
tags
array,
but
extraction
means
that
you
have
to
keep
get
a
rating
over
it
or
do
this
yeah.
Do
this
hash
conversion,
but
anyway,.
D
I
don't
know
we
should
if
this
problem
comes
up
again,
we
should
think
about
whether
there's
a
better
way
of
doing
this.
I
just
don't
know
what
it
is
right
now
it
would.
It
would
basically
be
you
know,
here's
all
the
keys
that
I
want
you
to
look
up
right
and
do
a
single
pass
over
the
array,
but
that's
not
the
way
the
the
apis
work,
and
this
is
really
a
spec
issue.
I
don't
think
it's
a
ruby
implementation
issue.
B
B
A
I
think
we,
you
know,
you
saw
a
blog
post,
we're
trying
to
drive
the
adoption
of
semantic
conventions
and
then
internally
adopt
some
engine
conventions
across
the
board
and
logging
is
a
big
signal,
a
very
highly
used
signal
in
our
organization,
so
like
internally,
we're
like
driving
wanting
to
drive
the
logging
sdk
work
and
we're
we
we've
we're
still
working
on
that,
but
not
trying
to
do
anything
with
hotel.
Specifically
right
now,
I
don't.
A
So
that
is
the
message
that
I
am
spreading
across
the
world:
one
one
yeah
one
github
development
team
at
a
time
right.
B
Yeah
we're
fighting
that
same
battle,
so
lovingly
there's
always
like
a
team
that
tries
to
implement
tracing
with
logs.
It's
like.
We
just
passed
this
idea
around,
and
then
we
can
stitch
all
the
logs
together.
B
A
B
A
lot
of
the
stuff-
the
open
pairs
here
are
a
bit
older.
Now.
A
Do
we
get
to
the
point
where
we're
like
here,
your
your
the
prs
that
we
have
that
are
outstanding?
We
give
them
a
certain
amount
of
time
and
maybe
auto
close
them
with,
like.
B
D
So
an
interesting
data
point
on
that
is
that
the
4318
is
default,
otl
or
otlp
exporter
port.
This
is
blocked
on
a
spec
pr
that
has
been
threatened
with
auto
closing,
I
think,
like
three
times
now,
so
it's
yeah,
it's
interesting
right.
It's
like
this
is
blocking
a
fairly
significant
change
across
a
whole
bunch
of
projects,
and
there
is
a
bot
sitting
there
just
like
poking
it
and
there's
still
been
no
progress
except
somebody
keeps
reopening
the
thing.
B
B
I've
just
I've
seen
a
lot
of
repos
in
the
past
that
have
like
the
stale,
bots,
closing
issues
that
just
never
were
resolved
or
like
it
wasn't
clear
if
it
was
all
like
if
we're
going
to
close
something,
be
like
hey,
this
isn't
an
issue
anymore
or
something
like
leaving
like
a
human
breadcrumb.
Not
this
is
stale
beep
boop
clothes.
B
Okay,
I
think
it's
a
bad
end
user
experience,
but
it's
also
different
like
we're
not
drowning
in
issues
in
pr's.
Right
now,
or
at
least
I
don't
think
we
are
okay.
18
18
is
not
that
many,
so
yeah.
B
That's
those
terrible
maintainers
are
not
doing
a
good
job
of
going
through
and
grooming.
This
list
yeah.
I
think
that's
also
something
that
maybe
should
be
addressed
by
like
people
who
can
close
or
action
issues
is
like
actually
going
through
and
looking
at
them
and
tagging
them
appropriately
and
potentially
closing
them
if
they're
not
relevant,.
D
Yeah,
I
think,
along
those
lines,
we
have
tended
to
be
nice
and
not
close
issues
where
we've
either
said
you
know
effectively
we're
not
fixing
this
or
we've
explained
what
the
solution
is
and
we're
really
just
waiting
for
acknowledgement
from
the
person
who
opened
the
issue
to
say
that
yeah,
it's
okay,
but
I
I
think
it's
probably
reasonable.
D
Sorry,
not
probably
it
is
reasonable
for
us
to
go
through
these
things.
Where
we've
provided
some
context.
We've
explained
why
either
it's
not
a
problem
or
it's
not
something
that
is
going
to
be
fixed
at
this
level,
because
it's
a
spec
issue
and
there's
been
no
response
for
a
while.
We
should
probably
just
close
them
as
stale
asking
maintainers
to
continually
troll
through
71
issues
to
see
if
anything's
still
relevant
is
not
the
best
use
of
time.
B
Yeah
so
like
a
like
an
issue
like
this
eric
responded
and,
like
I
tried
recreating
this
issue
and
it's
like:
do
we
close
it
and
say
hey
like
we
haven't
been
able
to
recreate
this
issue?
Can
you
provide
us
reproduction.
A
That
seems
sensible
to
me
like
if
they
can
open
a
repository,
that
it
has
or
give
us
some
sample
code
like
like
a
thing
that
can
consistently
reproduce
the
problem.
Yeah
then
I
think
that's
reasonable.
The
other
thing
that
we
can
do
is
probably
label
these
with
labels
like
can't
reproduce
or
need
help
or
whatever
yeah,
so
that
they
stand
out
to
us
at
least.
B
I
I
would
feel
comfortable
like
closing
this
and
saying,
like
I
wasn't
able
to
reproduce
this
if
you
could
feel
free
to
reopen
it
with
a
reproduction
and
we'll
look
into
it,
because
it's
like
right
now,
it's
just
it's
nothing
right.
It's
not!
It's
not
actionable.
Unfortunately,
right.
B
A
So
what
do
we
like?
Would
it
would
it
make
sense
to
say
like
for
each,
for
we
have
like
a
rotation
where
we
assign
people
issues
for
triage.
B
A
C
A
Getting
updates
on
them
closing
them
whatever?
Would
you
be
okay
with
us
just
like
splitting
the
list
up
and
assigning
you
to
some
right
that
work?
I
think
so,
and
you
know
maybe
we
can
we're
open.
A
couple
of
folks
haven't
been
here
for
a
little
bit
like
other
francis,
and
is
it
daniel
yeah?
You
can
get
them.
You
know
involved
again
in.
D
There's
always
the
conflicts
between
people,
but
there's
also
conflicts
with
available
cncf
zoom,
which
are
reused,
and
we
had
to
move
this
previously
because
it
was
butting
up
against
a.
I
don't
think
it
was
a
specific
meeting,
but
it
was
one
of
it
was.
D
It
was
some
monthly
meeting
that
occasionally
would
overlap
with
either
the
start
or
the
end
of
this
meeting,
which
was
problematic
because
it
also
messes
up
the
recordings,
there's
kind
of
the
auto
recording
thing
which
posts
to
youtube
and
that
relies
on
everybody
leaving
the
meeting.
D
A
B
This
time
works
for
me
for
whatever
it's
worth
like.
This
is
fine
for
me
because
it's
like
right
leads
right
into
lunch,
which
is
nice,
but
I
think,
like
people
missing
today
is
just
time
off
right.
A
B
D
B
We
did
yes,
I
did
request
the
review,
he
did
respond,
but
I
haven't
seen
anything
since
so
I
don't
know
if
anyone
else
wants
to
pester
carlos.
That
would
be
cool,
but.
B
D
I'll
poke
him
and
see
if
he's
got
any
feedback.
Otherwise,
what's
our
path
to
1.0
milestones,
we
have
no
open
issues
right
now
against
our
tracing
v1
milestones.
So
technically
we
should
just
be
able
to
go
right
ahead.
B
B
I
know
like
instrumentation
isn't
part
of
the
1.0,
but
because
we
do
these
like
big
releases,
I
think
that,
like
at
fairly
something
like
the
the
active
support
action
view
stuff
should
get
sorted
before
we
do
it,
because
people
will
inevitably
pull
it
in.
I
think
stuff
like
that,
does
matter,
because
it,
even
though
that,
like
once
again
like
instrumentation,
doesn't
have
that
spec
guarantee
people
see
it
the
same.
B
Like
I
know
I
would,
I
would
think
of
this
all
as
like
the
same
thing
right,
open
telemetry
has
bugs
at
the
1.0
release,
it's
like,
so
any
the
more.
We
can
clean
up
before
doing
that
the
better,
but
I
don't
think
it
should
necessarily
block,
but
just
I'd
like
to
see
like
at
least
these,
like
known,
glaring
things
around
like
rails,
which
is
obviously
going
to
be
widely
used.
D
Yeah,
I
think
we
just
don't
want
to
drag
it
out
for
too
long.
We
want
to
get
this
get
a
1.0
release
out,
so
that
people
can
feel
like
they're
able
to
build
on
this
yeah,
and
even
if
we
have
to
deal
with,
you
know
inevitable
issues
that
arise.
D
Getting
a
1.0
release
out
also
means
that
more
people
are
going
to
be
using
it,
which
means
we're
likely
to
get
more
bug
reports
and
that's
helpful
for
us
as
well
right.
B
Yeah,
so
I
guess
like
if
you're
gonna
give
carlos
an
edge
this
week
or
for
this
week.
Hopefully
we
get
something
actionable.
Tim's
gonna
be
working
on
the
active
support
stuff
this
week,
so
hopefully
that'll
be
wrapped
up
by
end
of
week
and
then
so,
barring
anything
dramatic.
Next
week
we
could
look
at
doing
a
1.0.
D
I
don't
know
we
can
ask
carlos
for
specifics
there
I
feel,
like
I
feel
like
there's
something
that
has
to
happen
either
in
the
community
repo
or
the
spec
repo
yeah.
But
I
I
don't
know
the
details.
B
Okay,
okay,
I
think
in
terms
of
like,
hopefully
nothing,
magical
or
awful
appears
between
now
and
then,
but
I
think
next
week
we
could
try
to
aim
to
do
that.
D
A
My
goodness
ten
minutes
early,
you
all
a
friend,
I'm
fresh
and
fast
amazing.