►
From YouTube: 2020-09-01 Spec SIG
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
C
D
E
C
C
C
By
the
way,
sorry
for
any
possible
noise
there's
some
construction
going
on
next
to
my
building,
so
it
has
been
pretty
annoying
I
will
be.
I
will
try,
of
course,
to
be
quiet
when
I'm
not
talking
about
when
I'm
talking.
Please
apologies
for
that.
C
C
Okay,
let's
start
the
meeting.
Thank
you
everybody
for
joining.
As
usual,
we
have
a
few
items
and
of
course,
as
usual
andrew
please
get
started
on
the
triaging.
D
G
Triaging
we've
we've
merged
the
prs
listed
there.
I
haven't
looked
at
it
in
a
couple
weeks
of
the
issue
itself,
but
we
did
make
progress
here.
G
B
G
Yes,
there
was
another
issue:
that's
been
filed
to
take
over
the
rest
of
this
work.
I
think
which
was
8
55.
So
I
think
we
could
close
this
and,
but
I
mean
855
is
a
pr,
so
we
should
leave
this
open
until
that
one
closes.
A
B
For
me,
for
me,
there
is
a
part
here
that
is
required
for
ga,
which
is
the
the
fact
we
discuss
in
the
metric
sig,
which
is
we're.
Gonna
have
12
labels
and
we
can
have
a
very
high
cardinality
for
the
metrics
for
the
http
metrics
and
we
need
to
resolve
somehow.
B
D
Okay,
thank
you
cool,
that's
it!
Everything
else
has
been
triage
in
the
past
week.
D
D
42
percent
has
been
closed
and
then
down
to
just
the
ones
we're
working
towards
the
end
of
the
first
week
of
september.
We
now
have
only
four
remaining,
so
11
out
of
15
have
been
closed.
D
So
we
went
over
some
of
these
at
the
maintainers
meeting,
but
these
are
the
four
that
we
are
trying
to
close
by
the
end
of
the
week
and
I
believe
it
was
called
out
that
this
is
one
of
the
longest
polls
in
terms
of
effort
or
complexity
in
order
to
bring
it
in.
C
By
the
way,
actually
there's
one
ticket
that,
for
some
reason,
is,
is
not
listed
there
and
it's
about
the
initial
open
tracing
compatibility
specification
section
which
overlaps
with
the
top
with
the
last
two
items.
Let
me
look
what
that
is.
It
has
been
on
the
works,
but
I'm
waiting
for
yuri's
feedback,
mostly.
C
So
it's
on
the
words
what
we
need
to
decide.
Let
me
see
there,
you
are
yeah,
that's
the
one.
So
this
is
like
you
can
think
of
this
as
the
paranormal
of
the
other
two
ones
yeah.
Basically,
it's
there's
a
tricky
scenario
related
to
how
to
handle
spam
and
baggage
because
they
were
a
single
entity
in
open
tracing.
So
there's
no
perfect
solution
here.
C
Yeah,
okay,
so
yeah
exactly
so.
If
we
change
that
to
p1,
it
only
works.
The
other
option
is
that
we
mark
these
three
open
tracing
issues
as
p2
or
something
like
that,
because
this
is
the
pattern
you
know.
D
C
Right
well,
not
breaking,
but
it's
like
a
requirement.
This
is
what
it's
not
going
to
break
anything
but
for
the
open
tracing.
You
know
this
requirement
about
supporting
open
tracing,
actually
I'm
tempted
to
mark
it
as
p2,
because,
for
example,
just
to
put
things
into
perspective,
there's
nothing
about
open
sensors.
So
it
means
that
we
can
probably
delay
it
a
little
bit
yeah.
Actually,
you
know
what
yeah,
let's
do
that,
so
these
two
last
items
that
were
p1,
let's
mark
them
as
p2.
C
J
Yeah,
I
just
want
to
make
sure
I
know
you
were
trying
to
implement
this
carlos,
and
I
think
there
was
maybe
some
issues
around
baggage
and
context
propagation
right,
that's
the
heart
of
we
got
to
hash
out
here
beyond.
Just
actually
writing
the
section
down.
C
C
F
And
just
a
point
for
people
on
the
call
for
all
the
p1's
that
are
tracing
related,
we
want
them
done
by
the
end
of
this
week.
If
they're
not
done
by
the
end
of
this
week,
the
technical
committee
is
going
to
either
aggressively
close
them
out
by
turning
them
to
p2
or
just
make
rapid
decisions
and
implement
them
quickly.
I
I
I
A
A
If
the
sentiment
is
that
it's
very
likely
that
we
will
have
the
error
hint
and
we
will
measure
this
autopsy
so
that
we
we
don't
delay
this,
I'm
I'm
happy
to
give
an
approval
to
the
author.
If.
B
J
Because
the
features
that
people
use
spam
status
for
need
to
be
replaced
with
something
else,
so
we
don't
want
to
remove
spam
status
without
putting
back
in
something
else.
People
can
use
to
detect
that
there's
an
error
and
they
should
parse
the
attributes
that
that's
the
main
reason
we
don't
want
to
have
a
half
state
where
we've
removed
something
necessary
for
jaeger
integration
and
all
these
other
things
but
haven't
put
in
a
replacement
for
it.
That's.
A
J
B
Guys,
I
think,
I
think
the
reason
why
everyone
agrees
to
remove
spam
status
is
because
there
is
no
one
way
to
express
an
error
or
a
status,
and
every
protocol
has
its
own
theme,
so
we
already
have
http
code.
For
example,
we
have
grpc
code
as
semantic
conventions,
so
why
do
we
need
the
networking
equals
to
still
anyway?
We
can
have
this
offline,
but
but
the
reason
why
we
remove
status
is
because
we
try
to
have
something
generic
that
did
not
work,
but
now
we
remove
something
generic
and
put
another
thing.
Generic.
B
J
Right,
that's
why
there's
a
little
tiny
bit
of
debate
left
like
do?
We
want
to
leave
span
status
and
just
have
it
be
like
okay
and
error
that
would
be
kind
of
equivalent,
and
then
you
have
air
hint.
So
there's
these
little
bits
of
knits
that
I
do
feel
are
going
to
come
up,
even
though
a
lot
of
us
would
just
like
to
merge
an
air
hint
and
be
done
with
it.
Okay,
I'm
going.
G
J
All
this
out,
thursday
morning
at
the
erisig,
so
we're
hoping,
if
you
really
care
about
this,
please
show
up
to
that
meeting.
That's
our
main
request.
A
Also
because
of
the
tight
type
timeline,
I
am
right
now
going
and
I'm
going
to
approve
that
all
tap
I
feel
like
we
are
going
to
have
a
resolution
on
thursday
one
way
or
another
right.
So
let's
have
the
otep
approved
it's
it's
a
very
high
chance
that
we
move
forward
with
that
right.
We
remove
the
spine
status.
We
add
something
in
in
instead
of
that
right,
most
likely
the
error
heat.
So,
let's
not,
let's
not.
J
D
Okay,
I
think
we
touched
upon
morgan
touched
upon
this
line
item
I
just
want
to
bring
up
was
just
quoting
from
the
blog
post.
What
our
end
of
week
goal
means
in
the
second
committee's
next
action
by
the
end
of
the
week.
That's
just
an
fyi.
D
The
other
item
that
I'd
like
to
also
highlight
now.
This
is
moving
forward.
I'm
looking
forward
a
little
bit
towards
our
next
steps
after
the
trace
spec
has
been
locked
down,
is
the
implementation
of
this
across
the
different
languages.
I
see
that
there
were
some
pr's
merge
in
order
to
update
the
compliance
of
implementations,
and
I
think
that's
helpful
towards
being
able
to
identify.
D
What's
the
amount
of
work
that's
needed
in
order
to
be
able
to
implement
this
and
put
out
a
release
that
the
end
users
get
the
hands
on,
it
looks
like
go
and
net
the
two
languages.
That's
marked
for
ga
need
those
to
be
filled
out
for
the
trace
table,
at
least.
D
In
addition,
it
looks
like
context.
Propagation
error
handling
needs
to
also
have
rows
in
there,
so
that
way
they
can
have
items
filled
up
for
that
and
that
will
then
be
able
to
define
the
amount
of
work
that's
needed
in
order
to
be
able
to
get
the
implementation
released
because
some
languages,
some
of
the
languages,
could
use
help
such
as
python
sick.
So
I'm
just
putting
a
call
out
there
for
the
upcoming
work,
that's
needed
that
that
could
use
some
help
and
moving
forward
beyond.
D
That
is
tackling
what
are
the
next
issues
that
we
have
it's
great,
that
we've
triaged,
like
all
the
issues
in
the
spec
repo.
This
is
just
a
breakdown
that
I
I
put
together
and
updated
this
morning
on
how
many
p1
issues
are
left
based
on
spec
label,
so
trace,
of
course
we're
moving
towards
the
four,
and
this
is
now
what
two
p1
issues
context
has
got:
nine
blah
blah
blah
blah.
D
B
B
I
don't
know
andrew
you
probably
know
better.
How
do
you
want
to
handle
this,
but
or
we
can
just
say
that
we
start
with
p2
right
now
and
what's.
D
D
I'm
assuming
that
still
holds
true
for
a
lot
of
the
one
issues
marked
here
as
well,
so
we
should
just
keep
that
nomenclature
and
keep
that
meaning.
Keep
that
understanding.
What
p1
is
so
that
way
we
can
make
sure
we
tackle,
like
metrics
he's,
got
the
p1
issues
not
messed
up
with,
like
oh
that's,
a
p1
issue
for
like
10
p2
issues
promoted
to
p1
for
trace.
Now
that
we've
knocked
out
all
p1
issues
for
trace.
You
know
what
I
mean.
B
B
Sure
and
then
but
p2s
have
p2s,
we
have
30
or
something
or
a
long
number,
and
we
still
want
to
out
of
them
to
kind
of
define
some
priority
between
them.
That's
why
I
was
thinking
to
to
to
do
something
like
this.
Maybe
we
just
add
more
p4b5,
and
then
we
spread
them
yeah
more
like
that.
I
don't
know,
but
what
my
point
is:
you'll
see
that
the
next
sections
have
way
more
issues,
and
I
was
looking
for
a
mechanism
to
signal
people.
What
is
the
next
important
thing
out
of
these
30.
F
D
D
D
D
F
Yeah
this
came
out
of
the
ground.
This
came
out
of
the
collector
log
sig
last
week.
Remember,
mark
carter
had
brought
up
whether
we're
going
to
use
ecs
anywhere
in
open
telemetry.
A
C
A
A
The
ecs
compatible
conventions,
or
I
I
if
there
is
no
one
available
to
do
this
volume
of
work,
to
compare
with
this
year's.
A
Of
that
sort,
then
it
doesn't
mean
that
we
cannot
ga
with
our
own
semantic
conventions,
which
we
have
already
right
so
who's
in
the
book
conventions.
J
Okay,
we
will
have
to
address
versioning,
potentially
that's
the
only
tricky
wicket
about
gaining
with
one
set
of
semantic
conventions
and
then
deciding
we
want
to
change
that.
We
want
to
add
to
them,
that's
fine,
but
if
we
want
to
change
them
after
ga,
it
means
people
would
upgrade
a
version
of
open
telemetry
and
the
data
that
they
send
out
would
be
different.
So
that
seems
yeah.
Ideally.
F
A
That's
fair,
honestly,
I
might.
I
feel
that
if
we
ga
with
some
set
of
semantic
conventions,
it's
quite
unlikely
that
we
later
introduce
something
incompatible
with
that
we
will
definitely
add
stuff
to
it
right,
but
a
different
set
that
is
not
compatible
to
it.
I
don't
think
it's
going
to
happen
yeah.
I.
F
A
C
J
Probably
the
most
important
part
of
that
is
to
look
at
the
semantics
we
already
have
and
compare
them
exactly.
Yeah
just
make
to
see
how
weird
that
is,
and
just
ask
the
question:
if
we
just
wrote
a
collector
processor
to
translate
this
stuff,
would
that
be
good
enough
for
people
who
wanted
ecs
format.
F
C
Perfect,
so
the
next
item
is
anshu
again
for
your
information
error
c
on
thursday
morning,
discussion.
D
E
C
C
B
I
E
E
I
C
F
B
B
And
I
also
explained
briefly
there
that
we
probably
needed
no
tap,
because
there
are
way
more
cases
where,
where
things
can
happen
and,
for
example,
bi-directional
streams
where
even
child
can
wait
for
the
parent
and
so
on,
there
are
more
complicated
things
than
than
just
child
of
and
and
follows
from,
and
what
I'm
trying
to
say
is.
B
Maybe
we
don't
need
all
the
things
right
now,
but
the
way
how
we
or
things
that
we
add
right
now
should
should
be
in
a
backwards
compatible
way
and
should
be
leaning
ours
towards
the
end
goal
of
supporting
all
the
cases
not
just
to
support
open
tracing
this
edge
case
that
they
define
this
and
yeah.
So
there
are
a
bunch
of
things
there
I
don't
know
I
was
trying
to
see
if
this
is
really
needed.
It
seems
that
it's
very
very
important
to
have
it
before
ga.
C
C
My
impression
is
that
after
thinking
sometimes
is
that,
based
on
the
fact
that
we
we
need
this
basically
in
in
the
basic
form
for
open
tracing
compatibility
reasons,
is
that
probably
we
could
try
to
go
for
the
semantic
convention
way
that
will
support
the
sim
layer,
and
this
wouldn't
be
having
this.
You
know
as
a
main
level
component,
and
then
we
could
have
added
in
the
future.
B
Yes,
but
I
don't
know
what
are
the
requirements
for
semantic
conventions?
Can
we
simply
drop
them?
I
don't
know.
Have
we
decided
semantic
conventions
follow
the
same
requirements
as
the
api
like
one
year
and
a
half
two
years
backwards,
compatibility
and
and
so
on
and
so
forth
or
or
is
it?
C
Yeah
but
I
was
wondering
whether
we
can
define
some
specific
semantic
conventions,
are
special
for
backwards,
compatibility
reasons
that
you
know
I
don't
know.
If
that's
enough,
maybe
that's
not
enough,
and
then
we
will
have
the
same
problem.
So
my
fear
is
that
I
understand
the
situation
about
probably
trying
to
add
more
reference
types,
but
I'm
afraid
that
that's
going
to
take
like
so
much
more
time.
B
I
I
actually
think
it's
actually
not
a
reference
type.
As
I
was
trying
to
explain
in
case
of
bi-directional
streams,
there
are
more
moments
in
the
span
where
you
are
waiting
for
for,
for
the
other
span
to
send
you
data.
So
it's
not
just
one
relationship
as
a
as
I
was
trying
to
explain
there,
there
are
more
moments
and
there
is
a
there.
There
is
a
happens
before
relationship
that
you
need
to
describe
there
between
different
moments
in
these
moments,
and
I
don't
think
is
as
simple
as
just
a
bullet.
B
It's
way
more
complicated
than
that,
if
you
want
to
get
it
correct
and
and
have
all
that
happens
before
relationships
defined
there
in
order
to
calculate
crazy
things
and
and
correct
critical
path,
analysis
and
stuff.
So
again,
my
call
is
for
for.
B
Figuring
out
is
this
really
something
that
we
will
break
somebody?
If
we
don't
have,
I
mean
I
know
we
break
open,
telemetry,
open
tracing
compatibility
or
shim,
but
is
anyone
who
is
really
using
these
fields
and
how?
If,
if
we
can
identify
how
and
maybe
maybe
focus
on
solving
that
issue
instead
of
instead
of
carrying
these
values
around
so
anyway,
I
don't
know
what
to
say,
but
I
would
like
to
to
think
a
bit
more
about
this
problem.
J
Can
I
can
I
make
a
suggestion
we
we
should
start
with
with
modeling
right.
This
is
really
a
trace.
Modeling
issue,
like
you,
said
it's
about
modeling
various
trace
relationships
beyond
just
child
propagation,
so
it
seems
like
the
first
step
of
that
is
for
to
agree
on
the
model.
Like
you
said,
bogdan,
like
what
exactly
are
the
relationships
we're
trying
to
form?
J
What
is
the
difference
between
different
relationships
within
one
trace
versus
different
traces
that
are
glued
together?
Do
we
want
to
say
async,
I
believe,
from
the
open
senses
side,
for
example,
async.
What
we
called
an
async
tracing
open
tracing
was
actually
more
like
multiple
traces
glued
together
with
links
or
something
like
that.
B
Yes,
but,
as
I
pointed
there
lynx
was,
they
had
to
use
one
for
for
asking
and
the
reason
why
we
choose
links
for
using
was
mostly
because
for
the
acid
work
it
may
end
way
after
the
rest
of
the
trace,
because
it's
an
essence,
you
don't
know
when
it's
going
to
be
scheduled.
You
don't
know
when
it's
going
to
be
ended
and
a
lot
of
the
logic
in
a
bunch
of
back
ends
are
our
time
related
to
determine
the
the
end
of
the
trace
to
to
to
identify
the
end
of
the
trace.
B
So
because
of
that,
we
we
strongly
encourage
people
to
use
links.
So
then,
then,
the
back
end
will
wait
separately
for
these
two
two
traces
and
not
not
break
these
things.
But
there
is
also
the
link
the
links
usage
where
for
batch
operation,
and
that's
where,
where
where
people
are
waiting
for
that,
so
so
we
we
did
have
a
problem
there,
because
links
were
used
for
for
us
incorporation,
but
also
for
batch
operations.
J
J
Oh
actually,
I
see
there
is
another
section
on
links
between
spans,
but
I
I
kind
of
feel
like
this
is
an
area
we're
going
to
actually
have
to
really
spell
out
to
our
users,
because
this
was
an
issue
even
with
just
having
child
of,
and
you
know
follows
from
because
it
was
a
little
vague,
just
saying,
async
versus
not
people
are
still
sometimes
like
confused
about
how
to
use
it,
even
though
I
thought
that
was
a
pretty
straightforward
concept,
so
I
do
think
this
is
an
area
where,
like
end
users,
when
they're
like
how
am
I
supposed
to
link
this
together,
they
get
kind
of
scared
and
they're.
J
B
Yeah
and-
and
as
I
said
for
me
for
me,
that's
so
we
need
to
clarify
links,
and
probably
links
have
to
have
a
way
to
say.
Is
this
a
batch
operation
versus?
Is
this
an
async
operation
or
or
independent
operation,
whatever
we
call
it,
and
that
may
be
good
enough
for
the
moment.
For
example,
the
bi-directional
string
keys
is
super
complicated.
So
I
remember
when
we
started
open
sensors
and
one
of
the
idea
we
added
this.
B
What
we
call
message
event
was
the
fact
that
there,
every
if
every
message
that
we
change
between
the
spans
have
an
id
and
we
have
a
send
and
receive
operations
which
we
know
there
is
a
happens
before
relationship
between
them.
So
you
you
are
able
to
determine
some
waiting
times
and
some
happens
before
relationships,
and
I
still
believe
that
that's
a
reasonable
way
to
to
implement
this,
and
it
worked
very
nicely
even
with
parallel
re,
parallel
messages
and
or
in
a
bunch
of
corner
cases
anyway.
B
That's
way
too
complicated,
and
we
drop
message,
events
for
for
that
reasons,
because
it
was
way
too
complicated
for
for
for
consuming,
but
just
dropping
now
something
here
without
carefully
thinking
it's.
It
is
against
my
my
philosophy
in
in
this
like,
even
though
we
aim
for
ga,
we
should
not
throw
things
here
just
to
to
have
them
for
for
different
reasons.
That's
my
two
cents.
C
And
about
your
question
on
whether
somebody's
really
requiring
this
functionality,
I
would
like
to
ask
yuri
who
is
who
is
you
know
he
knows
his
stuff
very
well,
so
I
would
probably
poke
him
yeah,
and
I
will
do
all
my
research
on
my
side
yeah.
I
think
that's
important
part.
If
not,
we
can
postpone
it,
as
you
suggested,
to
habit
this
discussion
in
a
more
depth
way.
Yeah.
J
I
I
will
say
for
open
tracing
compatibility.
It
would
be
interesting
to
know
if
jaeger
really
leverages
that
I
found
in
practice
end
users
did
perhaps
because
there
was
not
a
feedback
loop.
You
did
not
necessarily
get
much
about
using
async
versus
child
of
end
users
tended
to
be
lazy
and
not
pay
attention
to
this
right.
It
was
like
slightly
abstract
concept.
J
You
don't
get
bit
for
not
doing
it.
So
in
practice
my
impression
was
no
one
really
used
follows
from
very
much
because
I
don't
think
any
backends
really
gave
you
much
for
doing
it,
but
I
would
like
to
know
whether
jaeger
does
actually
give
people
some
kind
of
value
if
they
do
this.
J
B
Correct-
and
I
think
it's
important,
but
I
as
purely
pointed-
and
I
I'm
trying
to
point-
I
don't
think
it
was
the
right
necessarily
the
right
thing
and
we
may
want
to
spend-
and
probably
this
discussion
is
going
to
take
months,
to
get
it
right
and
and
and
stuff,
and
I
that's
that's
my
fear,
do
we
really
need
right
now
or
we
can
postpone
this,
and
this
is
more
a
question
on
the
open
tracing
side
and
if
the
answer
is
no
no
no,
we
really
need
this.
I
would
try
to
come
up
with
a
solution.
B
That
is
not
that
bad,
maybe
maybe
semantic
convention
is
better,
as
as
carlos
pointed
because
at
least
the
api
compatibility,
we
don't
break
those
like
frameworks
that
we
integrate
like
dot
net
score
or
something
like
that.
We
integrate
this,
we
add
an
enum
and
then
we
remove
it
it's
much
worse
than
than
a
semantic
convention.
J
B
J
Agree
we,
I
don't
think
we
need
this
for
open
tracing.
We
we
should
check
in
with
with
the
jaeger
community,
but
if
they
don't
really
leverage
it,
then
I
would
say
we
definitely
don't
don't
need
it
for
now
and
when
we
add
it
when
we
come
up
later
with
a
way
to
model
this,
that's
super
great
and
we
can
model
cache
and
validation
and
all
this
crazy
stuff,
then
you
know
we'll
be
able
to
add
this
back
in
if
people
needed
it.
B
One
one
thing
that
I
was
trying
when,
when
I
designed
the
message
events
with
with
one
guy
from
google,
we
were
actually
trying
to
model
even
the
memory
bus
between
cpu
and
ram
and
stuff
like
that
to
with
this,
so
we
went
very
crazy
with
that.
That
being
said,
also
one
quick
thing.
I
think
it's
very
important
now
that
we
are
getting
close
to
ga
and
stuff
to
have
much
to
be
more
strict
about
defining
things,
experimental
versus
put
them
into
the
even
semantic
conventions.
B
I
think
we
should
start
having
an
experimental
directory
even
for
semantic
commissions
and
stuff
and
start
putting
things
there
before.
We
are
sure
it
feels
to
me
that
sometimes
I
I
feel
a
pressure
for
for
merging
things,
even
though
I
don't
agree
with
or
or
others
don't
agree
with,
and
is
this
pressure
that
is
ga
coming
ega
coming.
B
Let's,
let's
have
everything,
can
we
start
having
experimental
directory
even
for
for
api,
for
sdk
and
for
for
semantic
conventions
and
make
more
use
of
that
and
be
aware
that
we
should
not
just
put
everything
that
we
believe
right
now,
it's
important
just
because
the
ga
line
is
coming
in
in
two
weeks.
Let's
put
everything,
because
if
we
don't
have
it,
it's
going
to
be
very
hard
after
that
to
have
it,
let's,
let's,
let's
design
a
process
for
for
having
experimental
for
everything.
B
Start
with
specification
and
then
code
basis
should
follow,
probably
the
same
pattern.
I
think
this
is
a
good
question.
I
think
both
should
follow
the
same
thing
in
in
code
basis.
I
saw
different
ways
to
do
it,
for
example,
grpc
guys
they
use
annotations
on
the
apis,
mark
them
as
experimental
and
stuff.
I
don't
know
what
is
the
right
thing
to
do?
We
can
discuss
in
every
language.
B
How
is
the
the
right
thing
to
do,
but
I
think
the
notion
of
experimental
should
be
added
everywhere
from
from
this
point,
like
I
I
feel
like,
we
should
have
a
mechanism
as
part
of
the
ga
to
experiment
with
things
and
to
make
sure
we
where
we
guarantee
backwards
compatible.
We
guarantee
that,
where
we
don't,
we
don't.
J
Yeah
make
sense
in
general,
I
don't
think
we've
written
down
our
strat
we've
been
so
focused
on
ga.
We
don't
actually
have
a
written
down
strategy
for
post
ga.
How
do
we?
How
do
we
continue
to
make
changes
while
preserving
the
guarantees,
because
I
think
that
there's
enough
layers
there
that
we
have
to
think
it
through?
For
example,
you
can
add
an
experimental
api
feature,
but
should
core
instrumentation
rely
on
experimental
features,
or
do
they
stop
being
experimental?
If
you
do
that,
so
I
think.
J
Wickets
there
about
what
is
what
is
backwards,
compatibility
mean,
and
you
know
how
do
we
avoid
accidentally
breaking
a
bunch
of
people
or.
J
B
B
So
I
don't
know
I
would
like
to
solve
this
issue
because,
as
I
said
my
my
feeling
is
we
I
saw
at
least
four
or
five
pr's
that
one
added
merged
and
I
don't
feel
that
were
required
for
ga
it
was
just
it
happens
that,
and
the
argument
was
the
pr
is
ready
to
merge.
Let's
merge
it.
Oh
sure,
but
let's
not
okay,
let's
have
a
balance
like
yeah.
D
Well,
I
have
something
to
add
towards
that.
I
noticed
going
through
it
like
we
have
what
15
trace
p1
p1
issues,
but
we've
closed
like
50,
something
issues
in
the
spec
repo.
A
lot
of
them
are
p2s
p3s
and
that
just
kind
of
shows
that,
like
not
everyone's
concentrating
only
on
p1s,
nor
should
they
really
be
only
exclusively
contrary
to
p1.
But
if
like,
if
we
were
like
machines
and
super
hyper
focus
that
could.
D
B
I
agree
I
agree
with
you
andrew
I.
I
think
there
was
a
misunderstanding
a
bit
about
the
goal
of
this
week.
I
think
a
lot
of
people
understood
initially
as
everything
for
trades
should
be
done
this
week.
So
I
don't
blame
people
solving
p2
and
p3s
for
trays,
got
it
or.
B
Yeah,
which,
which
maybe
we
did
not
clarify
and-
and
I
I
blame
on
us
for
that-
and
I
I
don't
I
don't
blame
on
people
solving
other
things
that
we
mark
as
p2p3
more
for
me,
the
most
important
thing
is
is
prs
that
are
not
p2p3
and
even
myself
I
may
have
done
some
of
them,
but
anyway
we
need
to
to
have
a
way
to
to
not
to
probably
maybe
maybe
put
an
announcement,
for
example,
and
if
everyone
is
okay
with
that
that,
as
long
as
there
is
an
issue
mark
required
for
j,
we're,
not
gonna
review
or
we're,
not
gonna
accept
any
other
pr
for
for
for
until
we
are
ga,
for
example,
the
reason
being
again
again.
F
J
F
That
then,
beginning
of
next
week,
once
we
get
the
the
p
ones
done
and
then
we'll
just
tell
people,
okay.
J
J
D
I
I
I
will
like
to
add
that,
like
boxing,
I
think
your
original
proposal
of
like
having
the
experimental
subdirectory,
something
like
that,
may
be
a
legitimate
way
to
start
directing
some
of
those
if
you
see
them
coming
in
of
something
that's
marked
for
after
ga
release
after
ga
and
he's
like
this
is
coming
in.
Like
perhaps
ask
can
you
put
this
in
the
experimental
directory
and
because
we're
trying
to
make
sure
that
it
doesn't
get
locked
in
for
that?
D
As
for
communicating
that,
out
with
everyone
and
formalizing
as
a
process
for
post
ga,
I
think
yeah
that
is
helpful
for
being
able
to
work
on
major
version
breaking
changes
in
some
way.
I
have
opinions
on
how
that
could
be
accomplished,
but
yeah.
My
time
is
kind
of
filled
right
now,
in
order
to
be
able
to
actually
formalize
that
yet,
but
I'd
be.
J
We
can
do
this
as
a
group
over
the
next
coming
week.
Just
get
a
more
tightly
defined,
set
of
milestones
that
we're
going
to
hit
in
the
process
of
ga
right
like
so
we're
now
just
going
to
ratchet
up
precisely
what
our
next
steps
are,
including
potentially
a
spec
freeze,
funneling
issues
that
do
have
agreement
into
experimental.
J
We're
saying
like
we
don't
want
this
pr
to
get
packed
up,
we're
going
to
put
it
in
experimental
because
we
do
like
it,
but
we're
not
going
to
be
bothering
maintainers
with
implementing
experimental
things
right
now
and
then
figure
out
post
ga
be
like
this
is
how
experimental
changes
can
be
introduced,
and
these
are
all
the
backwards
compatibility
gotchas.
You
must
think
about
when
you're
thinking
about
a
change
postga,
so
we
can
get
that
all
sorted
out
in
the
next
couple
weeks.
J
J
B
B
Is
not
good
or
is
not
complete?
Is
it
means
that
people
don't
have
time
to
think
about
all
these
cases
and
stuff
if
you
really
want
to
have
it
put
it
in
experimental
if,
if
otherwise,
just
wait
for
for
us
to
have
more
room,
I
mean,
I
think,
the
the
current
pc
members
and
by
the
way
next
week,
you
all
know,
based
on
that
experiment,
we'll
add
three
new
people.
There
will
be
a
discussion
between
the
current
dc
members
and
stuff.
I
don't
know
all
the
details.
B
C
H
J
All
right:
well,
we
can
pick
this
up
again
at
the
maintainers
meeting
on
monday.
How
does
that
sound.
F
Hold
up
once
ted
isn't
monday
labor
day.
F
Yeah
and
canada
too,
we
could
move
the
maintainers
meeting,
maybe
to
tuesday
at
the
same
time.
So
just.
E
H
J
Okay:
okay,
well
I'll
put
this
on
the
list
for
the
spec
next
week's
spec
meeting.