►
From YouTube: 2021-01-27 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
Yeah
mostly
because
it's
terrible,
I
think,
oh,
we
should
put
in
the
agenda
what
the
passcode
is
in
case.
People
don't
know.
B
I
will
have
a
hard
stop
at
one
o'clock
by
the
way
today
I
might
even
have
to
leave
early,
so
I
apologize
if
that
happens,
but
I'm
having
my
kitchen
redone
and
the
contractor
called
me
half
an
hour
ago
to
say
that
he
was
gonna
show
up
around
one
which
could
mean
anything.
So,
oh
that
means
1,
30,
yeah
or
12
15.
A
B
Is
anybody
getting
in
on
the
the
gamestop
stock
explosion.
B
I
don't
know
bart
if
you're
familiar
with
gamestop,
but
it's
a
it's
essentially
a
failing,
video
game
retailer
in
the
us.
That's
pretty
popular
or
was
pretty
popular,
but
in
recent
years
you
know,
selling
physical
video
games,
I
think,
is
a
business
model
that
will
be
relegated
to
the
past
eventually,
but
for
some
reason
a
so
one
of
an
investing
subreddit
decided
to
essentially
blow
up
the
stock
because
it
was
shorted
by
a
bunch
of
hedge
funds,
and
I
mean
what
is
it
last
I
looked.
B
B
Looks
like
matt's
not
here
yet,
but
we
can
probably
get
started.
B
B
A
Yeah
yeah
because
it
looks
like
people
are
confused
with
every
release.
There
are
more
issues
that
you
know.
People
are
using
the
latest
version
from
each
of
the
repo
and
they
have
problems.
So
we
have
to
figure
out.
I
think
a
way
that
people
will
be
somehow
notified
that
something
is
wrong.
I
don't
know,
maybe
maybe
it
should
be.
A
I
am
written
somewhere
in
the
readme
that
please
this.
This
is,
I
know,
not
recommended
to
use
with
with
this
version,
or
maybe
we
should
implement
some
mechanism
in
the
plugins,
maybe
that
they
detect
the
checking
the
api
version
and
so
on
so
on
so
so.
B
The
plugins
should
probably
have
the
the
api
or
the
instrumentation
package,
or
both
as
a
or
the
api,
at
least
as
a
peer
dependency,
which
I
think
would
solve
this
issue,
because
if
you
had
the
wrong
version
of
the
api
installed,
it
would
complain
right
now.
It's
a
regular
like
that.
The
instrumentation
and
the
api
are
regular
dependencies
of
the
plugins
or
the
instrumentations.
B
A
What
if
we
create,
maybe
in
the
readme,
something
like
I
don't
know
some
compliance
metrics
when
we
say
okay
version
of
core
14
is
compatible
with
this
version
of
contrib
and
so
on
and
with
the
every
release.
We'll
simply
add
that
and
update.
B
A
So
maybe
then
we
should
on
the
gdp,
for
each
plugin
keep
the
information
which
which
api
you
should
use
really.
I
know
anything
that
will
help
people
to
understand
this
better,
so
you
can
avoid
situation
like
people
are
raising
the
the
ticket
that
doesn't
work
after
you
know,
30
minutes
of
releasing.
B
We
can
also
put
compatibilities
on
the
readme,
but
if
the,
if
the
plugin
declares
a
peer
dependency
of
like
api
version
15
and
you
install
api
version,
16,
then
npm
will
complain
when
you
install,
so
it
will
at
least
log
an
error,
and
let
them
know
that
something
is
going
on
where
I
don't
know.
If
we
can
always
assume
that
people
are
going
to
check
the
readme
every
time
they
bump
a
minor
version
number
of
a
package.
B
B
A
B
Yeah,
I
think
we
should
update
the
merge
guidelines
too
to
reflect
that
so
we'd
say
no
merge
on
weekends
minimum
24
hours.
I.
B
B
B
Yeah,
I
definitely
agree
with
no
merging
on
the
weekends
I
I
noticed
this
was
sort
of
the
first
week
that
we
had
regular
approvers
merging
a
fair
number
of
prs
and
I
honestly
had
a
hard
time
following
what
was
being
merged
right
in
the
beginning.
So
I
I
agree
with
the
sentiment,
I
think,
is
good.
It's
increasing
our
velocity
and
we're
merging
things
more
quickly,
but
we
need
to
be
careful
that
we're
not
merging
too
quickly
where
people
still
have
questions.
B
Okay,
I'll
I'll
update
the
merge
guideline
after
the
meeting
here,
the
documentation
being
broken,
I'm
actually
aware
of-
and
there
is
a
fix
for
this-
I
thought
I
had
the
open,
but
I
guess
I
don't
there's
a
pull
request.
B
Sound
okay,
yeah,
okay!
I
guess
I
can
create
a.
A
B
C
Well,
yeah,
so
I
briefly
brought
this
up
last
week
and
it's
kind
of
a
conversation
that
we're
having
with
many
of
the
other
maintainers
for
other
languages,
and
this
was
also
an
issue
that
we've
brought
up
over
the
past
summer.
C
And
basically
we
want
to
get
to
a
point
where
you,
the
maintainers,
are
comfortable
with
having
the
vendor-specific
propagators,
which
are
like
the
ids
generators
and
trace
header
propagators
in
the
contributory
bow,
so
that
you
know
we
have
clear
upstream
components
for
the
things
that
our
users
put
into
their
transfer
providers
and
so
the
gist
of
the
proposal
and
the
net.
Repo
is
basically
that
we
could
kind
of
separate
the
responsibilities
of
pr
review
and
code
ownership
so
that
only
the
you
know
the
subject
matter.
C
Experts
and
certain
vendor-specific
contributions
to
the
contra
repo
would
be
reviewed
and
maintained
by
experts
and
those
from
those
vendors
and
not
necessarily
by
the
maintainers
and
the
maintainers
would
just
be
responsible
for
merging
and
then,
as
for
releases.
C
I
know
that
right
now
the
contrib
repo
uses
lerna,
and
so
since
that's
already
kind
of
doing
all
the
releases
at
once.
I
don't
think
that
we
really
need.
C
I
think
that
would
kind
of
differ
a
little
bit
in
that
proposal
on
linkedin.net,
since
I
think
that
all
the
proposals
could
still
be
all
the
releases
could
still
be
done
at
once,
but
as
opposed
to
separating
responsibilities
for
those
but
yeah,
so
that
that's
kind
of
the
gist
of
it
and,
of
course,
I'm
very
aware
that
there's
a
good
amount
of
disagreement
in
this
in
the
past.
So
I
wanted
to.
B
B
B
I'm
sure
that
I'm
not
the
first
person
to
bring
that
up
and
probably
something
you
guys
are
already
aware
of,
but
if
we're
going
to
assign
long-term
code
ownership,
it
needs
to
be
someone
that
we're
sure
is
going
to
be
around
long
term.
B
Second
is
assuming
the
the
merging
and
reviews
are
done
by
you
know
vendor
folks,
and
then
release
is
done
as
it
currently
is
in
lerna.
Just
like
you
said
what
happens
if
I,
the
vendor,
in
this
case
aws,
has
some
hotfix
that
they
really
need
out,
but
there's
something
else
blocking
release
in
another
package.
C
Yeah,
that's
that's
a
that
is
a
very
good
point,
and
so
so
maybe
the
maybe
the
releases
do
end
up
getting
split.
Just
out
of
curiosity,
though,
what
would
happen
if,
if
that
was
currently
the
case
like
if
one,
if
the
express
instrumentation
had
an
urgent
fix
but
koa
was
blocking
it
or
something.
B
It
would
depend
how
urgent
the
fix
was.
Honestly,
we've
had
this
situation
in
the
past,
and
typically,
we
have
just
held
the
release
until
all
the
packages
are
ready.
B
It's
not
an
ideal
situation,
but
it's
what
we've
done
to
me
ideally-
and
this
goes
back
to
what
I
was
just
saying-
about
the
the
contrib
repo
versioning.
B
B
Lerna
calls
it
yeah,
I
think
so,
but
to
me
I
would
prefer
if
a
pull
request
modifies
some
package
a
then
the
pipeline
should
see
that
package
a
was
the
only
changed
package
and
should
automatically
release
it
in
some
manner.
You
know
it
could
be
as
simple
as
using
you
know.
Learner
has
a
in
their
publish
options,
there's
a
from
package
option
which
looks
at
all
the
current
version
numbers
and
looks
at
all
the
published
version
numbers
and
publishes
any
versions
that
have
any
any
packages
that
the
version's
been
bumped.
B
D
B
That
manner
we
would
keep
versions
of
you
know.
Each
package
would
have
its
own
version
and
be
released
one
at
a
time,
and
that
way
something
blocking
package
a
would
not
block
the
release
of
package
b.
It's
something
that
I've
been
thinking
about
for
a
while.
The
only
reason
I
haven't
really
made
a
push
on
it
is
because
I
haven't
had
the
time
to
you
know,
really
put
a
lot
of
effort
into
the
contrib
release
pipeline.
D
B
To
put
effort
into
then
it's
a
solvable
problem.
C
Like
you
know,
urgent
fixes,
being
blocked
is
not
would
not
necessarily
be
unique
to
new
aws
packages
which,
by
the
way
are
they
are
very
simple
like
it
would
be
two
pretty
much
single
file
packages
that
are
that
are
being
added,
so
I
don't
anticipate
needing
too
often
of
fixes
for
them,
but
I
think
that
we
would
definitely
be
happy
to
improve
the
ci
cd
capabilities
of
migrating
to
github
actions
to
to
start
with
from
because
I
believe
that
there's
an
initiative
across
all
of
open
telemetry
to
get
off
circle
ci
and
go
to
github
actions.
C
C
C
C
See
the
manual
effort
involved
and
so
improving
the
ci
capabilities
is
something
we
could
definitely
spend
time
working
on
and
so
yeah.
If
we
have
more
automated
releases
and
releases
that
we
can
do
kind
of
independently
using
from
package
or
something
similar,
then
then
do
you
think
it
would
be
a
little
bit
less
blocked
to
add
these
new
kind
of
separately
owned
packages.
B
Make
code
ownership
very
clear,
you
know
I
don't.
I
don't
want
to
end
up
in
a
situation
where
I'm
in
charge
of
maintaining
vendor
code
for
not
just
aws,
but
you
know
once
we
start
adding
code
from
one
vendor,
I'm
sure
other
vendors
will
want
to
do
that
as
well,
and
I
don't
want
to
end
up
in
a
situation
where
I'm
maintaining
20
or
30
packages
of
vendor-specific
code
that
I
don't
really
understand.
C
Yeah
I
I
yeah,
I
totally
agree,
and
I
think
that
the
the
code
owners
like
feature
on
on
github
has
been
pretty
successful
at
negotiating,
that
in
like
the
collector
contrib,
where
obviously
there's
a
like,
literally
20,
to
30
components
that
are
owned
by
different
people.
So,
like
yeah,
I
I
think
that
we
would
definitely
be
comfortable
with
obviously
having
a
full-time
engineer
assigned
to
it
and
reviewing
it.
C
And
ideally,
the
only
responsibility
that
you
and
the
other
maintainers
would
have
is
just
merging
after
one
of
us
would
approve
like
prs
and
stuff.
B
B
B
You
I
actually
added
a
exporter
to
the
collector
contrib
repo
and
I
was
not
granted
right
access
to
the
repo.
C
Yeah,
I
don't
know,
that's
that's
a
good
call,
then
I'll
have
to
investigate
more.
I
I
think
that
maybe
like
getting
approver
permissions
without
necessarily
like
merging
or
writing
permissions
would
be
sufficient,
but
again,
I'm
not
actually
sure
how
how
that's
handled
and
collector
contributes
so
I'll.
I
can
get
back
on
that.
B
Okay,
I
would
appreciate
that,
but
if,
if
we
can,
you
know,
I
think
these
are
all
solvable
problems,
even
if
we
do
have
to
give
people
access
to
the
repo,
we
may
be
able
to
use
something
like
branch
protections
to
ensure
that
they
can't
write
onto
the
main
branch
and
things
like
that
which
might
be
sufficient
protection.
B
B
C
Well,
yeah!
That's
that's!
Definitely
what
we
like
to
hear
so
I'll
I'll
look
into
the
code
owner's
issue
and
what's
required,
whether
it's
right
access
or
if
you
can
get
away
with
something
less
and
yeah
I'll,
look
into
kind
of
modifying
the
the.net
proposal
and
making
everything
kind
of
more
concrete
in
a
newish
view.
B
So
before
we
move
on
from
this,
I'm
only
one
maintainer
out
of
three
bart
you're,
the
only
other
maintainer
on
the
call.
Do
you
have
any
thoughts
that
you
would
like
to
add,
or
does
everything
sound
reasonable
so
far.
A
My
only
concern
is
that
if
this
is
really
doable
with
the
github,
so
you
can
somehow
protect
the
main
branch,
as
you
said,
but
still
allow
people
to
somehow
push
the
code
for
the
for
the
plugin
that
they
are
responsible
for
and
if
this
is
not
doable,
then
I'm
wondering
what
the
options
we
have
like
you
know
create
a
third
repository
with
the
with
easier
access
for
the
people.
But
then
you
know
to
give
like
a
full
control
for
for
the
third
party
maintainers
or
how.
B
Yeah,
I
I'm
just
not
sure
how
we
can
I
I
can
think
of
ways
to
do
it
without
granting
right
access
to
the
repo.
For
instance,
we
could
have
a
a
github
action
that,
when
a
pull
request
is
opened,
looks
at
the
ownership
somehow
of
the
package
and
tags
whoever
the
owner
is,
and
then
we
could
have
a
pull
request
label.
B
That's
you
know,
approved
by
owner
or
something
like
that,
and
then
a
regular,
approver
or
maintainer
would
then
merge
it's
slightly
slower
process,
but
I
think,
as
long
as
will
you
understand
the
the
limitations
that
were
that
were
under
and
it
sounds
like
you
have
some
research
to
do,
and
then
we
can
talk
about
this
later.
Is
that
seem
reasonable.
C
Yeah
and
I
yeah-
I
definitely
think
that
keeping
things
safe
in
terms
of
like
yeah,
we
don't
we
don't
want,
or
we
don't
need
right
access
to
the
whole
repo
if
we
can
avoid
it.
So
if
there's
some
way
to
just
get
us
approve
our
permissions
that
are
only
really
meaningful
for
approving
prs
to
our
owned
packages,
then
that
would
be
ideal.
So
I
will
look
into.
A
B
Okay,
I
added
this
next
one.
This
is
just
a
pr
that
I
opened
this
morning.
It's
nothing
more
than
a
bunch
of
renames
in
the
api
to
more
specific
names.
So,
right
now
we
have
attributes,
but
attributes
are
only
applied
to
spans.
So
I
renamed
those
to
span
attribute
and
span
attribute
value,
same
thing
with
entry,
ttl
and
entry
value.
Those
are
both
baggage,
specific
and
status.
B
Is
spam
specific,
so
it's
a
rename
that
just
makes
it
so
that
when
we
export
these
names
as
top
level
from
the
api,
it's
a
little
bit
more
obvious.
What
they're,
for
it's
just
part
of
a
general
api,
cleanup
effort
that
I've
been
trying
to
make
before
we
release
1.0.
So
I
would
appreciate
eyeballs
and
reviews
on
this
whenever
anyone
has
time.
B
Similarly,
our
baggage
implementation
is
incomplete.
I
don't,
I
think,
fortunately
nobody's
using
it
right
now,
because
it
is
so
incomplete,
which
means
we
have
room
to
repair
it
without
causing
too
many
headaches.
B
B
To
say
about
it,
nev
would
you
like
to
oh
wow?
I
guess
we'll
start.
D
Yeah,
but
most
of
this
is
it
it
is
informational,
but
I
thought
it's.
D
This
pr
has
become
quite
large
just
trying
to
support
backward
compatibility,
so
I
also
wanted
input
before
I
submit
it
in
terms
of
where
it's
at
I
finished
all
the
coding
got
all
the
tests
running,
updated,
the
the
the
docs
and
the
the
examples,
but
then
I
realized,
which
is
my
first
assumption
here
main-
is
now
master.
My
current
local
ones
are
still
using
master,
so
I
should
be
using
main.
Instead
from
now
on,
you
should
be
using.
B
Main
yes,
if
you
open
up
the
repo
in
github,
it
actually
gives
you
a
little
snippet
of
code
to
use
to
rename
your
local
branch.
If
you
don't
know
how
to
do
it,
but
yes,
we're
making
an
effort
across
all
open,
telemetry
repos
to
rename
to
maine
so
yeah.
B
D
Yep,
okay,
so
that
was
just
the
first
question
in
general
visibility.
I
added
the
the
next
bit
into
the
clock
comment
of
the
current
issue,
which
I've
just
got
the
link
in.
So
that's
the
one
where
currently,
the
issue
is
described,
as
you
know,
create
the
get
get
no
op
logger
and
where
this
is
not
what
we're
building
anymore,
based
on
what
we
discussed
last
week,
so
my
question
there
is:
should
we
actually
split?
D
You
know
close
this
issue
or
redeem
it
or
effectively
break
it
into
what
we're
doing,
which
is
the
first
part
of
introducing
the
new
diag
top
level
object,
so
it's
api.diag
with
its
api
implementations
of
the
the
affected,
the
equivalent
no
op
console
and
the
vlogger
interfaces,
and
it
turns
out
log
level
and
then
have
a
second
issue
which
comes
along
to
say:
remove
these
now
deprecated
things.
So
that's!
That's
really!
The
first
question
there
is
to
me
it
from
a
tracking
perspective.
D
Breaking
it
probably
makes
sense,
but
I
wasn't
sure
what
the
protocol
is
with
how
you've
done
something
like
this.
In
the
past.
D
Yeah,
okay,
so
I'll
do
that?
What
do
I
get
here?
So
the
existing
knob
blogger
console
logger
and
logo
interfaces
so
effectively.
I've
kept
them,
but
I've
tagged
them
as
deprecated,
which
I
have
a
how
I've
deprecated
a
little
bit
below
this
pr
is
like
118
files
right
now.
D
Most
of
the
changes
are
around
supporting
interactive
backward
compatibility.
So
in
theory,
if
someone's
created
their
own
extensions
and
they're
initializing
logger,
as
opposed
to
this
new
diag
logger,
the
api
will
happily
manage
whichever
workbook
you've
initialized.
So
that's
where
most
the
complexity
has
been.
D
There
are
a
couple
of
know
and
break
things
that
look
like
they're
going
to
break
stuff,
and
I
haven't
been
able
to
come
up
with
a
clean
way
to
completely
remove
it.
The
first
one
is
the
plug-in.
D
Today
you
can
see
that
third
argument:
logger
I've
now
defined
it
as
optional,
and
I've
introduced
this
new
type
called
optional
diaglogger.
Previously
that
was
mandatory
and
was
always
logger,
so,
while
at
runtime,
I
think
this
will
be
fine,
I'm
anyone
who's
created
a
logger
it.
This
may
create
a
compile
error,
which
is
why
I
introduced
the
type
zone.
Theory,
if
I
just
changed
to
to
pass
optional
diag
logger,
if
there's,
if
anyone
can
think
of
a
better
way
to
do
that,
I'm
I'm
open
for
suggestions.
B
This
is
in
the
instrumentation
class.
B
Yeah,
so
that
that
plug-in
is
deprecated,
anyways,
okay,
so
that
shouldn't
be
too
much
of
an
issue.
We
will
be
removing
it
fairly
soon
wholesale.
So
I
wouldn't
worry
too
much
about
it.
Yep.
D
Okay,
cool
the
next
one
was
effectively.
There
was
a
a
new
type
introduced
called
resource
detection.
Config
with
logger,
looks
like
it
was
added
by
a
an
intern
at
awf
at
amazon,
where
effectively
it's
extending
the
existing
resource
detection
config,
which
defines
the
logger
as
optional,
and
the
only
the
only
thing
that
the
with
logger
does
is
says.
It's
now
mandatory
on
the
basis
that
we
actually
want
to
have
a
diagonal
instead
of
the
logger,
and
we
want
to
be
able
to
have
it
as
optional.
D
A
Just
a
quick
question,
but
shouldn't
we
didn't.
We
agree
that
it.
It
will
be
like
a
global
diac,
vlogger
yeah.
D
Yeah
so-
and
this
is
where
I've
spent
a
lot
of
time,
doing
the
backward
compatibility,
so
even
if
they
do
pass
in
a
logger,
we
still
want
it
to
function,
at
least
in
the
short
term
until
we
flip
over
to
diag
logger.
So
I
was
saying
seeing
past
two
is
a
potentially
some
of
that
cleanup,
but
I'm
happy
to
take
the
big
plunge
and
do
it
straight
away,
because
that
would
probably
make
it
a
bit
smaller.
D
Well,
one
of
the
reasons
for
splitting
the
issues
that
we
that
came
up
last
week,
that
bart
was
mentioning
was
we
don't
want
to
break
the
contrary
repo,
as
soon
as
we
throw
out
an
updated
version
with
these
changes,
so
I
haven't
yet
updated
the
contract
repo
locally.
I
was
going
to
do
that
before
I
pushed
out
the
pr
to
see
how
bad
it
is,
whether
it's
just
warnings
or
a
complete
break.
A
D
B
B
D
D
So
we
have
to
change
the
signature
of
those
which
is
the
the
optional
diagram.
So
we
have
to
change
some
code
in
effectively
the
the
main
core,
which
is
what
I've
tried
to
do
so
effective.
D
At
least
that's
the
theory
anyway
got
it.
I
can
break
that
into
three
and
say
diagologa
we
go
to
contrary
repo
change
control,
repo
to
use
it.
The
second
one
is
to
update
the
the
quarter
vector,
remove
change
all
the
usages
to
the
diag
logger,
release
that
and
then
the
third
one
we
can
come
along
and
then
remove
the
the
deprecated
things.
That's
the
three
I
was
thinking
of.
B
So
it's
yeah,
I
mean
it
just
if
you're,
okay
with
it,
I'm
okay
with
it,
but
just
sounds
like
it's
growing
into
more
process
than
than
than
actual
code,
and
I
kind
of
want
to
avoid
that
it
is
there.
D
B
D
B
B
As
long
as
we
can
ensure
that
it's
done
in
a
timely
manner,
you
know
I
don't
want
to
block
and
trip
for
two
or
three
weeks,
but
if
we
can
do
it
in
a
couple
of
days,
I
don't
think
there
are
going
to
be
too
many
instances
of
you
know
it.
It
should
be
a
a
relatively
straightforward
change.
There
may
be
a
lot
of
calls
to
logger
and
maybe
a
lot
of
like
lines
of
code,
but
none
of
them
should
really
require
too
much
thought
to
change.
B
A
Mean
no,
no.
I
meant
that
we
should
first
have
a
diac,
so
it
will
be
a
small
pr
without
using
this
one
anywhere
yet
just
a
diag,
so
we
can
release
it
very
soon
and
then
the
next
pr
it
it
will
be
just
to
to
use
this
diag
in
the
quarter
repo
and
the
same
time.
A
We
can
already
release
the
api
with
this
new
diag
and
update
also
the
country
which
basically
means
the
country
doesn't
need
to
wait,
then
really
on
a
on
on
removing
everything
from
the
card,
and
you
have
to
make
another
like
big
change.
Until
you
are
able
to
release
it.
This
could
be
done
basically
simultaneously.
A
A
Yeah
and
then
the
next
pr,
once
you
push
this
br,
which
can
be
then
reviewed
quite
quickly,
I
think
you
are
start
removing
already
from
the
core,
but
if
the
dayak
is
fine,
we
can
just
you
know,
merge
it
and
release
it
without
really
waiting
for
updating
everything
in
the
car.
So
that's
this
way
we
can
use
the
diacology
in
the
country
people
also,
so
I
mean
those
releases
and
changes
would
be
faster
and
smaller.
C
D
A
D
B
D
A
D
Okay,
okay
cool.
I
should
be
able
to
push
that
out
today,
I'll
effectively
grab
what
I've
already
got,
push
it
off
to
one
side
in
another
repo,
so
because
most
of
the
changes
that
I've
done,
which
is
really
round
that's,
what's
on
the
screen
now,
tagging
logger
is
deprecated
and
then
adding
this
new
diag
logger,
which
I
didn't
really
want
to
do,
but
for
backward
comparability
I
had,
but
if
we,
if
we,
if
we're
going
to
say
we're
just
going
to
remove
components
from
being
able
to
pass
their
own
logger,
this
sort
of
disappears.
D
Although
I
did
think
there
is
a
couple
of
cases
where
internally,
they
change
the
logging
level
or
they
pass
their
own
logger,
where
they
want
to
use
a
knob
logger
or
for
that
particular
component.
They
want
to
have
a
console
logger,
which
seemed
useful,
at
least
during
development,
from
the
api
perspective,
which
is
why
I
added
the
dialogue,
but
we
can
review
that
later
and
then
the
next
one
was
as
part
of
the
change
to
go
from
the
environment,
hotel
log
level.
D
B
Does
anyone
else
have
anything
that
they
want
to
bring
up
today
looks
like
that
was
the
last
one
on
the
list,
so.
B
D
B
Then
okay,
then
I
guess
I
will
talk
to
you
all
next
week.