►
From YouTube: 2022-02-01 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
B
B
D
E
E
F
Yeah
I,
since
I've
like
I'm
in
ottawa,
right
now-
and
I
don't
have
like
my
like
gaming,
pc
or
a
lot
of
friends
here
to
socialize
with
or
do
anything,
so
I
pretty
much
work
from
like
eight
to
eight
or
eight
to
ten
most
days
and
just
stop
for
lunch
and
dinner,
and
it's
like
it's
not
good.
I
don't
think.
F
C
F
There
was
a
surprising
amount
of
american
and
confederate
flags
in
downtown
auto,
which
I
found
really
confusing
yeah,
but
again,
maybe
that's
the
best
conversation
for
a
recorded
cig.
D
Yeah
started
off
with
a
quick
update
on
metrics
kind
of
similar
to
last
week.
I
think
they
are.
They
would
like
to
declare
the
sdk
as
stable.
There
are
kind
of
the
three
issues
that
that
we
talked
about
last
week.
This
link
is
kind
of
that
same
the
same
slides.
I
guess
that
try
to
describe
the
problems,
but
I
think
the
consensus
was
that
these
changes
would
be
non-breaking
on
the
api
to
support
them
so
that
they're
not
necessarily
holding
up
the
sdk
stable.
D
There
was
a
little
bit
of
discussion
about
that
to
ensure
that
that
was
true.
It
seemed
like
it
probably
is,
but
but
then
we
kind
of
got
into
the
main
event,
which
is
we've
covered
this
a
couple
times
now
in
a
few
different
ways,
but
it
is
basically,
we
have
instrumentation
library
which
scopes
spans.
D
So
you
kind
of
bash
your
spans
by
instrumentation
library
and
the
logging
sig
was
on
the
verge
of
introducing
like
a
a
logger
name
for
their
benefits.
But
there
was
some
discussion
about
isn't
that
kind
of
the
same
as
instrumentation
library
name
and
it
kind
of
spawned
this
discussion
where
like
what?
D
If
we
just
were
a
little
bit
more
generic
and
referred
to
this
as
instrumentation
scope
and
allowed
it
to
be
like
a
set
of
key
value
pairs,
perhaps-
and
just
some
like
various
proposals
floating
around-
and
there
is
a
new
proposal.
D
That
actually
has
protos
behind
it
and
the
feedback
was
generally
of
two
types.
Most
people
really
liked
this,
so
you
would
have
you
have
a
resource,
you
have
a
scope
and
then
for
the
metrics
version
you
have
resource
metrics
for
traces.
I'm
sure
you
have
resource
fans
where
you
have
a
a
resource
and
scope
metrics,
and
then
you
have
some
metrics
in
a
scope.
D
D
There
was
a
lot
of
an
uproar
that
this
would
not
be
backwards
compatible,
however,
and
I'm
not
sure
from
what
angles
that
was
all
coming,
because
I
think,
if
you
kind
of
enforce
the
semantic
convention,
you
could
at
least
ensure
the
data
was
in
here,
but
I
think
for
anyone
like
consuming
the
data,
definitely
would
not
be
like
a
backwards
compatible
change.
D
C
Well,
in
the
tracing
context
of
for
scope
in
a
tracing
context,
would
the
repeat
you
know
so
in
the
in
the
product
buffer,
where
it's
like
message,
scope,
metrics
and
then
repeated,
and
it's
like
a
list
of,
I
guess
like
metric
names.
So
would
that
be
for
tracing?
Would
that
be
spam?
Names
like
span
operation
names
or
what?
What
would
that
I'm
confused
on?
What
that
would
look
like.
D
So
I
think
it's
really
any
arbitrary
key
value
pairs,
but
I
think
for
for
now
to
retain
backwards
compatibility.
The
scope
would
be
instrumentation
library
and
instrumentation
version,
instrumentation
library
version,
whatever
those
two
pairs,
are
right.
Now
that
kind
of
make
up
the
instrumentation
library
spans
in
the
current
photos,
if
that
makes
sense,
but
you
would
be
able
to
in
theory
like
decorate
that
batch
of
spans
with
kind
of
more
you
know,
common
scope
attributes
if
you
wanted
to
so
it
kind
of,
would
be
extensible
beyond
that.
Does
that
makes
any
sense.
C
So
it's
yeah,
it's
okay,
so
I
guess
I'm
a
list
of
I'm
just
so
it's
like.
If,
but
if
this
prayer
buff
were
defined
for
instead
of
scope,
metrics
it
was
scope,
traces,
a
collection
of
traces
from
a
scope
within
a
resource.
C
So
the
first
field
is
the
for
the.
I
guess
what
so
that's
it's
that's
where
instrumentation
name
and
library
would
be
in
scope,
and
then
I'm
just
confused
on
this.
Like
repeated
field
of
what
that
would,
I
guess
I
should
read
the
proposal,
but
it's
unclear
whether
that's
just
additional
attributes
or
is
that
the
list
of
actual
operation
names
or
or
yeah?
Okay?
So
I
guess
I
have
to
read
the
I
think
it
makes
sense.
C
I
just
have
to
read
the
proposal
and
it
definitely
would
be
breaking
for
consumers
of
stuff,
but
not
in
a
way
that
couldn't
be
easily.
You
know
it's
just.
You
have
to
update
the
mapping
a
little
of
like
how
you
look
up
the
instrumentation
library
name,
but
it's
certainly
breaking
in
that.
You
have
to
make
sure
you
roll
out
the
change
like
or
you.
You
would
probably
have
to
have
support
for
both
lookups
at
some
point,
because
you're,
probably
having
like
an
older
instrumentation
and
then
newer,
instrumentation.
C
D
I
just
kind
of
brought
up
the
existing
stuff.
I
think
what
you
would
end
up
with
is
instead
of
instrumentation
libraries
fans,
you
would
end
up
with
scope
spans
and
you
would
have
repeated
spans
with
just
a
scope
here:
okay,
okay
and
then
I
think
the
idea
is.
You
would
embed
like
instrumentation
library,
like
in
the
scope,
more
or
less
with
anything
else,
and
then
you
just
kind
of
have
like
this
batch
of
spans,
with
kind
of
like
this
scope
data
attached
to
them.
Okay,.
C
I
get
it
so
the
repeated
thing
isn't
like
a
list
of
like
string.
It's
like
the
right,
it's
it's
it's
the
actual
spans
and
then
the
span
objects
and
then
the
in
the
scope
is
essentially
just
a
wrapper
around
for
now
just
name
inversion,
but
it
could
be
arbitrary,
like
I
don't
know,
whatever
some
some
other
metadata.
That's
always
present
for
http
request
or
something
okay,
I
get
it.
D
Yeah-
and
I
think
I
think
in
general
people
are-
I
think
most
people
agree
that
you
know
this
is
probably
a
better
design
and
if
we
would
have
went
with
it
from
the
beginning,
it
would
be
pretty
like
uncontroversial,
like
I
guess,
if
we
hadn't
declared
things
as
as
stable.
I
guess
this
would
be
like
a
no-brainer
that
we
would
probably
switch
over
to
something
like
this,
but
I
think
trying
to
unravel
and
unpack
exactly
what
it
would
mean
to
make
this
change
and
how
he
can
do
this
in
a
way
that
will.
D
Not
be
inconvenient
or
breaking
is,
I
think,
the
problem,
but
yeah.
I
guess
we
will.
I
guess,
tbd.
I
think
there
was
a
lot
of
conversation
on
this
this
week.
Some
interest,
maybe
maybe
after
having
a
week
for
people
to
talk
things
out,
you
might
start
to
head
towards
a
resolution.
C
Yeah,
no,
it's
super
useful,
especially
if,
like
you're
attempting
to
query,
let's
say
you
want
to
query
your
like.
I
don't
know
your
your
active,
your
your
rails
spans.
You
would
know
like.
If
there's
metadata
specific
to
those
spams,
you
could
store
it
like
in
the
scope.
You
would
know
like.
Okay,
this
is
information
that
I
could
use
like,
and
it
would
help
you
like
scope,
your
queries
or
something
cool.
D
C
Right,
it's
almost
like
you
want
instrumentation
resource;
instead,
it's
calling
it
scope
or
something
I
don't
know,
and
it's
like
application
resource
and
instrumentation
yeah,
whatever
yeah.
D
So
we
left
like
two
or
three
minutes
at
the
end,
for
these
remaining
issues
they
were
really
just
kind
of
brought
up
very
quickly
is
air
still
on.
I
think
this
means
there's
some
continued
work
around
our
errors.
I
think
this
is
specifically:
we've
talked
about
errors
in
a
couple
of
contexts.
One
is
like
how
to
actually
record
them
on
a
fan.
I
think
that
is
not
what
we're
talking
about.
D
I
think
this
is
when,
when
there's
an
air
condition
like,
I
think
the
way
that
you
know
the
sdk
should
respond.
I
think,
in
general,
the
the
consensus
is
that
an
sdk
should
not
raise
an
exception
if
you're
using
an
sdk
should
not
raise
an
exception
that
your
application
would
not
otherwise
see,
but
I
still
think
that
people
this
leads
to
a
lot
of
problems
when
there
is
actually
an
error
condition
as
to
how
to
best
try
to
surface
information
to
a
user
and
handle
everything.
D
D
There
is
a
pr
that
basically
specifies
how
to
dump
otlp
in
json
format
to
a
file,
I
think,
which
is
to
call
call
review.
D
And
then
there
was
a
request
for
for
more
approvers
on
semantic
conventions
for
the
spec,
specifically
people
from
the
instrumentation
working
group
to
be
added
and
then
ted
was
discussing
how
we
can
be
more
public
about
current
spec
development.
So
all
the
people
who
are
attending
the
sigs
are
going
to
be
spec.
D
Sig
are
aware
of
what's
happening,
but
I
think
this
was
in
hopes
of
of
having
information
filtered
down
to
people
who
aren't
so
involved
in
the
project,
and
maybe
they'll
see
that
oh,
this
current
thing
is
happening
and
care
enough
to
show
up
and
want
to
contribute.
I
think
so.
D
Discussion
was
a
little
bit
about
blog
posts.
Website
updates
other
things
I
kind
of
left
because
the
meeting
was
running
over
so
I
assume
it
ended
soon
soon.
Thereafter,.
F
Last
week
it
was
a
short
one:
it
got
cut
early,
it
was
basically
just
people
from
the
open,
telemetry,
jazz
implementation
and
python
basically
came
in
they
prototyped.
F
The
http
convention
changes
around
like
linking
redirects
and
retries,
and
basically
they
said,
like
some
of
the
libraries
allow
it
some
of
them
don't,
and
so
they
were
pushing
for
the
language
to
be
moved
changed
from,
must
to
should
that
was
pretty
much
it
and
then
they
just
like
kind
of
cut.
It
short
that
day
so,
which
I
think
makes
sense,
because
I
don't
think
all
the
ruby
libraries
will
allow
us
to
implement
that
behavior.
F
So
I
don't
know
if
anybody's
like
has
free
time
to
actually
try
implementing
linking
together,
retry
attempts
in
some
of
the
http
libraries,
but
I
had
checked-
and
I
had
mentioned
that
to
them-
that
it
should
be
like
should
probably
be
should,
but
they
just
got
further
confirmation
from
other
languages.
So
I
think
that's
that
change
is
going
to
get
it
pushed
in
again,
nothing
too
exciting
or
interesting.
F
F
C
D
D
I
have
a
feeling
once
if
you
start
talking
about
that
it
could
go
long.
Is
there
anything
else
we
should
address
before
moving
there?
Are
there
any
pull
requests
or
issues
of
node.
A
Just
one
pull
request
that
I
had
submitted
recently
about
adding
a
configurable
trace,
metrics
reporter
it's
a
little
wordy
for
the
name
of
it,
wanted
to
get
some
feedback
on
that.
As
soon
as
somebody
had
a
chance,
but
essentially
being
able
to
inject
a
provider,
I
guess
like
a
factory
method
or
whatever
just
a
pr,
a
proc
to
the
configuration
object
and
then
it
would
use
that
to
inject
the
metrics
reporter
into
the
batchband
processor
and.
A
The
otlp
exporter
as
necessary,
so
just
some
feedback
on
that
would
be
great
when
you
get
a
chance
and
then
I
started
stone,
souping
a
rail
tie
since
there's
so
many
people
who
are
requesting
kind
of
like
just
like
automatic
setup,
whatever
build
just
kind
of
generated
a
plug-in,
and
I
don't
really
have
any
tests
around
it,
just
kind
of
a
a
test
that
runs
and
doesn't
explode
and
then
trying
to
figure
out
how
to
do
appraisals
in
a
meaningful
like
not
a
meaningful
way
but
manageable
across
the
different
versions.
A
Because
you
know,
once
you
go
into
a
major
upgrade
right,
the
rails
plug-in
generator.
It
generated
like
some
default
dummy
application,
but
it
has
all
the
settings
from
the
default
rails
app
and
I
think
we
want
to
try
to
pull
in
as
many
of
those
as
possible
to
try
to.
A
I
don't
know
how
the
instrumentations
all
get
installed
as
much
as
we
can,
but
then
that
also
means
like
incompatibilities
with,
like
different
versions
of
rails
right.
So
I
just
started
with
7-0
to
see
what
you
know
see
where
I,
where
I
could
go
from
there,
maybe
creating
different
versions
of
the
dummy
applications
and
then
having
the
appraiser
pick.
The
right
dummy
application
in
the
test
directory
might
be
enough,
but
but
then
generating
like
you
know,
some
other
release
that
comes
out
and
then
generating
another
dummy
application.
A
You
know,
I
don't
want
that
to
be
a
hassle
for
people
to
do
the
same
thing
and
then
because
right
now
I
just
I
I
I
perceive
it
to
be
a
little
bit
of
a
hassle.
F
Yeah,
the
one
I
did
was
doing
the
rails
testing
way
back
when
I
I
kind
of
did
it
additively
like
it
started
with
like
rack
controllers
and
as
we
added
further
tests
for
other
instrumentation,
it
kind
of
like
grew
and
in
the
test
case.
There's
like
it's
not
exactly
the
same
as
what
you're
doing,
but
like
it
basically
it'll.
Look
at
what
like
rails
version,
the
appraisal
pulls
in
and
it'll
like
stub
in
different
config,
so
that
it's
compatible
across
the
appraisals.
A
Yeah
I
was
wondering
if,
like
as
part
of
that,
build
process,
potentially
we
don't
have
to
iron
it
out
here,
because
I'm
gonna
experiment
with
a
couple
of
things.
I
was
wondering,
if
just
instead
of
committing
that
dummy
application
as
part
of
the
build
process
for
each
one
of
the
appraisals,
for
it
to
generate
a
new
dummy
application
every
time
and
then
load
it
instead
of
keeping
the
dummy
application
under
source.
A
I
know
that
might
be
a
little
bit
more
difficult
for
you
know
when
you
have
to
try
to
like
debug
something
or
when
you
try
to
run
the
test
on
your
own,
but
I
was
considering
that
other
than
that
it
was
just
going
to
be
like
I
would
do
just
the
basic
default
dummy
application
and
instead
of
doing
so,
I
see
what
you're
doing
here,
which
is
like
load,
specify
or
load
specific
configurations
for
each
one
of
those
it'd
be
just
a
standalone
rails.
App
that
didn't
have
any
conditional
logic
in
it.
A
Essentially,
the
bare
bones
a
minimum,
but
I
don't
know
where
to
go
for
the
comp
like
the
more
useful,
comprehensive
testing
from
there
other
than
the
fact
that
the
sdk
was
initialized.
F
A
F
Yeah
that
one's
tricky,
like
we've,
talked
about
that
internally,
like
doing
something
like
that
is
like
just
grabbing
like
some
app
in
the
company's
ci
pipeline
and
like
automating
it
so
that
we
like
inject
our
wrapper
gem
into
it
and
just
being
like
whenever
we
cut
a
new
release
or
like
if
we're
planning
to
do
a
release,
have
like
a
ci
step
that,
like
just
literally
like
hooks
into
someone
else's
ci
and
runs
it
against
like
a
real
application.
Instead
of
us,
like
you,
know,
crossing
our
fingers
right.
F
But
it
is
tricky
because,
like
you
want
to
test
multiple
versions
of
rails,
but
you
don't
also
want
to
commit,
like
you
know
how
many
thousands
of
lines
of
code
and
how
many
files
to
just
run
like
a
dummy
app
of
rails,
five,
two
and
then
six
six
one.
Six,
two
seven
right
like
it
becomes
weird.
A
A
F
That's
where
we
ended
up.
I
think
I
I
don't
want
to
like
misquote
him,
but
I
think
like
earlier
on
when
I
was
like
in
my
first
real
time
like
how
do
I
test
this,
and
I
think
I
like
pinged
raphael
like
bronco
on
that
right
and
like
he's
like
you
know,
I
think
he
something
like
you
don't
really
have
to
unless
you're
gonna,
like
boot,
up
a
whole
rails.
F
A
So
are
we
good
so
are
we
good
to
go,
then?
Then
it's
basically.
F
Yeah
for,
like
a
for
a
rail
tie
like
if
you
want
to
add
a
retail
rail
tie
that
does
all
the
configuration
I
wouldn't
block
on
a
test
like
a
missing
test
like
if
you
could
find
up
like
come
up
with
something
like
really
cool,
like
sweet,
I'm
more
interested
in
like
where
does
that
rail
tie
exist?
Is
it
part
of
the
rails
instrumentation,
or
is
it
it's
its
own
thing?.
A
F
Which,
I
think
is
like
probably
like
the
first
like
a
good
first
pass
at
this,
because
if
someone
wants
to
like
basically
what
this
is
like,
the
part
of
the
motivation
here
is
like
you're
answering
the
call
for,
like
the
note,
touch
configuration
right
yeah,
which
I
think
is
great
and
I
think,
if
you're
following
that
narrative
like,
if
people
want
to
modify
it,
they'll,
be
doing
it
through
environment
variables.
F
If
they
can't
touch
the
code
or
like
they
can
just
add
a
gem
and
they're
not
actually
like
touching
anything
else,
then
like
they
could
probably
add
an
environment.
Variable
like
there
has
to
be
like
a
limit
to
where,
like
people
like,
how
do
you
interact
with
this?
Otherwise,
so
I
think
like
in
my
mind,
it's
like
you're
doing
the
use
all
if
you
want
to
modify
any
of
the
instrumentation
configuration
options,
eric
added
support
for
environment
variables
there
so
like
they
can
do
that,
all
through
environment
variables.
F
You
can
pick
your
exporters,
your
propagators,
all
through
environment
variables.
You
can
turn
stuff
off,
but
use
use
all
gives
you
like
that
easy
to
use
default
behavior,
because
now
you
add
open,
telemetry,
api,
sdk
or
sdk,
and
then
you
add
your
rail
tie
and
then
you
pick
the
instrumentations
you
want
and
then
now
you
have
it
now.
If
you
want
to
modify
any
of
the
behavior
like
you're
effectively
like
open
sourcing
like
what
it
sounds
like
we've
both
done
internally.
F
It's
because
we've
just
made
our
own
real
ties
right,
and
this
is
exactly
what
they
do,
except
we've
jammed
in
the
configurations
into
our
our
internal
one
right.
So
because
we
know
what
we
want
for
the
company.
F
But
if
for
the
open
source
community,
it
makes
sense
to
just
be
like
here's
all
the
knobs
you
can
use,
but
here
I'll
get
like
the
opinionated
defaults
of
the
open
source
repo
and,
like,
I
think,
we've
done
a
pretty
good
job
of
like
setting
the
default
behavior
of
instrumentation
gems
to
be
like
conducive
to
like
not
spammy,
noisy,
expensive,
traces
right.
F
So
yeah
I'd
say
like
I,
I
wouldn't
have
like
a
fit.
If
there
was
no
test
for
the
rail
tie,
I
think
the
rail
tie
should
be
its
own
thing,
because
someone
pulls
in
rails
and
they
still
want
to
configure
their
own
stuff.
Having
the
sdk
configured
twice
would
be
confusing
precisely
whether
or
not
that
should
be
an
instrumentation.
A
F
F
A
So
so
what
one
one
mod
I
moved
to
was
using
use
all
mode,
but
not
installing
the
use.
All
gem,
because
there's
only
specific
gems
that
we
will
support
and
the
registries
auto
is-
is
auto,
registering
only
the
gems
that
it
can
find.
F
A
So
that
works
out
for
me-
and
I
think
that
what
we
wanted
to
steer
the
community
in
was
to
steer
them
into
using
use
all
and
then
disabling
what
they
don't
like
and
then
we'll
see
what
happens
from
there
like
we'll
get
feedback
from
people
about
what
they
don't
want.
But
we
can
omit,
I
can
omit,
they
use
all
gem,
the
instrumentation,
all
gem
as
a
dependency
and
for
the
purposes
of
the
test
suite,
I
can
add
it
as
a
development
dependency.
F
Well,
I
guess
what
I
was
saying:
it
was
backwards,
but
I've
already
changed
my
mind.
Like
yeah.
I
don't
think
the
rail
thai
gem
that
you're
working
on
should
include
any
instrumentation
dependencies.
It
should
only
depend
on.
B
F
The
sdk
right,
but
then
instrumentation
all,
could
depend
on
your
gem.
I
originally
was
saying,
maybe
not
that,
but
I
think
that
makes
sense.
E
F
A
F
So
if
you're
doing
instrumentation,
all
that's
or
I
don't
know
I'm
kind
of
going
back
and
forth,
it
really
depends
because,
if
you're
using
say
I'm
like
starting
from
scratch,
I'm
a
rails
developer.
I
want
to
play
with
open
telemetry.
I
haven't.
I
don't
have
like
the
background
to
curate
my
instrumentation.
Yet
I'm
just
like
gonna
throw.
A
If
you're
not
in
the
rails,
app,
you
wouldn't
use
the
rail
tie
and
you
have
to
use
those
two
gems
and
configure
it
yourself.
We
still
don't
have
a
solution
for
non-rails
applications
to
do
the
no
config
setup
because
of
the
interesting
loading
dynamics
that
we
run
into,
and
that's
the
only
step
that
I
think
we're
missing
and
the
only
reason
why
I
say
that
is
because
of
I
guess
I
the
only
concern
I
have
is
kind
of
like
the
boot
ordering.
A
A
D
Wood
yeah
is
the
point
of
this
rail
tying
yeah
he'll
clarify
for
me,
and
maybe
this
will
help
clarify
this
discussion.
A
little
bit
like
right
now,
kind
of
the
setup
for
for
rails.
App
would
be
you
know,
just
just
throw
some
configuration
and
then
and
config
initializer
and
setup
like
use.
D
Yeah
configure
your
your
sdk
and
use
all
yeah
the
rails
would
with
the
idea
with
this
rail
tie.
Extension
just
be
like
get
rid
of
that.
Just
include
the
rail
tie
gem
and
then
that
will.
A
That'll
do
the
bare
minimum
and
if
you
need
to
customize
it,
here's
all
the
environment
variables
that
you
can
use
to
customize
it
and
here's
all
the
options
that
you
can
give
to
those
environment
variables
to
customize.
It
there's
one
exception
to
that
which
is
the
metrics
reporter,
which
is
another
thing,
but
we
you
can
do
all
your
customizations
through
environment
variables
and
then
go
ahead
and
eric
please
well.
C
Realistically,
you
can't,
which
is
fine,
like
I
don't
think
we
can
expose
the
whole
world
via
environment
variable,
like
most
products,
still
can't
be
configured
via
there's
some
procs
that,
as
as
custom
as
a.
A
A
C
F
C
You
variable
right
right,
so
I'm
not
super
worried
about
making
everything.
I
I
think,
as
someone
who
I
date,
a
dog
had
this
feature
or
we
added
it
because
dinah
trace
had
it,
and
so
we
had
it
access
and
the
issue
was
people
wanted
to
do
both
they
sort
of
wanted
the
magic,
so
devops,
folks
or
sis
admins
would
be
like
cool
here's,
your
awesome
out
of
the
box
experience,
but
as
devs
you
don't
have
to
ever
touch
and
then
a
week
or
a
month
or
whatever
later,
some
dev
will
be
like.
C
I
need
this
custom
thing
so
I
want
to
have.
I
want
to
configure
it
twice.
Basically,
so
they
needed
to
have
that
ability
to
be
able
to
ensure
getting
back
to
like
the
original
thing
for
testing.
I
don't
think
we
need
to
test
the
whole
rip
like
we
can
assume
the
rail
tie
works
right
like
we're,
not
testing
that
rails
rail
ties
work.
We
want
to
make
sure
that
the
environment
variables
are
supported
from
the
rail
tie
and
then
also
like.
C
If
someone
reconfigures
it
later,
the
second
configuration
would
take
precedence
or
or
override
the
first
and,
realistically
speaking,
I
think
how
this
will
be
used,
given
the
where
this
interest
has
come
from,
which
is
like
aws
is
vendors
or
cloud
providers
are
going
to
offer
an
out-of-the-box
experience
to
their
users
or
maybe
as
part
of
the
k-8
operator,
which
is
where
a
lot
of
this
stuff
is
coming
from
and
they'll
just
you
know,
so
you
sign
up
you.
You
spin
up
your
stuff
on
aws
and
you'll.
C
Get
this
like
rail
tie,
sort
of
like
auto-injecting
your
stuff
for
you,
but
that's
not
your.
You
know.
You'll
probably
want
to
add
some
additional
a
couple,
little
additional
things
that,
hopefully
you
can
do
via
environment
variable,
but
it's
probable
that
you
eventually
won't
yeah.
So
I
think
it
needs
to.
A
Things
like
okay,
absolutely
I
don't
mean
to
imply
that
it's
like
autumn
the
magic
happens
in
environment
variables
as
much
as
that
is
like
steer
people
towards
try
not
to
touch
it
as
much
as
you
can
avoid
it,
and
you
know,
because
real-time
support
configuration
options
right
we
can
expose
a
like.
You
know
one
small
step.
I've
got
a
configuration.
A
A
So
we
could
do
things
like
custom
error,
handling
and
so
on
and
so
forth
right,
so
those
things
will
be
made
available,
but
I'm
I
want
to
treat
that
as
a
kind
of
like
a
stone
soup
advent
adventure
where
it's
kind
of
like
we
add
those
features,
as
people
will
identify
that
they
need
them
and
they
can
open
pull
requests
to
to
make
it
accessible
to
others.
A
C
I
get
it
yeah.
All
I
was
saying
is
I
don't
think
you
need
to
worry
about
testing
the
full
life
cycle
of
like
whether
the
rail
tie
work
like
we
could
we
just
can
assume
the
rail
tie
will
work,
that's
rails,
behavior,
that's
not
open,
telemetry
behavior
that
we're
testing.
All
we
need
to
test
is
like
a
couple
side.
Effects
of
the
relative
which
is
like
did
it
create,
did
the
instrumentation
get
injected
and
then
ideally
like?
C
I
do
think
it's
a
super
ugly
experience
to
like
configure
twice
like
that
feels
completely
wrong
to
me,
but
I
think
people
will
try
to
do
it.
So
I'm
not
yeah.
C
It's
not
that
big
a
deal
like
but
yeah,
whether
we
should
do
that
or
whether
we
should
try
to
more
robustly
support
double
configure,
initializing
configuration
which
feels
wrong.
But
I
think
people
will
look
to
do
maybe
because
of
the
environment
they've
been
provided
by
a
cloud
provider
or
vendor
who
like
hands
them
the
thing
but
yeah.
So
all
I
was
saying
is:
don't
I
would
say,
don't
worry
about
doing
crazy
tests,
just
maybe
try
to
test
one
or
two
side
effects.
C
Oh
also
for
the
metric
supporter,
not
to
think
that's
useful
to
have
it
came
up
with
the
zipkin
stuff.
We
had
a
small
pr
where
the
person
was
like.
C
I
would
say,
let's
try
not
to
worry
about
like
adding
a
metrics
reporter
to
like
zip,
again
and
yeager
just
because
it
just
don't
slow
us
down
and
but
yeah
it
does
seem
like
there's
a
general
need
to
have
like
more
arbitrary,
as
you
guys
have
talked
about
in
the
past,
so
I've
been
behind
because
of
time
off,
and
I
was
in
a
workshop
and
moving
and
stuff.
So
I
owe
review
I'll
try
to
review
those.
The
metrics
report
I'll
try
to
give
a
review
too
and.
A
Does
that,
if
it
just
feels
so
verbose
is
all
I'm
just
like,
as
I
have
go
lying
people
telling
me,
I
should
name
my
variables
I
or
whatever.
F
F
A
C
D
D
It
sounded
like
we
wanted
to.
We
were
trying
to
think
about
the
ones
yeah.
Let
me
back
it
up.
I
think
we
have
no
problems
moving
more
than
one
at
a
time.
I
think
the
problem
is
like
figuring
out
how
to
best
move
them
and
dealing
with
like
changes
that
may
happen
in
the
process
of
of
the
moving.
D
So
I
think
the
the
least
suggestion
was
to
maybe
move
over.
D
I
think
there
was
like
two
two
propagators,
maybe
like
b3
and
ot,
trace
propagators,
which
are
like
pretty
stable,
probably
not
going
to
change
and
then
figure
out
what
needs
to
be
done
to
to
move
those
over
and
then
kind
of
figure
out
what
the
best
plan
would
be
to
port
all
the
things
that
we
know
that
we
want
to
afford.
D
It's
like
we
could
come
up
with
a
plan,
that's
so
great
where
we
could
just
decide
that
you
know
what
we
could
actually
just
wipe,
contrib
clean
again
and
just
pull
everything
over
or.
D
A
E
C
A
Only
thing
that
I
was
gonna
suggest
was
for
like
preserving
history
and
whatnot
was
to
move
all
of
the
files
into
a
contrib
directory
in
everything
that
we
were
targeting
to
move
to
the
contributor
move,
all
those
into
a
subdirectory
called
contrib
in
the
hotel,
ruby
main
project,
and
then
we
can
use,
give
get
filter
branch
and
then
it
would
filter
down
that
one
contrib
directory
and
make
that
the
top
level
directory,
because
that'll
preserve
the
history.
The
only
thing
is
like
the
gpg
signing
and
all
that
stuff.
A
I've
never
seen
that
work
with
it,
so
I'll
be
a
little
bit
annoying
and
then
one
person
is
going
to
be
going
to
have
like
the
honor
of
their
contribution
graph
being
like
the
darkest
forest
green
they've
ever
seen,
because
every
single
commit
will
be
attributed
to
them
and
that
one
move
and
they
can.
You
know
they
change
the
upstream.
That
was
the
only
thing
that
I
was
suggesting
lots
of
things
that
are
going
to
go
wrong
there,
which
is
like
trying
to
make
actions,
work
and
releases
and
all
the
toys.
A
You
know
that
will
be
fun,
but
a
lot
of
that
work
would
happen
in
the
main
or
evo.
First,
I
guess.
A
F
I
I'm
like
it
would
suck
to
give
up
on
the
pr's
or
not
give
up
and
like
but
like
at
some
point
like,
like.
I
don't
think
we'll
be
able
to
do
it
all
perfectly
like
I
I
don't
know,
I
don't
know
if
I'm
just
being
super
defeatist,
but
it's
like
some
things
are
just
gonna
be
a
bit
manual.
I
love
it,
but
like.
F
C
We
can
also
run
both
so
like
if
we
do,
even
if
we
pick
one
like
it,
doesn't
have
to
be
all
or
nothing.
We
can
keep
the
stuff
in
main
while
we're
doing
releases
and
then
like.
We
can
fork
everything
over
not
update
the
releases
and
then
like
update
one
thing
in
the
release
to
point
to
a
contrib.
You
know.
A
Something
like
that
because,
because
it
would,
it
would
mean
updating,
essentially
the
pr's
target,
instead
of
the
pr
targeting
the
main
repository
it
targets,
the
other
one,
and
since
the
the
history
is
pretty
much
the
same,
with
the
exception
of
the
deletions,
it
should
line
up
pretty
okay.
C
I'm
not
sure
there's
a
few
like
act,
you
know
like
manticore
is
one
that
rd
kafka.
Grpc
will
probably
die
in
darkness,
nothing
personally
and
true,
but
we
don't
have
it's
not
that
great.
C
You
know
it's
not
like
a
hundred
open
things,
there's
a
few
realistically
and
then,
like
you,
know
whatever,
if
like
there's
one
or
two
that
are
so
old
that,
like
those
aren't
getting
done,
if
we're
being
honest
with
ourselves,
like,
I
don't
know-
or
it's
just
not
the
end
of
the
world,
to
update
a
couple
of
these
things
manually
like
robert
wrist's
name
anyway,
for
for
actual,
like
scheduling
purposes
this
week,
I'm
like
a
little
backed
up.
I
know
I'm
thank
you
guys,
for
you
know
suggesting
me
as
a
maintainer.
C
So
I
probably
like
can't
do
this
stuff
this
week,
but
like
next
week,
I'd
like
to
start
to
focus
on
this
I'll.
Try
to
pick
up
some
of
this
work.
I
guess
but
yeah,
I'm
happy
to
do
the
manual
work
or
whatever,
just
probably
not
for
the
next
couple
days
or
this
week,
because
I'm
like
a
little
backed
up
so.
F
I
I'm
forward
I'm
actually
willing
to
like
take
a
crack
at
that
this
week
or
on
the
weekend,
or
something
like
that
just
to
see
if
it
even
makes
sense
like
if
it
doesn't
work
out,
we
can
always
just
like
purge
contrib
right
like
there's
nothing
in
there
nobody's
depending
on
it
so
like
I
can
just
try
and
see
if
it
like.
Oh
no,
this
is
actually
a
tangled
mess
or
oh
no.
This
is
working
fine,
so
I'll
I'll.
F
I
can
commit
to
like
try
attempting
to
see
if
it's
as
easy,
as
I
hope
it
is
if
everybody
else
is
willing
to
thumbs
up
it.
A
A
D
Good
plan,
sorry,
were
you
saying
something
eric
no
yeah,
I
was
gonna
say
I
think
it
sounds
like
a
good
plan.
I
think,
on
the
question
about
like
open
and
kind
of
stalish
prs.
I
feel
like
this
is
like
a
good
opportunity
to
either
like
close
or
ask
the
people
to
move
them
if,
if
they
need
to
move
so
like,
I
don't
it's
probably
not
the
end
of
the
world,
things
that,
like
aren't
super
stale
that
we
do
want
to
get
in.
F
Yeah,
that's.
I
agree
like
some
of
that
stuff's
pretty
old.
We
can
probably
heads
up
the
old
ones
and
then
the
newer
stuff
we
can
try
to-
or
we
can
just
like,
try
to
get
in
asap
so
that,
like
this,
there's
like
that
list,
like
there's
19
things
there,
we
could
probably
prune
it
down
pretty
aggressively
before
the
big
switch.
D
Yeah-
and
I
think
it's
like-
I
guess
just
just
a
good
time
to
to
circle
back
on
some
of
these
things-
and
you
know,
groom,
groom
what's
currently
here
and
get
rid
of
stuff.
That's
never
going
to
go
anywhere.
D
Maybe
some
experimentation
will
will
take
place
this
work
or
this
week,
but
maybe
the
the
real
migration
could
start
to
take
place
in
earnest,
maybe
next
week,
depending
on
what
we
find
and
depending
on
what
schedules,
kind
of
look
like.
F
F
As
I
push
it
up,
there
isn't
much
right
now,
it's
just
like
the
initial
plumbing
of
like
upgrading
the
meter
provider,
meters
and
instruments
in
the
same
way
that
we
did
with
like
tracer
and
tracer
provider,
I'm
going
to
try
to
do
like
a
straight
shot
from
like
creating
a
tracer
or
a
meter
provider
meter
and
then
like
a
simple
counter
instrument
and
then
have
it
going
to
a
metric
reader
and
a
console
exporter.
F
I'm
going
to
try
to
like
do
kind
of
like
a
tracer
bullet
there
and
then
once
that's
up
I'll,
probably
won't
be
right
away,
but
by
hopefully
next
week
I
can
solicit
feedback
from
anybody
who's
interested
on
that,
but
I
do
mean
that
it
is
like
reading
the
sdk
spec
as
a
as
a
slog,
but
the
more
eyes
the
better.
I
don't
know
if
anybody's
interested
again.
C
Definitely
interested
just
probably
next
week
I
can't
just
like,
as
you
know,
it's
my
co-worker
I'm
behind
on
some
things
but
yeah.
I
think
it's
awesome
and
I'd
like
to
I
feel
like
if
I
don't
pay
attention,
I'm
going
to
look
up
one
day
and
have
no
idea
what
these
10
word
functions
mean
so
try
to
try
to
give
it
a
look.
I
think
that's
the
right
approach,
broadly
speaking,.
D
Yeah,
I'm
also
I'm
also
on
that
same
boat.
So
on
that
note,
like
do
you
plan
to
is
this
whip
pr
gonna
turn
into
like
a
full
metrics
sdk
implementation
or
would
be
kind
of
like
a
little
bit
incremental.
F
As
incremental
as
I
can
so
that
the
tracer
bullet,
like
should
establish
a
structure
of
like
how
the
pieces
fit
together
and
then
the
pieces
like
once
that
structure
is
established,
then
it'll
be
adding
like
the
different
types
of
metric
readers,
the
different
types
of
exporters,
different
instruments,
things
like
that,
so
it
should
be
more
piecemeal,
but
like
this
first
one,
I
think
of
all
the
prs
will
probably
be
the
largest.
The
the
metrics
api.
One
that
got
merged
is
not
very
long.
F
It's
worth
looking
at,
it's
not
overly
interesting,
but
it
just
shows
like
the
the
api
structure.
This
one
is
going
to
probably
fill
in
some
gaps
if
anything
was
missing
from
the
api
upgrading.
D
Yeah,
I
think
that
makes
sense
like
I
was
mentally
going
to
the
exercise
of
of
how
I
would
break
this
down.
If,
if
I
were
implementing
the
sdk
a
long
time
ago,
and
my
thoughts
were
like
kind
of
there
are
like
a
bunch
of
components,
you
need
to
get
in
place
and
then
you
would
wire
up
like
a
synchronous
instrument
like
a
counter,
make
sure
that
that
stuff
kind
of
made
sense
and
then
maybe
you
could
do
the
asynchronous
version
and
then
it
seems
like
you
will
have
most
of
the
stuff
there.
D
C
One
thing
I'll
kind
of
note
is,
I
don't
think
there
exists
an
implementation
of
some
of
the
histogram
like
algorithm,
like
the
variable
bucket
histogram
thing,
I
forget,
what's
even
called
an
open
telemetry,
it's
kind
of
like
a
invention
of
open,
telemetry
and
matt
like
your
co-worker
josh.
So
when
we
get
to
that
point,
it
might
be
good
to
have
like
josh
review
the
if
he
could
maybe
take
a
look
at
our
work.
D
Yeah,
I
think
it
makes
sense
for
us
to
come
up
with
a
way
to
collectively
understand
I
think
it's
the
exponential
histogram,
so
that
yeah,
I
think
I
think
we
will
all
be
better
off
if
we
have
a
better
understanding
of
that.
So
when
we
get
to
that
point,
let
me
know
and
we'll
we'll
figure
something
out
and
yeah.
D
I
I
expect
these
metrics
prs,
or
at
least
this
initial
one
to
be
something
I
don't
know
again
that
all
of
us
would
be
slightly
better
off
if
we
had
some
degree
of
understanding
so
like
I
don't
know,
I
think
it
would
be
fair
game
or
maybe
not
a
bad
idea,
or
at
least
let
me
just
throw
this
off
out
there.
That
might
be
worthwhile
to
kind
of
do
like
some,
some
walk-throughs
at
these
sig
readings
and
just
kind
of
get
yeah
just
get
a
little
bit
of
a.
D
Of
a
walk
through
of
of
what
we're,
adding
how
it's
structured,
how
it
works.
F
Yeah
I
can,
I
can
do
that
the
next
one
I
can
even
backtrack
a
bit.
I
can
go
through
the
api
apr
next
meeting
and
see
how
long
that
takes
and
then,
if
anybody's,
like
feeling
proactive
like
you
can
go
through
that
on
your
own
time
and
like
even
like
this
whip
right
now,
where
it
is
it's
at
a
very,
very,
very
simple
state,
but
it
is
like
a
first
step
so
like
this
one,
you
could
review
in
isolation
just
to
see
how
it's
interacting
with
the
api
it's
fairly
fairly
straightforward.
F
D
I
well,
I
think
that
will
help
everybody.
I
think
it'll
also
kind
of
help
us
get
you.
You
know
meaningful
reviews
as
well.
So
let's
try
to
do
that
I'll,
try
to
keep
specs
sig
as
short
as
possible
and
not
retell.
All
of
the
bike
sheds
in
in
full
detail.