►
From YouTube: 2021-09-17 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
A
B
B
A
It
also
was
like
nice
and
cool
yesterday
and
then
it's
now
back
to
blazing
hot.
So
you
know.
A
Yeah,
so
I'm
in
austin-
and
you
know
with
the
hurricane
that
hit
houston,
it
brought
a
bunch
of
like
cloud
cover
and
kind
of
cooled,
the
area
off
and
then
today
it's
back
in
the
90s
and
it's
like
it's
a
little
humid
and.
B
Yeah,
no
yeah,
that's
that's
kind
of
the
worst!
For
this
time
of
year
I
kind
of
enjoy
the
cool
weather
the
most
it
just
got
really
cool
last
night,
so
I'm
a
big
mycology
fan.
So
I
end
up
mushrooms
so
we're
getting
into
that
mushroom
temperature.
So
I'm
pretty
excited.
B
Yeah
I
mean
like
pretty
much.
I
just
enjoy
mushrooms
yeah,
so,
like
yeah
do
a
lot
of
foraging
for
mushrooms
to
eat.
I
would
love
to
grow
more
mushrooms,
but
it's
kind
of
hard
to
do.
B
Turns
out
the
pacific
northwest
is
a
great
place
for
that
kind
of
of
a
passion.
Yeah
well
they've
got
some
really
interesting
stuff
in
the
texas,
especially
austin
area.
There's
some
really
cool
mushroom
species.
There.
B
Okay,
look
at
that.
We
are
five
participants.
Okay,
steve
harris
can
only
listen
today,
10-4.
I
don't
think
this
is
going
to
be
a
too
long
of
a
meeting,
but
we
could
probably
open
up
the
attendees
okay.
B
Yeah
there
we
go
got
josh
on
here.
I
think
he's
the
last
person
I
wanted
to
have
on
the
meeting
before
we
start.
Okay
cool,
I
think
rich,
would
also
be
really
good,
but
we're
just
gonna
have
to
go
with
what
we
got.
Let
me
start
sharing
and
we
can
jump
into
the
meeting.
B
Cool
so
yeah
as
normal.
I
don't
think
anybody
on
here
wouldn't
know
this,
but
if
you
haven't
yet
added
yourself
to
attendees
list,
please
do
so.
If
you
have
anything
you
want
to
talk
about
on
the
agenda,
please
add
it
to
the
agenda
and
we
can
jump
into
it.
B
As
far
as
I
can
tell,
there's
really
only
one
thing
to
talk
about
that's
currently
listed,
but
there's,
I
think,
there's
probably
some
more
just
stuff
to
talk
about
in
the
afterwards.
One
of
the
final
things
is
like
we're
positioned
right
now
to
get
the
1.0
out.
I
think
we
talked
about
this
last
week
as
to
what
that
was
and
getting
feedback,
I
think,
was
kind
of
the
goal.
B
I've
talked
with
a
few
people
asynchronously
outside
of
the
meeting,
and
I
think
that
the
idea
is.
I've
asked
people,
people
for
reviews,
everyone's
super
busy,
which
is
completely
fair,
but
I
think
that
the
ones
that,
like
really
matter,
are
people
that
are
on
the
call
or
just
approvers
in
general,
so
I
have
a
proposal
to
make.
This
is
included
for
the
agenda
option
or
agenda
item
here.
I
just
updated
this
recently.
B
The
ticket
that
was
originally
titled
get
feedback
on
the
rc1
release.
I
think,
can
just
be
re-titled,
because
I've
asked
I've
gone
around
asynchronously
and
asked
people
for
this
feedback,
but
I
would
like
it
if
we
could
have
everyone
who's
an
approver,
and
everyone
is
a
maintainer
specifically
comments
on
this
issue,
saying
if
you
signed
off
on
the
fact
that
we're
ready
for
the
civil
release
or
if
you
have
identified
issues
that
you
wanted
to
make
sure
that
we
address
before
that
release
is
made.
B
Also,
I
would
love
to
hear
those
sort
of
things
and
anthony's
already
rocking
it
over
here.
Okay,
that
includes
myself
and
anthony,
so
it
looks
like
anthony's
already
there,
I'm
gonna
go
with
the
rocket
because
that's
way,
cooler
yeah,
but
I
think
that,
like
everyone
who's
on
the
list
as
an
approver,
I
would
love
to
get
their
response
on
here.
I'd
like
to,
I
think,
timeline
wise.
B
I
think
we
would
really
like
to
get
this
out
tomorrow-
would
be
kind
of
pushing
it,
but
early
next
week
I
think,
would
be
kind
of
like
ideal
if
everyone
signed
off
on
it.
I
don't
know
if
anthony
you
had
some
other
ideas
on
timelines
as
well.
I
know
that
that's
something
that's
important
to
you.
C
B
Okay,
yeah
and
I
think
that's
totally
reasonable.
In
fact,
this
being
a
short
meeting,
I
imagine
well,
I
imagine
it
being
a
short
meeting.
Everyone
on
this
list,
I'm
guessing,
could
add
chip
in
and
sign
off
on
this.
I
think
the
really
the
important
thing
is.
I
really
want
anybody.
Who's
contributed
to
the
project
to
sign
off
on
this.
That's
why
I've
listed
people
on
this,
but
I
also
want
to
make
sure
that
we
have
coverage
for
the
companies
that
are
interested
in
the
projects.
B
So
I
think
there's
only
company
I
don't
see
here
listed
by
approvers
is
going
to
be.
The
relic
is
the
only
other
contributor,
but
I
can
I
can
paint
them
asynchronously
just
to
make
sure
they
sign
off
on
it,
but
otherwise
yeah.
I
think
if
that's
it,
I
I
would
really
love
for
that
from
everybody
on
the
community
and
once
that's,
I
think,
done
we
can
close
that
and
then
we're
good
to
go.
B
I
think
that
that's
a
1.0
is
going
out
the
door
which
is
intense
to
say,
but
yeah
I'm
excited
about
it.
B
Okay
and
josh,
I
see
you're
on
the
call,
if
you
could
ping
gustavo
or
maybe
just
say,
you're
also
vouching
for
him
from
the
light
set
perspective.
If
you
want
to
comment
on
this,
I
really
appreciate
it.
D
Yeah,
I
was
just
checking
with
lightsteppers,
but
I
will
I
will
gather
at
least
one
other
voice
and
ping.
This
issue.
B
Okay
yeah,
I
picked
ted
but
of
course
he's
out
this
week
so
he's.
B
So
yeah,
I
would
appreciate
that
thanks,
okay,
I
think
with
that,
that's
about
it.
I
wanted
to
maybe
touch
josh.
I
know
that
you've
been
pretty
active
on
this
pr
here.
D
I
will
respond
to
any
feedback
immediately
as
quickly
as
I
can.
I
see.
Aaron
has
put
some
up
and
I
just
saw
it
so
I
will
get
to
that.
I
feel
so
conflicted
here.
This
is
a
huge
pr
and
I
don't
like
it,
but
I've
thought
of
the
alternatives
and
I'm
just
not
comfortable
with
them
either.
If
anyone,
if
anyone
was
calling
to
like
throw
this
sdk
out
and
start
over
from
scratch,
I
would
listen,
but
I
I
myself
am
not
going
to
make
that
call.
D
So
I'm
I'm
going
to
press
forward
with
what
we
have
refactoring
is
never
fun.
This
is
just
particularly
like
a
worst
case
because
it
crosses
an
api,
sdk
boundary,
and
I
I
was
discussing
alternative
approaches
here.
The
alternatives
would
have
been
long
and
ugly
as
well.
I
I
don't
know
that
there
was
a
good
outcome
here
and
I've
thought
of
like.
Should
we
take
this
out
of
the
sdk
revit
and
then
bring
it
back
with
a
single
review.
B
That's
a
good
question:
I'd
love
to
hear
people's
name
in
that
one.
A
So
the
only
alternative
I
I
really
saw
to
doing
something
like
this
was
to,
like
you
said,
create
another
revision
or
like
add
on
to
our
current
sdk,
in
kind
of
a
alternative
path
and
then
eventually
deprecate
the
old
methods.
But
I
think
at
this
point
with
metrics
being
unstable,
I'm
somewhat
okay,
breaking
anybody,
who's
relied
on
them
because
we've
been
having
turn
on
them
and
it's
it's
holding
us
back
as
well
from
actually
delivering
something
that
is
better.
D
The
there
was
an
issue
filed,
that's
talking
about
pulling
the
sdk
types
into
its
own
package
as
a
means
of
let
letting
us
explore
a
completely
new
api,
and
at
least
I
mean
what
I
said
was.
This
is
a
worst
case
because
it
crosses
that
boundary
that
I
believe
is
fairly
good,
so
that
in
the
future
I
hope
a
refactoring
won't
require
touching
both
the
api
and
the
sdk.
This
this
was
sort
of
the
worst.
D
I
do
think
that
we
should
keep
changing
the
interface
and
the
the
net
there's
this
issue
about
streamlining
the
otlp
export
path,
and
you
can
see
anywhere
that
otlp
exporter
is
doing
work.
That
seems
unnecessary,
I'm
trying
to
get
rid
of
it
and
it's
not
it's
not,
because
I'm
really
trying
to
optimize,
because
I'm
that
that
makes
the
interface
feel
right
to
me.
So
the
last
of
these
disruptive
refactorings
for
the
oclp
export
path
to
be
streamlined
would
be
yet
another
change
of
this
nature,
but
it
wouldn't
touch
the
api
this
time.
D
It
would
be
to
take
that
for
each
that
currently
gives
you
one
export
record
and
make
that
yet
another
level
of
iteration.
So
that
you,
when
you
iterate
through
one
instrumentation
library,
you
get
one
metric
at
a
time
and
then
it
gives
you
a
list
of
points
with
each
attribute
set,
which
will
then
avoid
a
final
set
of
grouping.
D
That's
happening
in
the
otlp,
where
you
map
vitamins
by
instrument
name,
you
shouldn't
have
to
do
that,
so
that
it's
that
kind
of
detail-
and
it
is
hard
to
change
that
kind
of
detail
when
you
have
three
or
four
exporters
built
and
and
then
it's
it
was
worse
than
that
because,
like
there's,
just
a
lot
of
tests
and
tests
often
get
the
short
end
of
a
refactoring.
D
D
So
you
see
some
of
that,
even
in
this
big
pr,
where
the
the
new
style
of
writing
a
test
from
the
metrics
sdk
is
to
just
use
the
sdk
to
generate
some
instruments,
use
the
sdk
to
generate
some
export
records
and
so
on,
rather
than
having
this
ugly
path
of
constructing
descriptors,
which
is
all
changing
right
now.
So
it's
just
a
really
unfortunate
case.
A
Yeah,
I
noticed
that
bulk
of
the
pr
was
just
tests
and
I
kind
of
breezed
through
those
which
is
how
I
was
able
to
actually
review
it.
D
Yeah,
I'm
sort
of
asking
for
some
trust,
and
I
don't
feel
like
this
should
happen
much.
It
shouldn't
happen,
often
because
we're
in
an
unstable
situation,
I
feel
like
it's
on
the
borderline,
but
this
would
not.
This
would
not
pass
in
a
stable
code
base,
but
it
just
shows
how
unstable
it
was,
but.
E
D
Yeah
definitely
so
I've
seen
more
feedback
if
we
think
we
can
get
through
this
one.
I
think
it's
never
gonna
happen.
This
type
of
awfulness
won't
happen
again.
It
doesn't
seem
like
it's
possible.
Otherwise,
I
just
don't
see
it.
Then
I
would.
D
I
would
go
ahead
and
immediately
volunteer
to
do
the
upgrade
in
the
go
contrib
directory,
which
will
take
some
more
wrangling
like
the
last
release
and
then
just
continue
on
the
path
which
would
be
to
move
that
descriptor
type
into
the
sdk
api
directory
and
then
continue
on
that
thread
of
separating
the
two
and
that
we
that
will
leave
us
in
a
point
where
take
it
or
leave
it.
The
current
api
is
pretty
close
to
the
hotel
api
spec.
D
We
are
still
ironing
out
details
in
the
metric
sig
about
like
observer
instrument,
registration
and
what
happens
when
you
have
duplicates
and
stuff
like
that's
the
level
of
detail
where
this
that's
the
current
api
might
differ
and
where
we
might
want
to
change
it
for
any
number
of
reasons,
and-
and
it's
also
coming
down
to
a
debate
about
just
this
bound
instrument-
api
style-
which
I
personally
don't
really
like,
even
though
I
put
it
in
there.
I
just
don't
think
it's
that
valuable
anymore.
That's
up
for
debate
as
well.
D
The
java
sig
has
it
the
prometheus
library.
Has
it
people
say
it's
important,
so
I
don't
see
it
going
away,
but
it
is
responsible
for
like
a
double
surface
area
which
which
makes
it
hard
to
take
so
that
that
will
be
debated
at
the
hotel
group,
and
I
think
what
we'll
end
up
with
is
saying
that
each
sig
gets
to
decide
for
its
language
what
it
wants,
and
I
will
take
it
or
leave
it.
I
know
the
prometheus
library
has
it
and
that's
why
we
thought
it
was
so
important
up
front.
E
D
That
that's
kind
of
what
it's
about.
It's
not
a
huge
one
and
I
could
go
out
back
and
look
at
the
benchmarks,
but
the
cost
of
constructing
a
label
set
is
generally
like
order
of
microseconds
and
then
the
cost
of
performing
the
update
is
order
of
nanoseconds,
and
so
like
you,
you
can
make
your
metric
operations
significantly
faster,
but
only
when
you've
got
the
code
and
the
piece
of
state
in
the
right
place
to
do
to
store
the
thing,
and
you
don't
have
unlimited
cardinality
and
there's
all
kinds
of
constraints
on
it.
D
So
and
then
what
people
point
out-
and
this
is
sort
of
its
weakness-
is
that
it's
great
until
the
moment
when
you
want
to
take
something
dynamic
from
the
context
like
baggage
or
or
have
a
handler
that
has
result
code,
that
maps
into
a
particular
attribute
and
now
you're
constructing
your
attribute
very
close
to
the
end
of
your,
like.
You
can
still
try
to
defer
your
attribute
set
construction,
but
it's
going
to
cost
you
something
eventually
and
very,
very
rarely.
I
think.
D
Do
you
end
up
being
able
to
fully
build
static,
attribute
sets,
and
that's
the
only
case
that
this
instrument
that
this
up,
that
this
optimization
currently
helps?
And
then
you
can
imagine
you
can
really
imagine
how
to
get
the
optimization
back
and
you
can
go,
find
examples
of
people
who've
done
it
and
go
or
other
libraries
where
well.
I've
got
an
attribute
set,
and
I
just
want
to
add
one
item
to
it.
So
now
make
me
a
fast
path.
D
D
The
optimization
there
is
to
use
this
sized
array
as
your
key,
a
variable
sized
array
as
your
interface
value,
which
is
which
cut
down
the
cost
of
building
an
attribute
set
in
half,
as
I
recall,
from
the
benchmarks,
but
still
there
is
still
a
performance
benefit,
it's
just
not
huge
compared
to
just
just
doing
it.
That's
why
I
don't
really
care.
E
D
I
will
always
do
what
a
reviewer
asks
and
I
think
it's
helpful
if
you
got
if,
if
we're
all
in
it,
like
we're
all
invested
in
this
code,
I'm
trying
to
make
it
better
and
I
but
but
it
doesn't
work
if
I'm
the
only
one
who
knows
it.
So
I
don't
think
you're
wasting
your
time
to
review
and
even
looking
at
some
of
the
tests,
it'll
either
look
like
some
search
and
replace
was
done,
which
is
really
easy
to
review
or
it'll.
D
E
D
D
Okay,
good,
that's
a
real
use
case
and
I'll
be
sure
to
handle
the
go
contrib
stuff,
I'm
sure
there's
some
explorers
there
that
will
need
change,
but
they
won't
be
complicated.
C
Yeah,
so
on
on
that
topic,
can
I
ask
that
we
defer
merging
this
until
after
we
ship,
1.0
and
sequence
it
so
that
we
ship
1.0,
update
contrib
to
1.0,
merge
this
and
we
can
ship
a
release
immediately
after
and
update
trim
so
that
we
we
get
a
contrib
release
that
has
1.0,
updated,
asap
and
and
then
move
on
from
there.
B
Cool
yeah
that
makes
sense.
Okay,
go
back
to
the
agenda,
so
nothing
on.
There
talked
about
the
metric
stuff,
one
I
think,
maybe
follow-up.
From
last
week
I
opened
up
a
pr
in
the
contrib
repo
to
kind
of
outline
our
instrumentation
policy.
B
If
you
haven't
seen
this
yet,
please
take
a
look.
This
is
outlining
kind
of
what
we
talked
about
last
week.
Just
wanted
to
put
this
forward.
It's
just
it's
refactoring
a
little
bit
contribute
which
is
helpful.
I
think
it
helps
in
the
flow
and
it
adds
as
part
of
that
refactor,
what
we're
actually
doing
for
instrumentation
and
like
the
guidelines
that
we
have
where
instrumentation
should
be
stored.
If
you
have
some
time,
please
check
it
out.
B
I
anticipate
that
this
is
going
to
be
a
next
hot
area
of
development
once
we
have
a
stable
release
out,
so
I
want
to
make
sure
that
we
have
really
good
guidelines
for
developers
as
to
where
they
can
put
their
code
and
what
that
what
the
procedure
is
and
I'll
be
honest.
After
reading
this,
this
is
the
first
thing
that
I'd
probably
change,
there's.
B
Definitely
a
lot
of
documentation
work
that
I
think
we
can
do
to
help
developers
after
we
get
a
stable
release
out,
one
of
which
is,
you
know,
helping
give
guidelines
as
to
what
is
good
instrumentation.
I
think
we've
done
a
little
bit
in
here,
and
I
think
that
some
of
it
is
also
like
some
of
it
stood
out
is
so
horribly
wrong
that
both
anthony
and
myself
had
to
fix
certain
things
of
certain
parts
of
the
instrumentation
section,
because
they're
just
we
need
they
need
to
be
updated.
B
So
I
think
if
there's
like
some
work
to
come
here,
but
we
want
to
make
sure
that,
like
we
have
are
starting
on
the
right
foot,
at
least
so,
if
you
have
some
time,
it's
not
blocking
the
stable
release,
but
I
think
it'd
be
really
helpful
to
get
this
in
place
and
we
can
also
clean
up
the
control
repo,
the
outstanding
prs.
B
I
was
just
looking
at
some
that
are
from
2020
still
so
that
makes
me
feel
really
bad
as
a
maintainer,
and
so
I
want
to
help
try
to
clean
this
up
and
rip
the
band-aid
off.
If
you
will
outside
of
that,
I
don't
think
I
have
anything
else
we
want
to
talk
about
or
that
I
have
scheduled
to
talk
about.
I
definitely
am
open
to
asking.
If
anybody
else
has
anything
we
want
to
talk
about.
B
Cool
seems
kind
of,
like
I
pinged
a
few
more
people
on
slack,
try
to
follow
up
on
the
stable
release
issue
that
I
mentioned,
but
I
think
the
last
thing
on
the
general
meeting
agenda
the
higher
order,
meta
one
is,
if
there's
any
good
user
stories
I
know.
Last
week
there
was
people
kind
of
like
humming
and
hawing
as
they
were
working
on
some,
maybe
some
project
ideas.
I
don't
know
if
they
came
to
fruition.
B
Okay,
that's
some
really
good
silence,
we're
pretty
good
at
meditating
in
this
group
of
what
I'm
getting
okay,
that's
it!
I
think
that
we
could
probably
end
it
here,
23
minutes
in
which
means
you
have
so
much
time
for
those
that
haven't
already
commented
on
the
issue
to
go
comments
on
the
issue
where
you
josh's
pr,
which
I
know
that
you're
just
all
chomping
a
bit
to
do
well
cool.