►
From YouTube: 2022-04-27 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
Good
people
are
showing
up
for
a
second,
I
thought.
Maybe
I
was
in
the
wrong
zoom.
B
A
Been
well
I've
been
kind
of
preoccupied
with
one
of
the
other
cigs
that
I'm
I'm
helping
out,
which
is
the
client
instrumentation
room
is
trying
to
get
over
the
finish
line
and
much
like
we've
run.
Afoul
links
that
group
has
run
afoul
resources
yeah
when
you're
doing
like
client
observability
the
like
overwriting
resource.
The
overriding
identifier
for
all
the
telemetry
being
emitted
by
service
is
a
session
id
like
you.
A
You
might
also
have
like
a
device
id
or
some
other
thing,
but
generally
speaking,
you
are
when
you're
like
trying
to
do
comparative
work
or
something
it's
really
sessions,
and
the
problem
is
that
resources
are
immutable
because
to
some
extent,
on
the
server
side,
the
concept
of
a
session
matches
one-to-one
with
a
service
instance
being
started
and
then
later
terminated,
so
that
all
made
like
perfect
sense.
A
The
problem
is
that
with
clients,
long-running
clients
often
have
like
idle
periods,
whether
their
browser
or
mobile
or
desktop
they'll
have
idle
periods
or
they'll
get
like
put
to
sleep
and
later
they
reawaken,
and
so
they
haven't
restarted.
They
haven't
reinitialized,
but
you
want
to
change
the
identifier
right
like
you
want
to
say.
Okay,
there's
a
new
session
happening
now,
because
this
bunch
of
data
that
the
user's
doing
is
shouldn't
be
associated
with
what
they
were
doing
yesterday,
the
last
time
they
used
the
app.
A
A
Well,
that's
the
the
other
option
we've
been
trying
to
look
at
is
like.
If
it's
not
a
resource,
then
what
the
hell
is
it
and
the
only
problem
with
not
making
it
a
resources
that
leads
to
stapling
the
session
id
over
and
over
again
on
a
bunch
of
other
objects
like
you
could
also
implement
it
as
just
like
an
attribute
on
everything.
A
So
every
single
thing
you
omit
every
log.
Every
metric
every
span
has
the
session
id
attribute,
but
that
runs
a
foul
of
the
the
limited
resources
available
in
browsers,
browsers,
in
particular,
have
very
limited
resources
protocol
you
know
like
wire
transfer,
the
speeds
are
very
low.
You
want
that
all
to
be
very
efficient,
but
yeah.
You.
A
A
single
threaded,
cpu
issue,
where
using
compression
to
get
rid
of
that
duplication,
also
takes
cpu
resources
that
and
to
put
it
another
way,
all
doing
it.
That
way
starts
to
incur
enough
overhead.
A
That
open
telemetry
looks
like
like
a
step
back
from
existing
client
instrumentation
systems,
whereas
like
making
it
a
resource,
is
kind
of
like
the
way
it's
sort
of
always
been
done
in
client
instrumentation,
which
is
you
know,
every
batch
of
data
just
has
like
a
session
id
attached
to
the
batch
of
data,
and
so,
if
you
look
at
the
resources,
just
the
envelope
that
this
batch
of
data
has,
it
seems
like
like
the
right
right
place
to
put,
it
is.
A
To
making
to
making
resources
updatable
so
so
that's
that's
what
we're
trying
to
to
hash
out
right
now,
I
think
we'll
get
there
part
part
of
the
issue
is
that
most
of
the
people
working
on
the
spec,
don't
have
a
client
background,
yeah,
and
so
there's
like
just
some
like
miscommunication
happening,
because
if
you're
a
back-end
developer,
something
like
a
session
id
really
sounds
like
transaction
level.
A
Context
like
this
would
be
a
trace
attribute
because,
like
on
the
back
end,
you're
a
service,
that's
handling
a
bunch
of
different
transactions
with
a
bunch
of
different
sessions.
So
so
there's
this
kind
of
like
an
impedance
mismatch
on
top
of
everything
else.
So
anyways,
it's!
I
I
maybe
pulling
it
back
around
to
this
sig
to
kind
of
help.
With
this
I
I
have
a
proposal
which
I
can
add
to
our
notes.
A
Also.
I
think
there
is
a
request
from
riley
to
start
moving
moving
our
notes
back
to
the
the
spec
notebook
instead
of
the
instrumentation
notebook,
where
we've
been
having
it
I'll,
just
put
in
the
instrumentation
notebook
for
now
and
I'll
copy
it
over
there
just
to
over
there
later,
just
to
save
save
time.
B
But
yeah
last
week
we
had
a
chat
to
riley
just
fleshing
out
with
him
kind
of
like
what
do
we
need
to
do
to
who
do
we
need
to
talk
to
kind
of
what
confirmation
we
need?
How
and
how
do
we
approach?
The
problem
of
you
know
getting
everyone
on
board
for
it
being
stable
for
v1,
and
we
just
kind
of
you
had
an
issue
open
dennis
regarding
like
agreeing
on
the
scope
of
v1,
and
I
think
tigran
was
saying
we
should
reach
out
to
maintainers
and
just
go.
B
A
A
Do
we
have
like
all
the
relevant
pr's
closed
out
yet
or
is
that
stuff
luke
miller
was
working
on?
Is
that
still
still
out
there
yeah?
It's.
D
Yeah,
that's
correct
and,
like
I'm,
actually
I'm
not
so
optimistic
about
the
the
overall
thing
that
we
are
doing
with
tc
but
in
particular
with
tigran.
D
So
like
the
way
how
I
read
his
command
basically
means
that
we
still
need
to
reach
out
to
you
know
all
the
maintainers.
D
That's
basically,
he
said
explicitly
said
that
you
can
ask
maintainer
from
each
language
to
review
and
approve
the
pr
right,
and
this
can
be
kind
of
hard
right,
especially
like
the
something
that's
pointed
out
by
james.
That
java
folks
have
some.
You
know
something
to
add
to
the
scope
and
I'm
pretty
much
sure
that
everyone
will
be
will
be
having
something
that
they
will.
They
might
want
to
add
so
like
the
overall
thing
is
it's
still.
It's
still
not
so
clear
for
me,
and
I
didn't
like.
A
D
Done
much
kind
of
during
this
week.
Just
because
of
this
reason,
because
I
don't
really
clearly
see
like
how
or
who
who
can
support
us.
A
Yeah,
well,
I
I
think
saying
every
maintainer
is
excessive.
Can
we
just
like
clarify
that
that,
like
three
three
different
maintainer
groups
would
be
would
be
enough.
D
Yeah,
so
that
this
was
my
proposal
actually
to
reach
out
to
just
three
groups
of
people
like
a
java,
formatted
python,
maintainers,
yeah
and
like
if
we
can
at
least
figure
out
that
these
three
groups
of
people
are
fine
with
going
forward,
then
we
can
just
you
know,
announce
this
and
ask
other
people
like.
D
I
would
say
just
once,
maybe
during
my
dinners
meeting
or
something,
but
it
looks
like
there's
nothing,
I'm
something
that's
tigran
wants
to
go
with
so
here
he
is
explicitly
asking
you
know
to
to
to
ask
for
review
from
all
my
dinners
from
each
language.
D
Yeah,
so
I
can
just
maybe
share
just
just
to
show
what
I'm
referring
to
so
here
yeah.
So,
basically
that
that's
the
that's
the
response-
and
this
is
the
comment.
D
Not
sure,
maybe
I
just
tell.
D
Yeah,
so
that's
the
first
part,
and
the
second
part
that
I
was
also
thinking
about
this
during
this
week
and
also
something
that
we
are
like.
We
have
some
discussions
in
microsoft
about
so
we
have.
This
version
schema
right.
So
it's
it's
already.
It's
already
there,
it's
already
something
that
we
have
mentioned
in
specification.
D
D
I
would
say
parallel
efforts,
saying
that
even
for
non-stable
or
like
a
experimental
spending
conventions
for
http
for
messaging
whatnot,
we
can
add
this
schema
version,
meaning
that
even
still
like
experimental,
we
can.
We
can
say
this
is
kind
of
0.9
right,
yeah
and
every
time
we
want
to
change
something
we
just
need
to.
You
know
increase
this
version
based
on
the
on
the
proposal
that
we
have
here
so
next
change.
D
It
will
be
0.10,
then
0.11,
and
we
can
go
very
far
with
this
right
yeah,
but
what
the
value
which
it
can
bring,
for
example,
on
our
side
when
we're
building
some
backend
right
to
to
consume
telemetry,
we
can
say
okay,
so
even
if
it's
like
experimental,
but
it
has
some
predefined
version
we
can
be.
I
would
say
it
can
be:
this
version
can
be
stable
for
us,
meaning
that
we
support
all
the
clients
for
this
specific
version.
D
So
this
is
a
specific
version
of
semantic
conventions
and
then
it
will
be
basically
choice
of
our
clients.
That's
you
know
they
can
just
explicitly
send
data
with
with
this
version,
so
it
can
be
kind
of
trade-off
between
you
know,
pushing
pushing
hard
to
make
everything
stable,
and
you
know
on
the
the
other
side
it
can
be.
Just
everything
is
unstable.
Everything
is
experimental,
it
can
be
changing
every
day,
so
this
basically
I
see
this
as
a
trade-off.
D
A
A
B
A
You
could
get
that
and
then
you
know
as
like
a
working
group.
We
can
just
try
to
make
sure
we
aren't
introducing
any
more
breaking
changes.
We
just
haven't
said
in
the
spec,
yet
that
we
promise
to
never
do
that
and
we
want
to
get
that
down
soon,
but
we
can.
Actually,
you
know
if
we
feel
like
we
have
hashed
out
enough
of
the
issues
that
it
is
worth
going
into
instrumentation
now
and
starting
to
to
update
it.
A
Then
I
would
say:
that's
that's
a
great
idea,
that's
a
great
way
to
to
get
around
some
of
this
stuff.
I
really
think
we're
close
to
getting
it
stable.
So
hopefully
that
might
just
happen
while
we're
in
the
process
of
updating
instrumentation,
because
that
that's
going
to
take
some
time
so
maybe
it'll
all
just
just
be
a
non-issue
by
the
time
we're
done,
but
I
think
yeah.
My
question
would
be:
do
we
want
to
resolve?
A
Are
there
any
issues
outstanding,
such
as
like
required
versus
optional,
that
we
we
would
feel
like
we
need
to
resolve
before
we
go
out
there
and
and
update
all
the
instrumentation.
D
Oh
yeah,
I
believe,
like
this.
This
can
be
done
parallel.
Actually
so
when
it
comes
to
optional
between
or
like
a
versus
required,
all
this
stuff
is
is
currently
being
investigated
by
the
mill
and
looks
like
the
involvement
is
great
there.
So
I
really
hope
that
it
will.
It
can
be
figured
out
like
a
really
soon
yeah,
but
no
matter
what
I
mean.
D
Currently,
we
just
have
a
status
as
experimental
for
http
conventions
but
like
if,
in
addition
to
this
experimental
status,
we
can
also
add
some
predefined
kind
of
number
version,
like
a
really
specific
version,
and
we
can,
you
know,
make
the
process
in
a
way
that
every
time
we
are
changing,
something
that
we
just
need
to
change
the
version
as
well.
So
that
can
be
done.
I
can
I
I
mean
it
can
help
a
lot
right,
even
if
it
break
and
change
it
still
can
be
communicated
right.
D
So
we
can
say
that,
like
a
civil
still
says,
experimental,
every
single
change
can
be
breaking
right.
So
but
at
least
for
some
specific
version
or
like
a
we
can
we
can
be
sure
that
we
can
support
it
and
it
will
will
never
be
changed
right
right
if
client
sends
us
telemetry
with
this
specific
version,
that's
enough.
A
Yeah,
so
we
try
to
cut
a
release
of
the
spec
monthly,
so
there
should
be
a
new
spec
release
in
like
a
week
if
that
version
of
the
spec
is
contains.
What
you
think
is
like
essentially
stable
stuff
like
we
aren't
about
to
add
one
final
thing:
that's
gonna
tweak
it
all
then
yeah
we
could.
A
We
could
begin
the
effort
of
going
out
and
and
updating
all
the
instrumentation
to
say
that
it
it
commits
to
that
version
of
the
spec
and
try
to
clean
up
the
instrumentation
so
that
it
it
matches
what
we
think
that
stable
instrumentation
should
look
like,
so
that,
hopefully
we
do
it
once
and
when
things
become
declared
stable
that
doesn't
introduce
any
change
that
would
cause
us
to
have
to
like
go
back
and
update
them
all
all
over
again.
D
Yeah
makes
sense
like
and
when
you
say
like
we
can
start,
you
know
moving
all
the
all
the
implementations,
all
the
is
too
stable.
What
actually,
what
practical?
What
does
practically
practically
mean
so
like
what
is
the
process
yeah
communicate?
This
change.
A
Do
you
mean
like
declaring
things
stable?
What's
the
process
of
doing
that
or
what's
the
process
of
implementing
implementing
yeah?
Well
implementing
means?
We
we
organize
an
effort
to
go
into
all
the
instrumentation
libraries
in
all
the
contrib
repositories
that
are
related
to
http
and
make
a
pull
request.
A
That
updates
them
to
you
know
include
the
the
schema
version
and
everything
else
that
needs
to
get
changed
about
that
particular
one
to
make
it
match
what
we
want,
because
we
know
for
a
fact
that,
what's
implemented
out,
there
is
kind
of
mushy
and
and
doesn't
necessarily
match
the
thing
we
want,
especially
around
that
stuff.
In
that
issue,
that's
still
outstanding
around
like
what's
required,
you
know
or
preferred,
I
think,
we'll
definitely
have
to
change
instrumentation
to
to
match
what
we
prefer
and
it's
gonna
suck.
A
A
So
it's
not
feasible
to
write,
write
a
translator,
probably
for
these
things,
the
first
time
we
do
it,
which
is
why
I'm
kind
of
saying
like,
but
I
don't
want
to
kind
of
do
it
like
twice
in
a
row,
real
quick,
because
that
that
would
be
that
might
like
piss
off
some
some
end
users-
and
I
mean
hopefully
we
don't
break
stuff,
but
I
mean
if
we
change,
which
attributes
are
there
by
saying
like
getting
rid
of
like
a
url
attribute
in
favor
of
having
it
like
broken
apart,
or
something
like
that.
A
You
know
that
that'll
break
somebody.
I
kind
of
hope
that
for
the
most
part,
it's
not
breaking
people,
it's
just
like
adding
more
things
that
that
maybe
that
particular
library
didn't
emit.
But
that's
that
that's
kind
of
what
I
mean.
It's,
not
it's
not
useful
to
people
until
we
go
through
all
the
instrumentation,
actually
update
it
to
one
of
these
schema
versions.
A
Once
we've
done
that,
then
you
know
once
we've
done
that
and
then
once
the
end
user
community
has
upgraded
to
that
version,
then
you
will
have
data
coming
into
microsoft
and
everywhere
else
where
you
can
identify.
A
You
know
the
schema
associated
with
this
http
stuff
and
start
doing
things
on
your
user's
behalf.
If
that's
like
helpful
around
like
auto,
translating
that
stuff
or
whatever.
D
Yeah
exactly
it
makes
sense
and
like
and
the
another
idea
I
have
in
this
regard
as
well.
Is
that
probably
you
remember,
we
were
talking
about
some
like
a
automation
or
framework
which
can
help
us.
You
know
to
verify
all
the
existing
implementations
against
some
specific
version,
even
unstable.
B
D
A
You
know
a
couple:
people
have
pinged
me
for
various,
like
other
projects
like
michael
heberman,
who
I
think
is
over
at
aspect,
though,
and
anyways
I
feel
like
a
couple.
People
have
pinged
me
for,
like
other
reasons
that
aren't
what
we're
doing
that
would
involve,
I
think,
more,
like
debugging
hotel
reasons
that
would
kind
of
that
had
kind
of
like
the
same.
It
would
be
nice
if
we
had
a
schema,
validator
kind
of
sentiment,
so
there
might
be
like
a
couple
more
people.
We
could
rope
into
helping
us
like
build
such
a
thing.
A
I
I
don't
want
perfect
to
be
the
enemy
of
good
enough,
though
you
know
I.
I
think
it
would
be
nice
if
we
weren't
in
a
rush,
and
we
could
like
build
the
test
harnesses
that
we
want
and
like
lift
everything
on
to
that
in,
like
the
same
path
that
we're
we're
updating
everything
but
honestly
like
if
that's
going
to
like
just
slow
the
effort
down
by
just
like
putting
one
more
roadblock
between
us
and
getting
the
instrumentation
out.
A
I
would
say
it
and
you
know,
update
the
instrumentation
and
then
later
come
back
and
update
the
test
harnesses
for
all
of
this
stuff
to
to
get
it
lifted
onto
something
that
would
make
it
easier
to
maintain
in
the
future.
Make
it
easier
for
us
to
have
some
central
somewhere.
A
That
can
kind
of
like
tell
us
when
something's
out
of
whack
or
at
least
be
able
to
go,
look
at
some
place
and
see
what
version
every
all
the
instrumentation
we're
providing
and
like
what
version
it's
on
or
is
it
like
like
broken?
A
D
B
They
would
they
would
be
nice.
I
just
I'm
kind
of
unclear
on
how
a
test
harness
would
be
made
like
like
how
how
do
we
do
it,
because
things
like
all
the
languages
have
different
instrumentations,
they're,
instrumenting,
all
kinds
of
different
things,
and
it's
like
yeah
they'll
all
have
slightly
different
implementations,
and
it's
like
how
do
you
verify
that
in
like
a
kind
of
unified
way.
A
A
D
A
Sure,
and
so
you
you
have
a
test
harness
where
it
spins
up
that
collector
and
then
in
your
test,
it
spins
up
a
real
exporter
and
like
like
really
uses
the
library
and
then
that
that
validator
plugin
has
some
api.
It
exposes
that
lets.
You
verify,
you
know
check,
you
know
what
what
came.
A
What
the
validator
said
like
did
it
the
validator
said?
No,
it
it
failed,
because
you
correctly
sent
a
different
version
of
the
schema
than
you
thought
you
were
sending,
or
did
it
fail
because
you
you,
you
didn't
send
anything.
I
don't
know
if
it
could
be
that
complicated.
Maybe
it's
just
enough
for
it
to
say
like
this
thing
came
in
and
you
were
expecting
it
to
match
schema
version
blah,
so
I
ran
that
validator
and
it
did
not
match.
A
These
are
the
fields
that
didn't
match
and
test
fails
and
you
get
that
output
printed
somewhere
yeah
and
I
kind
of
like
the
idea
of
such
having
as
a
final
step
where
that
data
also
goes.
Besides
that
the
things
pipeline
like
release
pipeline
is
maybe
somewhere,
that's
a
little
more
like
a
dashboard.
A
I
don't
know,
that's
still
yet
more
infrastructure,
but
it
would
be
like
kind
of
nice
if
we
could
get
a
global
view
of
this
thing,
which
is
basically
we
kind
of
have
this
thing.
It's
called
the
registry,
but
the
registry
is
like,
like
stupid,
simple
implementation.
It's
just
reads
a
bunch
of
stuff
out
of
a
manifest
file,
and
you
know
it
has
like
a
pretty
simple
ui,
but
we
could
improve
how
that
registry
worked.
A
So
there
was
a
way
to
go.
Look
at
all
the
http
instrumentation
that's
available
and
like
what
version
of
the
schema
it's
on
and
if
one
of
them
has
like
failed
is
failing
its
tests,
then
that
thing
you
know
is
marked
red.
A
So
as
an
end
user,
you
can
be
like
not
that
one
and
as
general
instrumentation
maintainers,
we
have
a
central
place.
We
can
just
go,
look
and
see
if
there's
like
stuff
out
there
that
that
needs
to
get
updated
or
you
know,
is
broken
or
something
happened
to
it.
A
I
don't
think
I
don't
think
we
should
stop
for
these
things.
I
I
think
we
should
get
it
all
up
to
speed.
I
it's
easy
enough
to
write
non-fancy
unit
tests
that
verify
this
stuff,
because
in
every
language
we
have
an
alternative.
Sdk
implementation
usually
called
like
a
mock,
tracer
or
whatever
that
its
implementation
is
just.
A
You
know
it
just
stores
all
the
data
inside
of
it
in
some
way
that
it's
very
easy
for
a
unit
test
to
to
access
and
then
run
verifications
against,
like
the
spans
and
logs
and
stuff
that
something
produced.
So
so
as
part
of
going
through
this
like
we
should
be
able
to
use
an
existing
existing
test
tools.
A
So
I
think,
like
this
state
of
the
world,
is
very,
not
uniform
out
there
in
terms
of
maybe
what
kind
of
testing
these
things
already
have,
but
that's
what
we
should
do
as
a
first
pass
and
I
think
that's
that's
not
an
infinite
amount
of
work,
but
it
is
a
fair
amount
of
work
is
work
across
like
a
bunch
of
different
programming
languages,
so
just
just
figuring
out
how
we're
going
to
execute
that
part
of
it
is
going
to
be
a
little
difficult.
A
We
can
try
to
get
help
from
the
various
sigs,
but
I
don't
think
we
can
depend
on
the
maintainers
of
those
six
to
like
have
enough
of
their
free
time
that
they'll
be
able
to
to
do
a
lot
of
it
for
us,
but
maybe
there
are
sig
members
or
just
the
end.
User
community
would
be
interested
in
in
helping
us,
but
it's
probably
going
to
be
us
doing
a
good
job.
A
D
A
D
A
I
think
it'll
be
good
for
us
to
perform
this
exercise,
because
also
one
thing
we
might
learn
is
it's
like.
Even
though
we
updated
the
spec
we're
still
confused
about
what
the
spec
says,
we
should
be
doing
when
it
comes
to
actually
like
implementing
these
damn
things
you
know,
so
I
do
think
it's
like
a
good
test
run
to
see
if
updating
to
the
latest
version
of
the
spec
is
just
like
a
super
obvious,
straightforward
experience
with
these
with
these
libraries,
so
in
other
words,
we're
gonna
eat
our
own
dog
food.
C
A
C
Yeah,
it's
kind
of
getting
what's
what
is
good
enough
and
being
able
to
iterate
from
there
going
forward.
Yeah.
A
You
know
I
do
think
there
will
be
more
cycles
from
more
people
once
metrics
and
logging
are
kind
of
out
the
door.
I
don't
know
that
instrumentation
is
everyone's
favorite
thing,
though.
That's
that's
also
part
of
the
problem.
It's
like,
like
it's.
It's
not
cool
to
maintain
an
instrumentation
package
the
same
way.
It
is
to
maintain
that
the
sdk
so
a
lot
longer
term.
A
I
think
we
have
a
maintainership
issue
that
we
need
to
dig
into
of
like
who
who
responds
to
the
issues
in
prs
that
the
community
makes
against
all
these
various
contrib
packages,
because
in
some
languages
like
java,
there
are
like
active
like
instrumentation
maintainers,
who
are
just
like
on
top
of
everything
and
it's
awesome,
but
in
a
lot
of
languages.
A
There
are
basically
only
sdk
maintainers,
who
feel
like
managing
the
whole
universe
of
of
instrumentation
on
top
of
what
they're
currently
doing
is
is
more
than
what's
realistic
for
them,
and
it's
not
realistic
for
them
to
be
able
to
like
process
and
triage
and
respond
to
all
the
issues
that
that
come
in
there.
So
so
that's
another
long-term
thing
I
think
we
need
to
to
think
about
which
is
as
a
community.
How
do
we
supply
maintainership
to
these
things.
A
Yeah,
but
I
mean
I
for
any,
given
repo,
it's
not
very
much
work.
You
know
like
like
these
things
are
once
you've
done
the
work
of
getting
it
hooked
in
it's
like
pretty
much
done,
but
the
thing
that
happens
is
like
new
versions
of
the
thing.
A
So
I,
I
suspect,
that's
that's
where,
like
most
of
like
the
prs
and
issues
will
probably
come
from
the
the
rest,
come
from
like
configuration
requests
in
my
experience,
can
you
please
add
this
config
option
to
this
thing,
but
I
think
we
don't
want
to
be
doing
that.
Instead,
we
actually
want
to
wait
for
a
coherent
configuration
project
to
to
get
rolling
which
is
kind
of
on
our
radar
to
to
do.
B
So
what
is
our
next?
What
is
our
immediate
actions
right
now
for
the
stability
stuff,
just
kind
of
waiting
on
that
required
optional
pr,
reaching
out
to
maintainers
a
little
bit
I
reached
out
to
java
yeah
people?
What
what
else
can
we
be
doing
right
now,
starting.
A
A
A
That
say,
you
know
they
target
the
next
version
of
the
schema
that
is
going
to
match
the
next
spec
version,
which
is,
let
me
see
here,
it'll
probably
be
1.11.
A
A
You
know
from
our
various
organizations
to
do
this
stuff
reggie.
I
don't
know
what
the
the
hotel
team
has
on
their
plate.
I
imagine
they're
busy,
but
if,
if
they're
looking
for
a
way
to
put
a
bunch
of
like
quick,
wins
on
their
jira
board
and
look
like
they're
they're,
just
smacking
things
and
getting
a
lot
of
things
done,
this
would
be
some
some
low-hanging
fruit
to
to
make
that
look.
Look
good.
A
But
maybe
the
more
realistic
thing
is
is
like
yeah,
it's
like
with
everything
in
hotel
when
it
comes
to
like
trying
to
like
secure
resources
from
organizations.
There's
usually
like,
like
a
time
gap
between
when
we
like
ask
for
help
and
when
help
can
show
up
like
I
imagine,
the
hotel
team
at
lightstep
could
maybe
get
some
of
this
penciled
in
to
their
backlog
in
the
in
the
future.
A
A
You
know
they
could
help
us.
Certainly
they
could
help
us
like
reviewing
and
merging
the
peers.
So
that's
the
thing
to
think
about
yeah.
A
B
So
when
you
say
implementing,
you
mean
going
in
to
all
the
instrumentation
repos
and
aligning
it
as
much
as
possible
with
what
we
have
now
in
the
spec.
A
A
Just
say:
there's
a
new
spec,
that's
going
to
get
cut
yeah
and
one
that
get
cut
in
a
week.
So
if
there's
anything
in
this
in
the
in
like
head
of
specification,
you
know
what
I
mean.
That's
going
to
be
part
of
the
official
spec
release
that
comes
out
in
a
week.
That
represents
any
work
that
we
got
merged
over
the
past.
A
B
Yeah,
I
don't,
I
don't
think,
there's
anything
significant
for
acp
traders
convention
right
like
it's
just
we've
just
got
that
the
only
thing
we've
got
open
is
the
draft
pr
the
miller's
drop
here
for
the
required
best
optional
attribute
set.
So
what's
in
the
spec
right
now,
I
think
is
just
what
will
be
in
wonder:
11
yeah.
I
think
that
they've
been
turned
off
yeah.
A
B
A
And
you
know
it
might
not
be
a
whole
lot
of
stuff,
like
I'm
looking
at
a
go
right
now
and
I
just
see
like
I
see
a
client
which
might
have
some
http
stuff
in
it,
but
it
might
all
just
devolve
down
to
net
http
because
actually
in
go
like
the
whole
community
is
pretty
solid
on
the
default.
Http
implementation.
A
I
see
a
couple
of
things
that
look
like
http
url,
lib
url,
lib3
httpx.
I
see
a
bunch
of
things
that
ascribe
to
the
pokemon
naming
convention
where
there's
called
like
falcon
celery.
A
You
know
so
who
knows
what
those
things
do,
but
you
know
I
don't
think
it's
like
an
infinite
amount
of
work,
but
there's
probably
like
30
libraries
out
there
that
have
to
get
get
updated.
A
Yeah
yeah
might
be
fine,
might
be
at
minimum,
really
just
just
attaching
the
schema
version
making
sure
we
understand
how
to
how
to
indicate
that
and
that
that's
there.
A
That'll
have
to
happen
everywhere,
I'm
sure
or
maybe
not
java,
but
certainly
in
the
other
languages.
That'll
that'll
definitely
have
to
happen,
and
the
other
thing
I
would
really
look
at
is
retries
and
redirects
anything
that
that
manages
that
stuff.
We
want
to
make
sure
we're
adding
the
various
attributes
around
counting
and
stuff
that
we
added
and
then
the
last
thing
is
maybe
we've
changed.
A
B
Okay,
I'll
put
that
down
as
well.
Maybe
those
ones
that
aren't
in
the
spec
can
be
raised
is
like
draw
fpr's.
A
B
A
Maybe
we
can
work
on
a
document
as
just
when
you
start
doing
this,
just
like,
like
a
checklist
right
like
we
kind
of
know,
all
the
things
to
like
look
for
to
make
this
particular
update
of
everything.
So
it
might
be
helpful,
especially
if
we're
gonna
farm
this
work
out
to
people
to
just
have
a
dock.
That's
like
a
checklist
of
all
the
things
to
kind
of
look
at
where
we
know
like.
Maybe
a
spec
change
happened
that
we
added.
B
A
Yeah,
but
you
can
see
why,
having
that
schema,
validator
would
like
make
make
it
really
easy
for,
like
a
novice
who
is
like
totally
unfamiliar
with
any
of
the
things
that
we
just
changed
to
just
like
bump
the
validator
to
the
next
version,
and
then
it
just
spits
out
all
the
things
that's
wrong,
and
then
you
just
change
the
instrumentation
to
to
fix
those
things
and
like
carry
on
so
that
that's
gonna
be
yeah
right.
That's
really
gonna
make
it
easier
to
maintain
these
things
in
the
future.
I
think,
would.
B
Yeah,
I
think
I
mean
initially
when
you're
talking
about
the
validator.
I
was
kind
of
scared
because
it
seemed
like
the
scope
was
very
very
large,
but
I
think
if
we
initially,
if
we
initially
keep
it
to
like,
let's
just
verify,
http
client
and
server
bingo
man,
then
it's
much
more
achievable.
Isn't
it
yeah.
A
A
You
know
what
it
what
it
thought
happened,
so
it
won't
be
like
terrible,
but
it's
enough
infrastructure
that,
like
I
don't
I
don't
want
to
wait
if
we've
got
people
who
are
ready
to
just
dive
into
these
repos
and
update
them
yeah.
But
in
the
meantime,
though,
I
think
a
checklist
would
probably
help
people
being
like
check
the
retries
and
redirects
and
make
sure
they
have.
These
attributes
check
the
required
versus
optional
stuff
and
make
sure
it's
ideally
presenting
these
attributes
like
if
you
can
make
sure
these
attributes
are
there.
A
B
Yeah
cool
all
right
well,
yeah
sounds
good
to
me.
Okay
sounds
good
to
me.
A
B
A
A
Yeah
yeah
yeah.
If
anyone
has
time
to
work
on
that
thing,
I
would
say
you
know,
go
go
for
it.
I
just
don't
want
to
block
us,
but
if,
if
that's
the
thing,
people
want
to
want
to
go,
build
or
build
it.
B
A
A
It's
like
a
little
bit
weirder
to
like
post
a
help
wanted
issue
somewhere
if,
if
it's
slightly
nebulous
like
what
they
should
be
targeting,
so
I
kind
of
would
really
like
these
open
issues
to
get
freaking
closed
out.
It.
B
Is
the
schema
validator
kind
of
thing?
Is
that
something
that
would
we
would
open
an
issue
about
inspec
repo.
A
You
know
as
a
way
for
people
to
to
give
their
two
cents
in
it,
but
I
don't
see
it
as
something
that
it's.
If,
if
it's
just
a
collector
plug-in,
then
the
specification
needs
on
it
aren't
aren't
heavy.
You
know
we
need.
The
spec
is
more
for,
like
all
this
stuff,
we
have
to
implement
in
like
500
different
places,
and
you
know
what
do
our
proto
buffs
look
like
and
stuff
like
that?
If
it's
just
like
I'm
off
here,
writing
some
crazy
schema,
validator
plug-in
then
just
just
go.
A
A
A
If
we
can
get
that,
if
we
can
like
make
sure
that
thing
doesn't
doesn't
just
like
run
aground,
people
not
paying
attention
to
it
and
get
it
put
in,
then
we
can
create
a
help
wanted
issue
in
every
language,
saying
please,
update
http
to
target
the
1.11
release
and
include
a
schema
version.
A
If
that
stuff,
like
misses
the
boat,
then
it's
not
going
to
be
official
until
you
know
next
month
and
that'll
make
it
harder
to
to
open
those
issues
or
accept
those
pr's
unless
we're
just
totally
fine
with
what's
in
1.10,
but
I
I
really
would
like
that
thing
to
get
done.
So
maybe
that's
part
of
our
work
is
like
really
bother.
The
heck
out
of
whoever
input
is
needed
to
to
close
that
thing.
A
I
I
can
try
to
help
with
that,
but
if
you
all
notice,
you
know
there's
someone
who
needs
to
look
at
it
is
not
looking
at
it
go,
go
bug
them
on
slack
and
I'll,
be
doing
the
same
thing
and
it'll
just
be
that
squeaky
wheel.
A
Okay,
great
okay,
so
I
just
yeah,
let's
just
let's
just
try
to
get
that
thing
over
the
finish
line
this
next
next
week.
A
I
put
it
in
the
agenda,
the
lincoln
slack,
if
you
have
any
input,
if
not
you
know,
don't
worry
about
it,
but
this
is
just
me
trying
to
to
solve
some
of
this
like
high
level
impedance
mishmash,
where
we
we
don't
have
an
official
project
level
backlog
and
that's
making
it
a
little
confusing
and
it's
it's
making
it
so
that
it's
hard
to
tell
which
tc
members
basically
to
to
get
involved,
and
so
I
just
want
to
like
move
all
this
stuff
to
kind
of
like
a
project
board
and
so
the
all
the
new
projects
that
start
after
us,
don't
don't
go
through
this
cycle.
A
Instead,
they
they
have
tc
members
available
from
the
beginning
and
everyone's
kind
of
aware
of
like
what's
happening
so,
hopefully
that'll
boost
participation
in
this
stuff
anyways.
It's
not
it's
not
a
complicated
proposal,
but
I
think
it'll.
I
think,
we'll
help
when
we
start
doing
it.
Reggie
here.
C
A
Is
agreed
to
come
on
as
like
a
a
tpm
like
a
project
manager
for
for
the
spec
group
to
kind
of
help
us
triage
the
backlog
and
and
make
sure
stuff
isn't
isn't
like
getting
stalled
in
different
places
and
stuff
like
that.
So
hopefully.
B
Cool,
I
don't
know
how
much
how
much
useful
input
I'd
have,
though,
because
I've
never
been
a
project
manager,
but
I'll
have
a
look.