►
From YouTube: 2021-05-26 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
C
D
E
C
F
E
E
we're
currently
in
the
process
of
updating
and
releasing
core
so
that
it
can
use
this
api
20
version
until
the
api
goes
to
1.0
we're
going
to
try
to
keep
the
api
and
the
core
repository
versions
the
same
once.
The
api
goes
to
1.0.
It
won't
matter
as
much
because
the
api
won't
change,
but
we
will
talk
about
that
a
little
bit
later,
because
we're
fairly
close
to
that
one
quick
thing,
I
can't
run
the
browser
tests
locally.
E
G
B
E
In
the
contrib
repository,
no,
it's
just
main
in
the
main
repository.
So
what
operating
system
are
you
on.
E
D
H
B
E
I
don't
think
so,
because
I
have
done
a
complete
like
fresh
checkout
on
core
and
the
ci
has
had
the
cash
break
a
handful
of
times
recently.
You
know
it
regularly
downloads
new
versions
and
continues
to
work
in
the.
E
D
E
Multiple
versions
so
working
on
windows
working
on
linux.
Is
there
anyone
anyone
who
has
a
mac
that
it
is
working
on
or
anyone
who
does
has
windows
or
linux?
That
is
not
working
on.
E
Yeah,
it's
just
npm
run
test
colon
browser,
I'm
going
to
create
an
issue
for
it
and
just
have
various
operating
systems.
Please
report
their
results
on
the
issue.
I
would
appreciate
that.
E
So
let
me
yes
I'll
just
create
the
issue
now,
while
we're
on
a
call
so
that
I
don't
forget
it.
D
E
Do
okay,
so
here's
an
issue
for
it.
I
will
here
and
I
just
would
appreciate
anybody
that
can
report
whatever
results
they
can
get.
If
it
turns
out
that
it's
only
broken
on
a
mac,
we
may
be
able
to
work
around
it
somehow
yeah.
Hopefully
we
can
fix
it,
but
right
now
I
think
we
just
need
to
gather
more
data.
I'm
particularly
looking
for
people
with
macs
to
see
if
anyone
has
a
mac
that
it
works
on.
E
Okay,
so
the
core
has
been
updated
to
use
the
latest
api.
Thank
you
bart.
I
believe
that
the
only
thing
blocking
the
current
core
release
is
the
start
active
spam,
poorer
class.
Does
anyone
else
know
of
any
other
pull
requests
in
core
that
should
block
a
release.
E
I'm
going
to
take
silence
as
no
naseem.
Are
you
on
the
call
or
not?
No?
Okay?
The
implementation,
I
think,
is
good,
but
he's
having
issue
with
the
tests
so
hopefully
should
be
resolved
fairly
soon,
and
when
that
merges,
I'm
going
to
release
a
new
version
of
the
car
repository,
unless
anybody
has
a
reason
that
I
shouldn't.
H
About
the
tests,
I
said
that
in
the
in
the
in
one
of
the
pr,
I'm
not
sure
if
it's
the
api
on
the
other
car
one,
but
I
think
the
since
the
by
default,
the
basic,
not
the
basic
tracer
tracing
provider,
doesn't
have
any
context
manager
available.
H
It's
used
no
upcontext
and
obviously
the
test
cannot
work
with
this
setup.
I
I
can't
find
back
the
comment
if
you
want
yeah.
E
There
is
a
test,
oh,
like
a
stack
context
manager,
that's
just
a
very
basic
non-async
stack
manager,
so
it
was
already
in
there
for
testing.
For
this.
E
It
might
work
okay,
it
looks
like
he's
seen
it,
but
I
don't
see
any
update
to
actually
use
it.
Yet
so
we'll
see
if
it's
okay.
E
Yeah,
so
it
looks
like
yeah,
okay.
Well,
in
any
case,
I
think
that's
the
only
pr
that's
blocking
and
it
is
in
need
of
reviews,
because
it's
blocking
the
core
release.
I
would
appreciate
it
if
people
would
review
it.
E
E
E
So
these
two
pr's,
I
would
appreciate
it
if
they
get
reviewed
they're,
mostly
testing
changes,
but
one
of
them
does
change
the
tracing
package
also
fairly
minor
change,
though
so
it
should
be
relatively
straightforward
to
review.
E
E
Okay,
there
is
one
more
core
pr
from
the
spec
review.
Resource
needs
to
have
service
dot,
name.
E
Has
to
be
set
like,
according
to
the
specification
it's
required,
so
I
created
a
pr
to
ensure
that
the
service
dot
name
is
always
set,
but
one
question
that
I
we
sort
of
ran
into
is
when
the
user
has
not
specifically
set
a
name
with
an
environment
variable
or
configuration,
or
something
like
that.
What
should
we
do
so
in
my
current
pr,
I
attempt
to
find
the
package
jason
of
the
calling
program
and
find
the
name
of
the
program
from
that
and,
if
that
fails,
I
use
the
the
command
line
name.
E
You
know
the
the
the
name
of
the
program
that
ran
so
typically
it's
node
or
something
like
that
as
a
fallback.
The
question
is:
is
that
too
complex?
Should
we
just
fall
back
to
some
string
and
call
it
a
day?
E
G
E
Yeah,
that's
what
I've
seen
in
some
others.
I
know
at
least
python
I
think
was
doing
that
and
I
think
I
ruby
was
also
doing
that,
although
I
think
ruby
may
have
changed
to
use
the
the
command
line.
Names
like
the
process
command
line,
but
I'm
not
sure
is
matt
on
the
call
he
would
know
no.
E
D
E
No,
I
I
don't
think
it's
the
same
as
what
we
had
before,
because
we
were
trying
to
get
the
version
of
of
the
sdk,
not
the
version
of
the
end
users
program
right.
That
was
a
different
problem
that
we
were
solving.
A
E
E
Fall
back
on
unknown,
so,
if
everything
fails,
it
does
fall
back
on
a
string.
It
won't
throw
or
anything
like
that.
But
the
question
is:
is
it
if
it
doesn't
throw
but
comes
up
with
the
wrong
string?
E
E
Yeah
once
at
startup,
okay
yeah-
I
know
because
it
does
like
synchronous,
stuff
yeah,
so
it
does
have
some
performance
penalty,
but
yeah
it's
only
run
one
time
at
startup.
So
I
think
that
that's
probably
okay,
although
if
anyone
disagrees
with
that
assessment,
I
am
willing
to
willing
to
be
convinced.
I
I
E
I
Yeah,
I
might
my
vote-
would
be
just
to
go
with
the
string
rather
than
trying
to
be
smart,
because
if
they,
if
they
try
and
run
in
some
other
environment
that
doesn't
support,
it's
just
gonna
fall
back
to
that
anyway.
We're
just
gonna
burn
cycles
for
no
reason.
E
Yeah,
okay,
so
I'll
I'll
change,
the
pr
to
just
use
a
string
I
like,
if
we
want
to
add
some
sort
of
fancy
detection
later
users
ask
for
it
then
great,
but
for
now
I
guess
nobody's
really
asking
for
it.
So
there's
no
reason
to
try
to
to
be
too
smart
to
potentially
keep
it
wrong.
I
E
Okay,
I
think
we
sort
of
already
touched
on
the
start
active
spam
pr,
but
it's
in
need
of
reviews.
So
please
review.
G
E
This
past
week
we
removed
prettier
from
our
linting
prettier,
implemented
a
rule
that
we
didn't
agree
with,
and
it
turns
out
because
of
the
philosophy
of
the
prettier
project.
It
was
not
configurable
sort
of
on
purpose
and
because
we
wanted
control
over
that
we
removed
prayer.
E
I
E
But
in
my
opinion,
having
control
over
our
own
mental
roles
is
worth
it,
so
I
just
so,
you
guys
aren't
confused
or
surprised
when
things
that
previously
were
auto,
fixed,
can't
be
or
they're
fixed
in
a
different
way
or
something
like
that.
That's
the
reason.
E
There
are
two
final
prs
in
the
api
that
are
breaking
changes
before
we
can
go
to
1.0
the
first
one
we're
waiting
on
an
opinion
from
the
tc.
So
I
won't
talk
about
that
one
right
now.
E
E
E
We
will
probably
release
one
more
minor
version
like
21
or
something
like
that,
and
then
sometime
shortly
after
that,
we
will
release
1.0.
There
will
be
time
for
people
to
object
before
we
do
that.
E
It
looks
like
somebody
added
a
pr
down
here
that
needs
reviews
anybody
else
that
has
open
prs.
If
you
feel
like
they're,
ready
for
review
and
they're,
not
receiving
reviews,
please
add
them
to
this
list.
I
will
make
sure
to
review
any
pr's
that
are
added
to
this
list
today.
So,
even
if
you've
added
after
the
meeting,
I
will
I'll
look
back
at
this
list
today.
J
Today,
yeah
hey,
I
have
a
question
about
the
contribution.
Instrumentation
releases
do
all
of
them
have
to
be
released.
At
the
same
time,.
E
E
J
But
do
we
have
some
kind
of
release
cadence,
so
is
it
like
once
a
month
or
once
every
two
weeks.
E
There
is
no
official
release
cadence
we
try
to
release
regularly.
Most
of
the
time
we
release
when
somebody
bugs
one
of
the
maintainers
and
says
hey,
I'm
waiting
on
this
fix,
that's
been
merged.
Can
you
please
release
it?
I
think
if
we
want,
we
can
try
to
come
up
with
a
release.
Cadence,
I
would
say
once
every
two
weeks
probably
sounds
fair,
but
no
we
don't.
There
is
no
official
policy
right
now.
E
Yeah
two
weeks
is
probably
a
little
bit
too
slow
once
we
have
more.
Ideally,
I
would
say
we
would
release
on
every
horror,
blessed
merch,
but
then
that
would
depend
on
you
know.
How
do
you
there
there's
no
way
to
auto
detect
whether
a
change
is
breaking
or
not?
E
So
do
you
bump
the
patch
version,
the
minor
version
or
the
major
version,
so
there
will
need
to
be
some
manual
touch,
which
means
we
can't
do
it
on
every
pull
release
on
every
full
request,
but
I
think
we
should
try
to
release
more
quickly
will
spend
a
bunch
of
time
coming
up
with
a
nice
release,
automation,
workflow.
That
seems
to
work
pretty
well
and
the
whole
point
of
that
was
to
make
releasing
faster.
E
So
if
we
don't
make
releasing
faster,
then
we're
letting
his
work
go
to
waste,
and
I
don't
want
to
do
that.
E
I,
this
is
a
very
short
answer
to
the
question
I
can
try
to
release
contrib
later
today.
If
you're,
it
sounds
like
you're
waiting
on
a
on
some
release
and
as
a
more
general
answer,
I
will
try
to
at
least
release
every
two
weeks,
if
not
faster
than
that.
E
Okay,
thank
you,
everybody
for
your
time
and
hopefully,
next
week
we
can
release
the
api
1.0
so
make
sure
not
to
miss
it.