►
From YouTube: 2021-02-04 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
Cool,
I
think
alex
will
be
a
little
bit
late,
but
we
can
go
ahead
and
get
started
yeah.
So
as
usual,
you
know,
if
you
can
add
your
name
to
the
attendees
list.
That'd
be.
B
Great
all
right
so
this
week,
not
much
on
the
you
know
and
jet
does
and
stuff,
but
we're
pretty
much
just
focused
on
you
know,
1.0,
due
to
like
some
remaining
pr's
that
are
open
and,
like
the
you
know,
recent
changes
in
the
spec
we're
planning
to
release
rc1
by
the
end
of
next
week.
B
The
the
open
issues
right
now
for
the
that
were
just
changed
recently,
mostly
the
hotel
trace
to
auto
traces
change
for
the
environment
variables
yeah.
This
should
be
pretty
straightforward,
but
this
is
just
the
like.
A
blocking
thing
that
we
have.
B
One
of
the
questions
that
alex-
and
I
talked
about
is:
should
we
do
this
whole,
singular
to
plural
thing,
just
for
the
environment
variables
or
for
like
everything
within
our
code?
More
specifically,
like
the
you
know,
the
folder
path
like
stuff
within
our
docstrings
or
some
of
our,
like,
like
api
services.
Maybe,
like
my
opinion,
like
I
feel
like
it's
not
a
big
deal.
You
know,
I
think
just
the
environment.
Variable
change
is
good
enough
and
plus
it
won't
like.
B
Yes,
we
can
still
break
people
right
now
and
like
we
should
make
this
decision
right
now.
But
honestly,
I
really
don't
think
it's
a
huge
issue.
C
Laden
just
question
here,
so
we're
going
to
have
some
something
when
I
say
something
I
mean
any
possible
thing
like
environment
variables
or
folders,
or
file
names
or
functions
or
whatever
right.
Yeah.
We're
gonna
have
something
named
hotel
traces.
C
Something
else
right
and
we
are
also
gonna
have
open
to
limit
tweet.
The
tracer.
C
Yeah
yeah,
so
the
idea
is
to
rename
everything
from
tracer
to
traces.
B
No,
no!
So
so
right
now,
the
only
thing
that
we
need
to
do
for
this
spec
change
is
to
rename
our
environment
variables
so
like
the
hotel
traces
exporter,
as
well
as
the
the
hotel,
traces
sampler
and
then
the
yeah
that's
pretty
much
it.
C
All
right
yeah-
because
I
I
remember,
had
a
conversation
with
josh,
not
not
long
ago,
when
I
mentioned
it
to
him
that
we
have.
D
B
B
B
D
B
I
wasn't
really
referring
to,
like
the
tracer
part,
I'm
referring
to
like
if
you
take
a
look
at
like
so
like
the
the
folder
paths
like
this,
we
have
like
dot
trace,
so
it's
nothing
to
do
with
like
specification
related
stuff,
it's
just
like
internally
python.
We
we
just
used
trace
before
you
know,
and
maybe
some
some
some
in
our
doc
strings
too.
So
it's
like.
C
D
B
Right,
I
I
think,
like
tracer
is
kind
of
set
in
stone
like
tracer
itself
is
like
a
like,
has
already
been
properly
defined
in
the
specs.
A
I
think
yeah,
like
you
mentioned
this,
isn't
specified.
So
I
feel,
like
I
feel
like
leaving
this
trace,
would
be
okay.
Unless
anybody,
I
don't
what
I'm
trying
to
say
is
I
don't
see
it
as
an
inconsistency.
Does
anybody
else.
B
A
B
A
B
A
B
But,
to
be
honest,
like
I
totally
agree,
it's
like
we're
gonna.
Have
this
inconsistency
regardless
you
know.
So
maybe
it's
like
not
such
a
big
deal.
You
know.
B
Oh
yeah,
I
have
it's,
I
think
it
was
bogdan.
I
think
he
is
strongly
advocating
for
this.
For
some
reason
I
didn't
follow
it
that
closely.
I
just
knew
that
I
got
merged.
So
okay.
B
Yeah,
so
I
guess
they
wanted
to
be
consistent
for
environment
variables,
which
makes
sense,
but
for
internally,
like
might
not
be
such
a
huge
deal.
You
know.
C
Well,
I'm
just
a
little
bit
afraid
that
someone
will
have
some
tracer
earth
and
that
completes
the
the
I.
D
C
B
But
we
don't
have
you
know,
like
the
plural
version
of
tracer,
you
mean
that
problem
is
unavoidable.
Right,
like
people,
users
can
do
whatever
they
want
like,
but
they
shouldn't
make
up
random
terms
right,
like
they
should
just
look
at
our
api
service
and
read
our
docs
strings
and
stuff
right
so
like
what's
stopping
users
from
using,
like
you
know,
tracers
without
the
e
or
something
right.
A
Yeah,
honestly,
if
anybody
has
a
strong
opinion,
so
I
have
no
strong
opinion
and
to
avoid
it
being
a
bike
shed.
Maybe
somebody
does
have
a
strong
opinion.
We
can
just
go
with
that.
C
E
C
B
I
think
for
the
the
metrickers
and
the
the
utilities
to
use
metrics
and
stuff,
like
I
think
those
will
be
defined
in
spec.
So
hopefully
we
can
like
minimize
the
the
risk
for
introducing
too
many
terms,
at
least
for
traces
like
the
specifications
right
now,
like
they're
pretty
clear.
So
I
don't
foresee
like
that.
Many
additions
in
terms
of
the
tracing
pillar.
A
Yeah
one
one
thing
I
was
gonna
say
is
like
I'm
just
trying
to
think
of
how
other
libraries
do
it
and
like
standard
library,
python
collections,
you
have
like
future
python
concurrent
futures
threading,
so
you
usually
have
like
the
noun
version.
I
guess,
but
I
don't
know,
I
really
don't
care
that
much
so
yeah.
To
be
honest,
me
too.
B
Me
too,
okay
right,
if
there's
no
other
kind
of
like
strong
opinions,
I
think
we'll
just
stick
with
the
environment
variables.
Then.
B
B
All
right,
nice
yeah,
so,
as
I
mentioned
before,
we're
planning
to
release
rc1
by
the
end
of
next
week
we're
trying
to
get
solve
all
the
issues
that
are
outstanding
as
fast
as
possible.
B
B
I
think
alex
has
a
pr
open
for
this
and
we'll
talk
about
that
after,
I
think
the
only
one
that
is
like
kind
of
outstanding
is
this
otlp
should
support
concurrent,
sending
the
reason
why
we
put
this
up
as
rc1
was
because,
in
the
feature
matrix
outlined
by
the
specs,
as
you
can
see,
there's
like
an
optional
column
now
and
for
for
the
exporters.
B
I
think
aaron
took
a
look
at
this
and
like
tried
to
answer
this
guy's
comments.
I
pinned
him
an
hour
ago
asking
him
if
he's
going
to
take
this
on,
but
like
might
be
unlikely
that,
like
he'll,
respond
in
time,
because
this
is
a
blocking
issue
for
rc1,
so
you
know
like
in
the
unlikely
case
that
they
can't
take
this
on
aaron.
Are
you
able
to
like
maybe
take.
A
A
Yeah,
I
can
and
to
be
clear,
I
kind
of
feel
like
we
need
to
clarify
a
little.
If
you
look
at
the
matrix,
the
only
language
that's
implemented.
This
is
javascript
and
they've
taken
some
some
liberties,
so
they're
doing
like
they
basically
return
success
before
they
get
like
all
the
responses
from
the
server
they're
using
async
version
of
grpc,
and
that's
fine
and
all,
but
like
I
don't
know
it
would
be
nice
to
just
clarify
some
of
that
stuff.
A
B
Okay,
I
think
my
gut
feeling
really
is
like
this
was
added
like
a
while
ago
and
if
anything
like,
if
the
specs,
if
the
spec
issue
doesn't
get
resolved
by
1.0,
which
is
highly
likely
technically,
this
would
be
like
an
additive
change
right,
so
we
won't
be
breaking
anyone.
So,
like
worst
case
scenario
is
like
you
know,
we're
gonna,
be
we
if
we're
gonna,
do
this
we'll
do
this
right
and
like
open
up
a
spec
issue
and
like
clarify
what
the
default
behavior
is
yeah,
so.
A
A
B
All
right
cool,
oh
nice,
cool
other
than
that
for
the
rc1
release.
I
know
we've
been
talking
a
lot
about.
You
know
like
the
deprecation
of
packages
and
everything
so
we're
going
to.
B
I
think
we're
just
gonna
make
like
the
arbitrary
decree
of
deleting
the
old
extension
packages
for
the
these
three
packages
that
are
gonna
be
part
of
rc1.
That
way
it's
like
like,
yes,
like
we
will
break
old
users
and
everything-
and
I
remember
aaron
having
a
an
aneurism
over
that.
But
it's
just
something
that,
like
we
just
always
kind
of
like
leave
and
like
the
conversation
gets
stale,
so
I
think
we're
just
going
to
put
the
hammer
down
before
we
go
to
1.0.
F
And
to
be
clear,
though
I
I
don't
think
it's
an
arbitrary,
arbitrary
decree
here.
I
think
it's
it's
very
intentional.
You
know
the
bottom
line
is
currently.
We
have
like
a
very
small
amount
of
users.
We've
already
seen
users
being
confused
by
these,
like
exe
packages
that
are
left
laying
around,
and
you
know
the
support
cases
right
now
is
kind
of
manageable.
F
But
if
you
imagine
you
know
the
one
auto
release
announcement
and
people
getting
excited
about
using
open
telemetry
for
python,
you
know
the
number
of
people
that
are
going
to
get
confused
by
these
packages
is
only
going
to
increase,
and
you
know
it's
also
going
to
be
a
lot
more
difficult
to
remove
them
in
the
future.
So
I
feel
like
this
is
a
very
intentional
move
here.
B
B
All
right:
okay,
cool
cool,
nice,
so
we'll
probably.
B
B
A
year
yeah,
so
cool
and
we'll
revisit
the
other
packages
when
we
release
those
too
so
at
least
the
users
will
get
exposure
and
click
change
logs
and
stuff.
B
A
Yeah,
so
we're
not
using
it
right
now,
but
so
now
that
metrics
and
traces
are
not
going
to
be
1.0.
At
the
same
time,
yeah
I'm
wondering
if
I
need
to
like
what
I
did
was
I
combined
the
two
exporters
into
a
single
package
yeah,
which
is
what
we
have
for
otl
p2.
So
otlp
package
has
tracing
and
metrics
exporters,
but
now
that
you
know
metrics
and
traces
aren't
going
to
be
1.0.
A
At
the
same
time,
I
have
to
decide
if
I'm
going
to
split
them
and
leave
the
monitoring
one
like
the
metrics
one
below
1.0,
and
I
think
we
need
to
make
the
same
decision
for
otlp.
So
if,
if
we
decide
to
split
otlp
into
two,
then
I'll
pick
up
this
name
again
and
and
then
we
can
delete
the
other
one
and
then
otherwise
I
can
yeah.
We
can
delete
these.
So
what
do
you
guys?
Wanna
do
for
otp.
B
For
all
tlp,
I
think
we're
it's
gonna
be
following
the
same
like
versioning
and
release
plan
as
the
sdk
and
api.
So
it's
the
whole
like
what
we're
releasing
the
package
will
be
only
the
tracing
components
of
the
otlp
explorer,
but
the
like
the
dev
version
or
the
you
know.
Experimental
version
will
contain
both
of
them,
but
they
all
exist
in
one
package.
B
A
Yeah,
that
makes
sense
I'll
I'll
think
about
a
little
more.
If
I
want
to
split
them,
but
I
think
sure
I'll
get
back
to
you
and
then
but
yeah.
B
A
B
Oh
that's
another
package
that
exists
right
now.
F
F
F
No,
this
is
a
like.
What
do
we
expect
our
users
to
do
so?
It's
you
know.
Otlp
export
currently
has
like
three
options
mentioned
in
the
spec
there's
json
over
http,
there's,
protozoa
http
and
then
there's
grpc
with
protos
and
our
implementation
only
uses
grpc.
Is
that
something
that
we
need
to
split
out
as
a
separate
package?
My
my
guess
is
that,
yes,
because
we'll
we
won't
want
to
have
the
same
dependencies
on
the
other
packages
but
yeah.
I
guess
what
should
the
name
be
here?
A
Yeah,
I
was
in
the
spec
and
they
were
discussing
this
because
there
was
supposed
to
be
an
environment
variable
to
choose
the
protocol,
but
then
that
would
require
them
to
all
be
in
the
same
package
right.
So
they
decided
against
that
for
exactly
that
reason,
because
people
might
not
want
the
grpc
dependency
which
probably
for
python
people,
it's
the
only
reason
you
really
want
to
use,
not
the
grpc
exporter
or
for
some
reason
your
receiver
can't
take
it
but
yeah.
A
A
Yeah
or
we
could
like
do
that's
awful,
it
depends
thing,
the
extra
depends
and
then
we
could
have.
You
know
like
installed
in
temperature,
exporter
grpc,
and
then
you
would
put
like
grpc
or
proto
or
http,
and
then
it
wouldn't
install
the
correct
dependencies.
You
would
have
dynamic.
H
F
B
Okay,
but
yeah
alex
that's
a
good
issue
to
bring
up.
Do
you
want
to
create
a
ticket
for
that.
B
I
F
F
B
Cool
nice
all
right
does
anybody
else
have
any
other
pressing
topics
that
are
not
specifically
pr
issue
related.
B
Okay,
so
alex
recently
added
a
pr
for
solving
this
readable
span
issue
the
so
to
not
access
spam
attributes
inside
the
span
context
alex.
Do
you
want
to
just
take
a
few
minutes
to
talk
about
this.
F
F
The
readable
span
essentially
means
that
whoever
has
access
to
real
real
spans.
In
this
case,
that's
the
the
span.
Exporter
can
only
read
attributes
from
a
span.
It
can't
write
to
it,
and
so
there
is
a
the
the
pr
the
to
the
spec
just
calls
for
this
readable
span.
F
The
different
sigs
have
implemented
this
differently,
so
go
has
implemented
this
via
a
span
snapshot,
which
is
essentially
the
equivalent
of
what
I
think
java
calls
spam
data,
and
so
so,
basically,
everybody's
kind
of
implemented
a
little
bit
differently,
but
and
what
this
really
means
is
that
there's
just
a
like
a
read-only
copy
of
the
some
of
the
span
data,
that's
required
for
the
exporter,
and
so
the
the
pr
just
implements
that
and
that's
really
all
the
pr
is
doing.
There's
nothing,
nothing
really
exciting
about
it.
F
It
did.
It
was
helpful
to
to
create
this
readable
span
interface,
though,
because
or
sorry
disputable.
Spam
class,
because
it
did
point
out
that
some
of
our
contrib
packages
were
trying
to
like
modify
resources
where
they
shouldn't
they
shouldn't
have
been
able
to
so.
C
We
so
we're
gonna
have
read,
write,
span
and
readable
span
right,
yep,
isn't
the
isn't?
The
read
write
span
also
a
readable
span.
C
E
B
Yes,
only
during
when
it
gets
to
the
span
processor
on
end
to
the
exporter.
F
C
Can
just
laden
didn't
you
just
say
that
some
something
was
going
to
be
able
to
modify
attributes.
B
B
If
you
want
to
take
a
look
at
that,
it's
I
think
it's
a
defining
our
sdk
somewhere.
H
B
Yeah
somewhere
here,
oh
check
spam
ended
this
thing.
Yeah.
B
Yeah,
hey
so
alex.
I
remember
talking
about
this,
but
I
don't
remember
the
the
reason.
So
if
we
already
have,
the
check
span
ended
thing.
What
was
the
reason
why
we
needed
the
to
make
a
readable
span
again
or
you
had
a
reason
for
that?
I
forgot.
F
Sorry,
I
can't
remember
the
context
of
the
question
that
we
were
discussing,
but
I
mean
essentially
we
just
don't
want
the
the
span
to
be
modifiable
at
all
by
the
exporter
right.
So
like
right
now,
if,
if
we
don't
have
a
read
of
read
only
span,
then
people
can
still
modify
the
attributes
directly
if
they
wanted
to.
F
B
F
B
Well,
well
it
it
makes
like
that.
That
reason
makes
sense,
because
it's
python
and
we
can
access
everything
by
dot
but
like
in
a
language
like
java,
where
they
can't
do
that
and
if
they
already
enforce
like
checking
the
span,
that's
ended
before
setting
an
attribute.
Why
would
they
need
to
implement
a
something
like
a
read?
Read
only
span.
H
C
C
In
any,
in
any
case
I
mean,
if
you
have
a
readable,
spanner
or
whatever
span,
and
one
of
your
attributes
is-
is
mutable,
for
example,
a
list
right
then
you
can,
and
let's
say
that
attribute
is
named
x.
Then
you
can
say,
span
dot
x
square
brackets,
3
equals
99,
and
now
you
have
changed
the
fourth
element
in
that
list.
B
B
C
That
fine,
I
don't
know,
I
don't
know
how,
because
now
that
you
mentioned
that
that
about
those
other
languages
not
needing
this
those
other.
Maybe
the
intention
of
this
is
to
make
sure
that
even
the
attributes
themselves
are
not
modifiable,
because
if
that
was
the
case,
then
it
will
make
sense
to
have
this
in
the
specification
for
languages
like
java.
Also
well,
the
this
is.
F
Yeah,
the
other,
the
other
way
that
I
can
imagine
this
being
useful
for
other
languages
that
that
have
this
check,
that's
implemented,
is
to
reduce
the
surface
area
of
what
exporters
can
have
access
to,
because
right
now,
if
you
were
to
pass
in
like
a
full
rewrite
span
which
you'd
still
be
able
to
call
like
set
attribute,
it
just
wouldn't
have
any
any
effect
right.
So
the
like
the
interface
around
this
would
still
be
confusing
for
anybody
who's
using
it
outside
of.
B
B
Okay,
that's
fair,
sorry,
diego
to
answer
to
address
what
you
said,
I'm
under
the
assumption
that
other
languages
are
like
strongly
typed
languages
has
already
implemented.
This
like
check,
spent
ended
kind
of
functionality
where,
if
the
user
tries
to
do
set
attribute
after
a
span
has
ended,
it
doesn't
do
anything,
it's
a
no
op,
so
if
they
already
have
that,
like
my
question
is
like,
why
would
they
need
this
to
be
created
after
the
span
has
ended
so
like?
B
C
Know
yeah,
but
but
how
because
I
mean
anything,
could
be
well.
C
Not
necessarily
I
mean
if
before
this
span
has
ended,
anyone
assigns
an
a
list
as
an
attribute
to
spam.
They
can
keep
modifying
that
list,
even
if
the
response
has
ended.
B
You
mean
like,
through
the
attribute,
accessing
or
like
through
our
api,
because
through
our
api
we
don't
allow
them
to
do
that
right
with
set
attributes.
We
don't
want
them
to
do
that.
H
Like
right,.
B
B
H
C
That
okay,
so
you
only
allow
set
attributes
to
be
called
with
non-ended
spans
yeah,
no,
no,
of
course,
but
with
attributes
that
belong
to
the
those
types
attribute
values.
Yes,.
H
C
So
yeah
sequence
is
one
of
those.
That
means
that's
immutable,
and
that
means
that
yeah
people
can
still
modify
the
the
attribute
itself,
but
maybe
that's
right.
What
I'm
trying
to
understand
here
is
if
this
specification
is
asking
us
to
make
sure
that
attributes
can't
be
modified,
meaning
that
we
should
not
have
any
kind
of
mutable
attributes
or
if
we
only
should
not,
should
protect
against
attributes
exist,
already
existing
attributes
being
set
with
new
values.
That's
that's
what
I
I.
B
Don't
know,
no,
I
don't
think
it's
either
of
those
it's
it's.
We
just
need
to
make
sure
that
within
our
api
surface,
which
is
set
attributes,
we
we
adhere
to
the
specs
so
like,
if
you're
talking
about
like
getting
the
mutable
sequence
and
then
adding
to
that,
like
that's,
not
within
our
api
surface
right,
it's
only
if
someone
does
set
attribute
and
the
string
is
like
the
key
to
the
mutable
sequence.
B
Oh
yeah,
we're
definitely
good
because,
like
like
that,
question
was
just
like
asking
why?
Why,
like
a
strongly
typed
language,
would
need
this
because
they
wouldn't
have
the
problem
of,
like
you
know,
being
able
to
access
anything
by
the
dot
property
thing,
but,
like
alex,
provided
a
pretty
good
reason
like
design
wise
and
like
usability
wise,
why?
We
would
why?
What
why
they
would
want
to
do
that
so,
okay,
yeah,
any
other
topics
about
this
conversation.
B
Yeah
so
be
it'd,
be
good
to
have
more
reviewers
on
this.
You
know
I'm
already
taking
a
look
at
it,
but
you
know
any
other
eyes
on.
It
would
be
good,
so.
J
Cool
later
just
a
question
here:
how
would
how
the
like
go
and
go?
How
would
they
be
able
to
prevent
using
that.
J
B
F
B
I
I'm
here,
hello,
hello,
everyone
yeah,
I'm
I'm
with
you
for
quite
a
long
time
since
zero,
nine
b0
release
and
every
time
with
my
test
application
I
had
to
just
you
know,
update
libraries
and
make
some
small
call
changes,
and
I
was
super
surprised
when
I
updated
from
016
b1
to
017
b0,
because
I
couldn't
find
any
any
spawns
any
traces.
I
I
also
found
that
my
application
is
not
it's
not
instrumented,
I'm
using
the
auto
instrumentation,
and
it's
only
a
few
few
http
servers
based
on
flask
and
one
client
on
the
request.
Library
and
a
few
things
came
out
that
the
the
first
one
responsible
for
lack
of
instrumentation
was
the
change
of
open,
telemetry
python,
tracer
provider
environment
variable.
B
Sorry
matt
before
you
go
on,
do
you
have.
I
I
B
Discussing
it
on
gator
right,
yeah
yeah,
it's
me:
okay,
yeah
yeah,
no
worries
no
worries
yeah.
So
for
people
who
haven't
been
following
that
conversation
like
it's
difficult
for
us
to
kind
of
like
kind
of
debunk.
E
I
B
With
you
right
now,
so
if
it's
either,
you
can
continue
the
discussion
in
getter
and
the
people
who
are
addressing
it
can
like
talk
about
it
with
you
right
now
or
you
can
open
up
a
specs
issue,
and
so
all
of
us
will
have
context
for
it
with
it.
Okay,
yeah,
okay,.
B
Briefly,
just
go
through
it
and
the
people
who
have
been
working
with
you.
Hopefully
during
this
call,
so
I
can
help
you
out.
I
Sure
sure
so
I
found
that
I'm
that
the
the
sdk
tracer
provider
environment
has
changed.
So
I
I
set
up
and
I
can
see
that
my
applications
are
instrumented
right
now.
I
can
see
that
because
of
I
have
a
trace
id
and
spam
id
injected
in
the
locks,
but
I
have
issue
with
exporting
the
spams,
not
even
otlp
jager
zipkins
are
not
working
at
all,
and
this
is
my
my
biggest
problem.
I
What
can
I
say
more,
I'm?
I
will
be
happy
to
to
share
this
on
the
guitar.
I
can
provide
exactly
the
repository.
It's
very
simple,
to
run
this
application,
just
a
two
three
comments,
and
maybe
someone
of
you
will
be
able
to
to
help
me
and
solve
solve
this.
B
Issue
yeah
sure
I
would
advise
just
opening
up
a
ticket
for
it
so
more
eyes.
Can
you
know
help
out
okay
and
stuff?
Okay,
yeah
getter
is
usually
used
for,
like
you
know,
if
we
could
quickly
help
you
solve
something
without
much
like
need
for
examples
or
like
walk-throughs
or
something,
but
if
it's
like
taking
too
long
for
you
and
gitter,
I
would
advise
opening
up
a
spec,
okay,
a
ticket
yeah
sure
cool.
Okay.
Thank
you.
Nice
thanks
nice.
So
that's
pretty
much
everything
we
have
the
agenda
today.
A
A
F
I
was
just
about
to
ask
that
as
well.
I
think
we,
I
think
we
should
instead
of
get
her
right
or
what
yeah.
I
think.
That's
that's
what
some
some
folks
are
moving
on
to.
A
Yeah,
I
think
they've
done
it
in
in.
I
know
they
happened
in
js
and
they
also
opened
one
up
in
the
spec,
the
discussions.
Okay,
we
got
plus
one
from
trigon.
B
Yeah,
nice
yeah.
I
have
no
issue
with
that.
I've
never
used
gear
discussion
or
github
discussions
myself,
but
yeah
like
if
we
have
enough
like
votes
for
it,
then
I'm
totally
okay
with
doing
that.
A
B
B
Yeah
we,
I
don't
think
we
have
anything
for
that,
yet
so
cool
nice,
any
other
topics
right
now.
A
I
have
something
if
nobody
else
does
something
that
might
be
quick,
yeah,
so,
oh
yeah,
so
we
have
like
type
annotations
in
the
sdk
but
they're
not
like
checked
in
rci
and
nor
are
they
like
published.
I
guess
so
since
they're
technically,
you
know
just
annotations.
A
I
don't
think
there's
much
like
compatible
compatibility
issue
with
publishing
them
later,
but
I
do
think
from
usability
perspective.
It'd
be
really
nice
if
our
sdk
shipped
with
some
type
of
annotations
for
users,
but
I
think
this
is
a
bigger,
bigger
project
than
like
something
we
could
do
in
the
next
week.
So
I
think.
B
I'm
pretty
sure
there's
an
issue
already
for
that
right.
I
think
you
created
that.
B
Yeah
yeah,
I
do
remember
something
like
that
and
then
I
think
we
did
discuss
that
it's
like
yeah.
We
definitely
want
this,
but
since
it
won't
be
breaking
anyone
like
given
our
timeline,
I
think
it'll
be
difficult
to
add
it
within
next
week.
So.
B
Yeah,
but
definitely
you're
right,
like
we
do
need
to
expand
it
to
our
sdk
surface
as
well.
B
B
B
Okay,
cool:
if
there
is
nothing
else
we'll
end
early
today
and
we'll
see
you
guys
next
week,.
E
If
you
wouldn't
mind,
I
did
have
a
quick
one.
I
was
just
wondering
if
you
guys
discuss
the
contrib
repository
in
this
group
at
all.
B
We
do
like
we're
we're
owners
of
that
as
well.
We
just
didn't
see
much
at
least
for
our
side.
That
is
very
pressing
matters,
but
if
you
have
something
that
you
want
to
bring
up
and
talk
about,
feel
free.
E
Yeah
just
wondering
the
process
of
getting
stuff
stuff
merged,
there's
a
lot
of
a
lot
of
prs
and
there's
a
lot
of
it
seems
like
there's
a
lot
of
changes
made
to
the
the
automation
around
the
checks
and
things
like
that.
That
aren't
really
clear
what
breaks
yeah.
I've
got
a
couple
pr's
that
have
just
been
open
for
a
while
zoning.
If
I
can
help
those
move
along,
it's
really
my
question.
B
Yeah
yeah
great
question,
I
think
recently,
like
a
lot
of
our
focus,
has
been
trying
to
get
to
1.0.
So
I
guess
next.
B
Yeah,
like
me
personally,
I
haven't
been
like
grooming,
the
the
country
repo
as
like.
I
usually
do,
but
definitely
like
you
know
once
like
past
next
week.
It
should
be
very,
very
more
active
but
like
in
the
meantime,
if
you
could,
like
you
know,
maybe
list
out
your
pain
points
and
like
a
like
an
issue
somewhere
it'd
be
easier
to
address,
so
we
can
like
have
a
plan
for
you.
Maybe.
E
Yeah,
I
think
yeah
I've
got
a
couple
issues
with
a
couple
of
pr's
for
the
issues,
and
I
was
just
wondering
like
what
the
timing
was.
I
didn't
realize
that
we
were,
you
know,
rushing
to
get
a
1.0
done,
so
that
makes
a
lot
of
our
rc
don.
That
makes
a
lot
of
sense
right,
but
just
going
forward
I
was
I
was
wondering
like
what
the
kind
of
expectations
on
that
sort
of
thing
were.
E
You
know
mostly,
I
I'm
someone
who
uses
a
bunch
of
the
contrib
things,
and
so
you
know
helping
with,
or
at
least
looking
into
like
the
main
library
is
great.
But
if
I
don't
have
anything
if
the
contrib
stuff
isn't
working,
then
my
you
know,
interaction
with
the
main
library
is
going
to
be
really
limited
because
nothing.
E
C
Was
blocking
several
other
pr's
that
got
merged
just
late
yesterday,
so
maybe
that
was
also
blocking
or
causing
one
of
your
pr's
to
fail.
So
I'll
suggest
that
maybe
take
a
look
at
it.
E
Yeah
this
looks
like
I
mean
if
we're
talking
about
the
failures
it
looks
like
this.
It's
I
think
this
one
was
doc's
test
and
something
definitely
got
changed
in
that.
So
maybe
it's
just
a
matter
of
of
merging
from
the
base
and
it
says
something
but
failed
to
import
django.
I
didn't
really
look
into
that.
E
Yet
yeah
it
yeah
just
it
seems
like
you
know,
these
have
been
sitting
the
ones
I'm
looking
at
have
been
sitting
since
december
and
again,
I
know
the
timing
of
this,
but
like
every
time
I
go
and
look,
something
else
has
changed.
It
causes
things
to
break
again
and
I
have
to
go
back
and
you
know
fix
stuff
that
wasn't
really
clear.
Why
was
the
where
the
priorities
that
things
were
so
you
know
I
want
to
like
help
as
much
as
I
can
here.
F
I
think
the
probably
the
best
thing
to
do
and
by
the
way,
thanks
for
adding
the
comment
there,
I
did
review
the
prs
yesterday
and,
unfortunately,
the
changes
that
did
break
because
of
that
other
pr.
But
I
think
the
best
thing
to
do
is
probably,
to
just
like
add
the
like,
come
to
the
seg
meetings
and
add
them
to
the
list
of
pr
that
you'd
like
to
get
reviewed,
and
that
way
you
can
just
kind
of.
Hopefully
we
can
get
some
people
assigned
like
reddit
right
then,
and
there
yeah.
F
C
No
because
we
merged
the
the
fix
for
the
configuration
problem.
C
So
well,
I
just
sent
your
tests
to
run
again,
see:
let's
see
what
happens:
okay,
I'll,
take.
C
A
Yeah
yeah,
thanks
for
the
feedback
and
thanks
for
helping
out
yeah,
yeah
yeah
real
concerns.
E
B
A
Guys
do
we
have
a
plan
for
like
1.00
the
contrib
packages,
because
I
don't
think
we've
come
through
those
for
like
semantic
convention
compliance
for
instance,
so
it
would
be
a
break
okay.
So
is
the
plan
to
do
that
later.
B
Yes,
because
first,
I
think
semantic
conventions
haven't
even
been
marked
as
stable,
yet
so
yeah
we'll
be
waiting
on
that
and
then
we'll
do
like
our
rc
compliant
pass-throughs
afterwards.
So
yeah
yep
good
question.
B
Okay,
cool,
I
guess
that's
pretty
much!
It
I'll
see
you
guys
next
week.