►
From YouTube: 2021-03-22 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
C
D
All
right
shall
we
get
started
with
the
sig
check
in
I
see
people
have
already
been
filling
in
notes.
F
D
D
Think
just
like
an
interesting
question,
all
right,
javascript
daniel.
G
Okay,
the
api
is
still
at
rc
one.
As
we
reported
last
week,
the
sdk
release
candidate
should
hopefully
be
this
week.
I
take
most
of
the
credit
for
delaying
that
myself
because
I
took
a
week
of
vacation
so
we're
working
on
that
as
quickly
as
we
can
and
hopefully
we'll
get
there
this
week,
if
not
next
week,.
H
Yeah
so
we're
we
have
a
couple
of
issues
that
we're
closing
out
and
then,
after
that,
we're
planning
on
doing
the
1.0
release.
After
that,
there's
a
release
announcement
that
I
linked
in
here
draft
that's
a
pm
from
microsoft
put
together
and
yeah.
If
you
want
to
have
a
look
and
feel
free
to
add
any
comments
in
there.
A
I'm
not
a
maintainer,
but
I
can't
update
sure
all
right,
there's
just
a
1.1
beta
release
with
which
added
a
lot
of
new,
like
capabilities
to
the
sdk,
where
people
ask
about
how
do
I
config
asp.net
easily,
so
we
added
dependency
injection
feature
and
the
plan
is
to
bake
it
for
a
month
before
we
release
the
stable
1.1
and
by
the
way,
I
think,
open
time
should
not
just
hit
1
million
total
total
downloads
of
all
the
packages
we
published.
That
is
a
lot.
D
C
D
D
J
Yeah,
so
our
audit
of
the
specification
is
mostly
drawing
down.
There's
five
remaining
issues
to
just
complete:
they
all
have
assignees
just
hopefully,
should
be
done
this
week,
24
identified
tasks
in
our
rc
project.
There
is
one
actually,
I
think,
there's
like
one
identified
issue.
J
That's
blocking
us
from
the
specification,
that's
through
clearing
out
the
baggage
and
then
there's
two
other
open
pr's
that
need
to
get
resolved
before
we
can
actually
make
an
rc
release,
but
those
are
actively
being
discussed
currently
in
the
specifications
so
yeah,
that's
kind
of
a
status
update
of
that.
K
Yeah,
hey
think
I'm
in
this
second
yeah,
so
for
c
plus
plus
I
mean
we
are
still
working
for
the
beta
release,
we're
having
a
bit
slow
from
last
couple
of
weeks.
Just
the
reason
being
that
I
mean
most
of
the
approvers,
they
have
been
busy
on
the
other
stuff,
so
hopefully
going
forward.
The
next
two
weeks
probably
will
be
quick
and
still
there
are
some
some
features
like
resource
api
baggage
api,
which
still
is
not
fully
integrated.
K
So
probably
once
that
is
done,
we'll
go
forward
for
the
beta
release
and
then
then
we'll
start
planning
for
the
release
candidate.
So
vita
is
planned
for
mid
of
april
and
then
release
candidate
may
be
end
of
may.
D
Fantastic,
that's
it's
actually
really
encouraging
to
hear.
Considering
cpus
plus
wasn't
one
of
the
languages
we
started
off
originally.
So
it's
great
progress
all
right,
ruby.
L
We're
still
working
towards
our
first
rc.
There
are
officially
two
issues
in
the
milestone.
There
are
pr's
for
both
of
those
issues.
L
M
Yeah,
so
we
were
looking
for
some
direction
on
defining
like
a
1.0
beta
release,
we're
hoping
maybe
somebody
from
the
tc
could
come
and
help
us
out
with
that
during
one
of
the
sigs
at
some
time
and
nacho
asked
for
more
eyes
on,
like
just
the
general
state
of
sort
of
how
the
specifications
implemented.
D
Yeah,
do
we
have
anyone
on
the
the
tc
who
wants
to
assist
with
direction,
defining
the
beta
release.
O
Yeah,
it's
thursday
yeah
there's
a
the
checklist
that
tcu
is
putting
together.
Where
is
that
where's
that
located
cause
that
would
be
yeah.
O
N
Carlos,
do
you
know
where
that
is?
That's.
I
don't
know
if
that's
what
you
are
talking
about,
but
there
is
a
pr
that's
boredom
put
together
on
the
set
of
things
that
are
suggested.
Let
me
look
for
that.
Yes,
but
usually
meanwhile,
usually
what
the
tc
member
would
do
is
that
he
comes
checks.
Your
code
tries
to
see
whether
there's
something
that
may
need
you
know,
probably
needs
to
be
changed
or
updated,
and
then
we
feel
a
set
of
issues.
We
get
the
conversation
going
right.
N
Well,
so
that's
how
it
starts,
but
yeah
technically
there's
a
document.
You
cannot
find
it
now.
I
will
post
it
once
I
find
it
but
yeah.
Well,
I
will
comment
through
say
I
will
probably
okay.
Okay,
so
let
me
plan
so
I
will
start
feeling
issues
later
today
or
tomorrow
and
then
we
can.
On
the
thursday
meeting
I
will
join
and
we
can
have
a
longer
discussion
yeah.
I
will
post
during
later
during
this.
N
I
think
yeah
actually
yeah.
Let's
talk
about
that
more
later,
maybe
offline,
but
I
think
that
python,
I
think
the
painting
community
did
like
it,
but
we
took
it
on
a
more
relaxed
level.
Where
I
just
go
on
field
issues
we
talked,
we
said
you
know
some
of
them,
probably
they're
fine.
We
decide
not
to
go
with
them,
some
of
them,
yes,
and
so
it's
a
little
bit
less
a
strict
approach
and
that's
why
I
think
that
the
prg
put
together
as
something
that
physics
can
request.
N
D
Okay,
next
up
is
the
collector.
So
do
you
got
any
other
announcements
other
than
the
one
million
downloads
mark.
P
We
did
a
good
progress
in
the
past
couple
of
weeks.
Few
weeks
we
are
at
the
point,
probably
in
two
three
weeks-
maybe
four
weeks
we'll
have
an
rc
for
for
a
bunch
of
our
packages
to
declare
them
stable,
and
then
we
start.
I
wish
the
next
phase
will
be
starting,
focusing
on
otlp
components
like
receiver,
exporter,
otl,
bhtp
and
grpc,
and
a
couple
of
other
components
inside
the
collector,
and
after
that,
we
we
have
to
to
work
with
all
the
other
components
that
we
have.
C
Okay,
yeah
and
just
to
add
to
brogdon's
comments.
We
didn't
triage
of
you
know
the
current
back
phase,
one
and
phase
two
for
collective
stability.
Last
week
on
thursday
and
and
then
we
also
had
a
good
session
where
we
picked
up
some
of
the
issues
to
make
progress
there.
E
Yeah
we
recently
merged
in
autep
that
I
proposed
about
how
to
do
logging
library
prototypes
held,
and
so
I'm
kind
of
looking
for
volunteers
to
if
you're
interested
in
logs
and
want
to
work
on
implementations.
That
would
be
great
to
start
not
to
start
actually
continue.
Prototyping,
because
some
initial
programs
for
java
exist
for
c
plus
does
exist
and
to
continue
those
and
make
them
aligned
more
with
what
the
all-tech
proposes
to
do,
or
maybe
start
in
some
other
languages
where
they
don't
exist
at
all.
E
I
D
I
had
added
it
to
the
agenda
last
week,
but
I
also
didn't
attend.
So
I
don't
know
if
it
came
up
as
a
discussion
point.
It
was
added
on
the
agenda
ted.
I
see
you
just
unbeated.
Do
you
wanna
yeah.
O
I
I
did,
I
did
give
a
report
back
on
it.
I
don't
think
there
was.
There
was
huge
discussion
about
it.
Also
john
watson's
been
on
vacation.
I
know
he's
got,
got
lots
of
opinions
and
feels
on
this
subject.
So
I
think,
would
be
good
to
hear
from
him
when
he
comes
back,
but
it
looks
to
me
like
like
a
reasonable
solution.
O
I
have
some
questions
myself
around
handling
things
like
you
know,
older
versions
of
the
docs
like
how
do
we
link
to
those
things
and
the
pernicious
question
around
relative
links
like
like?
How
do
we
deal
with
with
linking
and
link
translation,
they're.
O
I
You
replied
on
the
thread
and
checked
it
out.
It's
fine
as
long
as
relative
links
are
fine
as
long
as
you're
not
linking
to
things
outside
of
that
directory
sweet.
So
what
would
the
next
good
step
here
be?
Would
it
be
helpful
if
I
went
and
took
the
existing
docs
and
then
made
prs
into
the
other
cigs
to
kind
of
get
people
bootstrapped.
I
O
And
for
clarity,
the
way
docs
get
updated
so
we're
we're
pulling
off
there'll
be
a
script
that
pulls
this
stuff
out
of
like
head
of
main
and
it
would
be
cut
off
of
a
release.
It'll
it'll
be
cut
off
of
release.
Okay
right,
I
think
in
the
in
the
proposal.
It
said
it
would
be
pulling
from
from
main
only
I
mean
it'll
it'll,.
I
Be
the
last
whatever
the
last
main
release
was
it?
Doesn't,
I
don't
believe
we
said
maine
just
because
that
way,
the
the
docks
are
going
to
advance
further
than
the
released
artifacts
or
sorry
maine
is
going
to
be
more
up
to
date
than
released
artifacts.
So
I
would
hope
that
people
would
be
updating
the
docs
as
they're
going
and
then
whenever
a
new
release
is
ready,
they'll
cut
that
and
then
that
would
be
pushed
to
the
website.
O
Awesome
that
that
was
the
only
I
forgot
what
I
read,
but
I
think
I
read
something
that
made
it
sound
like
it
was.
It
was
gonna
pull
off
of
maine,
but
what
you're
saying
makes
a
lot
more
sense.
I
Yeah
right
now
the
process
would
be
just
opening
an
issue
once
there
was
a
release
and
then
we
would
once
we
get
everything
switched
over.
Then
we
can
do
some
automation
in
terms
of
like
history,
that's
very
difficult
because
everyone
kind
of
has
their
own
release
cadence
and
their
version
numbers
don't
mean
the
same
thing
to
different
cigs.
So
people
wanting
historical
versions,
we'll
just
need
to
go.
Look
at
the
release,
tag
in
github
or
or
whatnot.
O
Yeah,
okay-
that
was
my
actual
question
there,
I'm
remembering
this,
so
I
think
there
was
like
yeah
a
reasonable
proposal
to
go
and
we
could
even
just
provide
links
to
these
old
versions
but
still
host
them
on
github.
O
I
Yeah
I
mean
there's,
that's,
there's
not
a
ton
of
options
there,
like
the
docs
site,
is
capable
of
versioning
right
and
having
a
nice
little
drop
down
and
publishing
multiple
versions
of
things,
but
it's
versioned
kind
of
the
place
that
it
versions
is
different.
Right
like
we
would
have
to
come.
We
would
have
to
come
up
with
like
a
our
own
way
to
do
it
and
that
would
be
challenging.
I
think.
I
Which
isn't
the
case,
because
what
we
would
have
is
actually
like
slash
docs
go
would
be
versioned
independently
of
slash
talk,
slash
java
right,
so
are
there?
You
know.
Is
this
a
solvable
problem
sure?
Is
it
a
solvable
problem
that
would
be
trivial?
No
like
it
would
take
a
lot
of
custom
hacking
on
that
template
and
then
it
would
also
be
kind
of
confusing,
I
think,
to
end
users,
because
the
docs
specifically
don't
you
know,
move
in
lockstep
or
the
releases
don't
move
in
lockstep.
I
should
say
so.
I
Is
there
a
you
know,
a
standard
point
that
we
could
kind
of
reference
and
say
like
okay,
doc's
version
based
off
of
the
spec
and
that
it
seemed
like
the
journal?
Consensus
was
having
the
doc
site
always
be
up
to
date,
with
whatever
their
latest
release
of
each
sig
is
and
then
keeping
the
stuff
in
history.
O
I
I
can
bring
this
up
to
the
com
sig,
but
yeah,
maybe
just
like,
like
the
mild
version
of
versioning,
where
it's
not
attempting
to
keep
all
the
docs
on
the
site
relevant
to
that
save
version
of
go,
but
just
having
like
an
archive
folder
where
you
can
see
the
properly
formatted
version
of
the
old
go
docs
that
were
in
that
that
were
in
the
github
repo
just
so
that
there's
like
a
formatted
version
of
that
stuff,
that's
still
available.
I.
I
Want
to
talk
about
if
you
want,
if
this
is
interesting
to
anyone
other
than
me
and
ted,
feel
free
to
come
to
the
comsig
meeting
this
thursday
thanks.
J
Austin,
I
just
want
to
jump
in
there
and
say,
like
the
ghost
sig
would
appreciate
it.
If
you
wanted
to
kick
stardust
because
I'm
a
little
lost
so
yeah.
I
N
Yeah,
I
was
wondering
about
these.
What
what's
the
plan,
if
you
guys
have
any
opinion
about
these?
This
was
something
that
was
left
out
of
1.0.
E
This
is
assigned
to
me
actually,
but
I'm
happy
to
if
somebody
else
wants
to
take
it,
because
I
won't
be
able
to
look
into
this
for
a
few
weeks
at
least
I'm
working
on
schemas
right
now.
There
are
a
few
things
that
need
to
be
clarified
here.
It's
not
just
about
declaring
its
table.
There
are
some
unsolved
problems
here
as
well
like
the
timestamps,
the
64-bit
integers.
It's
also
related
to
another
open
issue.
E
The
the
we
want
to
have
a
format
for
storing
otlpin
files
likely
some
json-based
thing,
so
this
is
going
to
be
mostly
identical
with
maybe
some
differences,
so
it's
kind
of
a
few
different
related
things
as
well,
with
some
decision
making
is
necessary
here
as
well.
So
if
we
can
wait
a
few
weeks,
then
I
can
start
working
on
it.
If
we
want
it
to
be
sooner
than
someone
else
need
to
to
work
on
it.
N
Yeah
and
besides
what
you
mentioned,
tigran
one
of
the
requirements,
or
at
least
suggestion,
is
that
we
implement
this
in
a
pair
of
languages,
so
we
can
validate
that
things.
Are
you
know
working
as
expected?
So
it
actually
requires,
as
you
said,
not
only
just
declaring
that
stable
but
like
work
on
a
few
small.
K
N
So
I
think
we
need
to
start
having
some
kind
of
a
small
plan
like
the
test,
one
put
together
for
the
convenience
api.
You
know,
I
don't
know
if
a
milestone
is
needed
for
this,
but
we
can
probably
put
it
in
the
next
good
to
have
milestone
for
tracing
or
something.
But
I'm
wondering,
besides
that,
how
important
this
is
or
how
important
you
guys
feel
that
this
could
be
going
forward.
E
I
think
it's
important
to
have,
I
just
don't
know,
what's
the
urgency
if
it's
actually
needed
right
now
or
it
can
wait
a
bit,
but
I
think
we
do
need.
N
All
right
yeah,
since
I
hear
silence-
I
guess
it's
important,
but
not
urgent,
but
anyway,
okay!
So
let's,
let's
respond
that
for
now
yeah
I
will
pro
probably
on
the
3i
session
on
friday.
We
can
discuss
going
forward
if
we
need
something
like
specific.
You
know,
like
small
team
or
something
to
to
help
you
grab
this
up
in
the
future.
William
thanks
for
the
for
the
feedback.
C
Yeah
I
mean
again,
I
just
wanted
to
better
understand
what
the
tracing
1.0
items
are
which
which
need
to
be
completed.
I
understand
the
collector,
you
know
timelines
and
milestones.
We
are
trying
to
hit
that's
why
you
know.
We've
also
added
additional
engineers
to
kind
of
help,
bogdan
and
tigran
on
some
of
these
open
issues,
but
from
a
language
point
of
view.
Is
there
anything
else
that
is
open
for
the
languages
to
graduate
to
one
daughter
for
tracing?
C
C
E
C
C
P
P
P
D
D
Javascript
we
got
an
update,
so
the
api
is
still
at
rc1
api,
one
and
a
half
million
weekly
download
as
well
and
the
sdk
for
our
c1.
Hopefully
this
week
daniel
did
you
have
a
did.
You
have
a
like
a
1.0
date
for
that.
D
J
No
a
few
months
if
elite,
if
you
want
to
send
some
go
engineers
over
or
anybody
else,
okay.
B
Yeah,
I
I
would
say
no
earlier
than
next
month,
even
if
we
get
some
resources
on
board
and
up
to
speed,
we
will
be
looking
probably
towards
the
end
of
april
for
an
rc
for
go.
Q
K
Is
may
end,
but
I
mean
we
have
been
seeing
the
pattern
in
c
plus
places.
I
mean
we
don't
get
consistent
contributions
over
the
course
of
time,
so
sometimes
sometimes
you
get
slow
down
with
the
pr.
So
definitely
if
you
can
get
some
contribution
from
some
engineers,
I.
D
All
right
and
then
we
have
ruby,
do
we
have
we're
working
towards
rc?
Do
we
have
any
kind
of
date,
we've
penciled
in
no
date.
L
I
would
say
my
best
guess
is
that
it's
a
on
the
order
of
weeks
and
probably
not
months,
if
that's
good
enough.
D
O
And
I
would
say,
on
behalf
of
the
swiss
group,
getting
some
some
outside
expert
eyeballs
on
it,
I'm
reaching
out
to
some
people
at
apple,
but
just
because
it's
been
a
very
small
working
group
like
I
think
what
that
group
needs.
The
most
is
it's
just
like
a
review
of
their
work
before
they
feel
confident
and
slapping
a
label
on
it.
Yeah
absolutely.
D
C
O
Okay,
that
was
also
the
end
of
our
agenda.
Do
we
have
other
agenda
items
that
people
would
like
to
discuss.
C
Yeah,
I
had
one
more
item.
I
know
you
had
mentioned
that
we
should
do
a
series
of
you
know,
updates
on
the
on
communicating
progress
for
different
components.
You
know
and
and
different
areas
of
work
again.
We
would
like
to
kind
of
have
a
better
understanding
of
how
we
do
that.
I
mean
we
have
a
couple
of
blog
posts.
We
discussed
today
and
that's
one
way
of
doing
that.
Is
there
any
other
ways
you
would
suggest?
O
Yeah
I
would
like
to
get.
I
was
actually
just
pinging
tigran
about
this
I'd
like
to
get
similar
to
what
we
have
for
for
tracing
and
metrics
now,
which
is
a
series
of
projects
with
with
dates
and
expectations.
O
I
can
get
that
for
for
logs
as
well
just
a
sense
of
what
the
expectations
there
are.
Then
I
can
create
a
gantt
chart
and
put
this
high
level
information
up
on
the
website,
so
we
used
to
have
a
project
status
page
and
basically
updating
that
page
to
just
have
have
this
information,
but
I
would
like
to
have
the
logs
there,
because
every
time
I've
shown
people
this
chart,
the
first
question
that
comes
out
of
everyone's
mouth
is
like
what
about
logs
so
yeah.
O
As
soon
as
we
get
that
I'll,
I
think
the
website
is
the
most
appropriate
place
to
put
that
and
then
keeping
it
up
to
date
will
just
be
a
manual
process.
For
now
that
I
think
we'll
just
have
to
stay
on
top
of
yeah.
L
You
I
just
snuck
something
on
to
the
agenda
since,
since
we
have
time,
I
wasn't
sure
if
this
is
a
spec
sig
thing
or
if
it
is
a
maintainers
meeting
thing,
I
think
it
actually
could
be
either
and
it
does
somewhat
affect
where
we
are
in
tracing
rc.
It
does
affect
some
of
the
some
of
the
complications
we're
having
in
integrating
some
of
the
work
needed
for
our
rc
and
ruby,
and
it's
mainly
around
b3
configuration.
L
So
basically
there
are,
there
are
kind
of
like
three
three
types
of
b3.
If
potentially
potentially
I
think
that's
what
that
this
issue
is
discussing
there.
If
you
look
at
the
zipkin
specification,
there's
b3
single
header
and
b3
multiheader
and
for
open
telemetry,
we
kind
of
have
this
hotel
flavored
b3,
which
is
it,
tries
to
combine
the
best
of
both
worlds
and
be
as
backwards
compatible
with
formats
as
possible,
but
be
as
forward-looking
as
possible.
L
So
the
the
hotel
flavor
is,
you
will
extract
b3
in
the
multi
or
single
header
format,
but
inject
in
the
single
header
format.
L
So,
right
now,
right
now
that's
kind
of
what
the
spec
says
is
the
default
for
b3
there's
a
little
bit
of
a
discrepancy.
I
guess
of
the
environment.
Variable
spec
in
that
there's
only
two
options:
there
they're
called
b3
and
b3
multi,
and
if
you
and
on
that
environment,
variable
spec
for
b3,
it
specifically
calls
it
b3,
single
and
links
out
to
the
zipkin,
the
zip
can
spec
and
then
it
has
v3
and
b3
multi
linking
linking
out
to
zip
and
spec.
L
O
Go
ahead,
ted,
I
was
gonna,
say
matt.
I
I've
been
thinking
about
this
a
little
bit
more
and
by
otel
flavor.
We
really
mean
we
check
for
both
header
types
in
order
to
maximize
compatibility
and
it'd
be
kind
of
a
shame.
If
you
picked
multi
that
we
like
stopped
checking
for
single
headers,
it
seems
like
maybe
the
better
way
to
interpret
these.
These
flags
is
we.
O
We
always
check
both
header
types
and
then
the
the
with
the
environment
variable
you're,
just
setting
which
of
those
headers
it
it
should
write.
Should
it
write
the
single
header,
or
should
I
write
the
multi-header,
so
that
would
be
just
like
a
slightly
different
way
of
interpreting
this.
I
was
wondering
how
you
felt
about
that.
J
O
I
O
J
That
would
happen
is
there's
conflicts
in
the
header
values,
but
that's
why
we
have
a
precedence.
I
think
is
also
why.
P
Yeah,
that's
one
thing
and
the
other
one
is
fyi
in
code.
They
can
configure
whatever
they
want
with
with
a
bit
of
code.
It's
just
about
the
the
configurations
that
we
offer
via
the
environment
variables,
because
the
with
code
they
can
configure
directly
whatever
they
want,
and
if
they
want
to
only
read
multi
multiheader,
they
can
grid
only
multiheader
and
so
on.
So
what
I
was
trying
to
point
is
this
is
just
a
configuration
is
not
the
behavior.
O
So
so,
maybe
just
yeah,
the
clarification
is
what
people
are
setting
with
this
environment.
Variable
is
just
what
which
header
type
should
be
written
which
which
injector
should
be
used
and
the
extractor.
If
you're,
not
mucking,
about
with
the
propagators
yourself
in
code,
should
it
should
always
be
both
with
a
you
know.
I
forget
which
precedence
we
currently
do.
I
think
it's
single
and
then
multi
yes,.
O
P
Let's
wait
for
that:
let's
until
we
have
clear
clear
use
case
and
questions
and
requests,
let's
not
preemptively,
add
more
options
that
we
need
to
support.
Sure
well,
probably
be.
B
Handled
with
a
composite
propagator
with
two
b3
propagators
set
up
within
it
as
well,
so
that
that
should
be
available
to
the
end
user
as
an
option.
If
they
really
want.
O
Yeah
it's
just
like
do
they
do?
We
want
a
configuration
option
that
makes
that
composite
for
them.
I
agree.
We
don't
need
to
do
it
right
now,
but
if,
if
we're
trying
to
facilitate
people,
switching,
that's
that's
the
way
people
would
switch
right,
is
you'd
roll
out
both
and
then
you
would
switch
to
single.
O
If
you
were
on
multi
right,
you'd
want
to
be
propagating
both
for
a
time
and
then
propagate
single.
If
you
didn't
want
breaking
changes,
but
I
think
the.
P
Zip
king
community
passed
that
moment
so
at
this
moment
they
are
at
the
moment
where,
where
they
accept
both
and
and
it's
single,
so
so
this
process
started
a
few
years
ago
for
zipking
and
I
think
they
are
at
this
stage
of
that
lifetime
debt.
So
we
are
just
following
whatever
the
zipkin
ecosystem
is
in
that
regard.
That
doesn't
mean
that
we
don't
give
users
the
open
the
opportunity
to
do
that
if
they
want,
but
as
as
anthony
said,
you
can
use
the
the
composite
version
of
this
and
emit
both.
If
you
want.
L
No,
I
I
don't
think,
there's
any
additional
scenario.
I
think
I
think
the
main
problem
is
that
my
read
of
the
spec
there
was
like
no
configuration
option.
That
was
really
the
the
hotel
flavor,
but
I
think,
based
on
this
discussion,
if
we
just
interpret
b3
well,
if
we
just
interpret,
if
we
always
extract
both
formats,
then
everything
works
out
fine,
but
I
do
think
we
need
to
like
clarify
this
in
the
spec.
N
So
makes
sense,
yes,
I
will
create
a
ticket
now
to
so.
We
don't
forget
about
that
yeah,
but.
L
Yeah,
I
I
already
volunteered
to
do
this
in
the
issue
I
just
yeah.
I
just
wanted
to
get
some
consensus
before
I
started
walking
around
with
actual
changes.
Awesome.
O
So
backwards
compatible
change
so
should
be
easy.
P
O
P
G
G
Comment,
it
was
just
more
a
quick
update
as
to
what's
the
current
priority
of
the
the
spec
work
like
what
is
currently
being
worked
on
at
the
moment
perfect,
because
there's
there's
so
many
issues
in
pr's
to
follow
them
all
is
kind
of
a
nightmare.
J
Yeah,
it
would
also
be
really
helpful
to
understand,
like
what's
going
to
be
included
in
the
next
release
or
when
that
release
timeline
is
going
to
be
similar
to
the
spec
sort
of
or
those
six.
P
J
Yes,
sorry
I
meant
like
so
daniel
is
kind
of
like
talking
about
all
of
the
issues
in
the
priority
order.
I
just
like
having
the
release
being
the
the
thing
of
setting
that
priority
order,
be
really
helpful
in
understanding
that
okay.