►
From YouTube: 2022-05-05 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
Can
you
hear
me
now
cool
yeah,
tanya
me
and
zoom?
We
just
don't
get
along
so
well.
B
Okay,
what
time
did
you
all
need
to
jump
off?
Is
this
like
a
half
hour,
15
minutes,
45.
B
Okay,
let's
jump
into
it,
then
you
know
what
second
thought:
let's
just
shoot
shoot
the
breeze
right.
No,
okay,
yeah,
let's
jump
into
it.
If
you
haven't
already,
please
add
yourself
to
the
attendees
list
like
I'm
done
now,
and
if
you
have
any
topics
you
wanted
to
discuss,
add
them
to
the
agenda
item
any
use
cases
of
open,
telemetry,
we'd
love
to
hear
about
them
as
well.
B
Please
add
them
as
a
user
story
and
we
can
kind
of
jump
in
I've
got
a
few
things
I
wanted
to
talk
about.
Well,
the
first
thing
is
pablo
is
I
talked
from
via
slack.
He
is
not
able
to
contribute
to
the
project
anymore
on
a
regular
basis.
At
least
I
think
it
sounds
like
he
might
be
working
on
with
josh
and
maybe
aaron
as
well
reviewing
some
code,
but
otherwise
he's
not
gonna
be
able
to
continue
on
so
just
removing
it
from
the
appenders
our
approvers
list.
B
So
that
needs
a
review
specifically
by
code
owners.
So
I
guess
I'm
just
calling
out
aaron,
but
anyone
else
that
would
like
to
express
their
feelings.
We
are
sad
to
see
him
go
other
than
that.
There's
a
pr
here
that
I
have
opened
around
project
linting,
so
I
kind
of
wanted
to
get
some
meta
feedback
on
this
from
the
community.
I
don't
know
if
anybody's
actually
taking
a
quick
glance
at
it.
I
I
know
that
nobody's
reviewed
it,
but
essentially
what
this
comes
from.
B
Is
that
there's
a
lot
of
things
that
I
feel
like
a
lot
of
us
reviewing
code
just
say
that
are
essentially
lint
items
and
I
was
looking
into
it
and
it
looks
like
our
implementation
of
revive
the
winter
with
going.
Ci
is
not
doing
anything
which
at
some
point
I
think
they
shifted
so
that
like
by
default,
it
does
nothing
and
it's
enable
rules,
and
so
what
this
pr
does
is
it
goes
through
and
it
enables
a
subset
of
all
the
rules.
B
B
A
I'll
speak
for
myself,
I've
been
busy
with
a
conference,
so
most
of
this
week
has
been
somewhat
gone
for
me.
I
can
take
a
look
at
it.
My
only
ask
is
that
we
try
not
to
do
this
more
than
once
a
year,
because
changing
styles
is
painful
like
this,
and
I
don't
care
what
it
is.
Let's
just
agree
to
something,
and
then.
B
Yeah,
I
don't
necessarily
see
this
as
changing
style,
but
just
enforcing,
I
think.
What's
already
there,
you
know.
One
of
the
things
that
we
do
try
to
enforce
are
okay,
but
yeah.
I
I
if
there
are
style,
changes
that
you
find
in
here
and
controversial,
I'm
happy
to
remove
them
and
have
a
separate
discussion,
I'm
more
so
like.
I
can't
remember
how
many
there's
53
commits,
and
I
think
the
majority
of
them
are
effectively
just
enabling
a
rule
and
it
passing
so
I
don't
think,
there's
yeah
but
yeah.
Okay,.
D
B
Yeah,
okay,
I
I
get
it
and
I
was
worried
that
that
was
the
case,
but
I'm
also
open
to
somebody
saying
like
break
this
apart,
because
I
have
ways
I
could
do
that,
but
if
it's
digestible
in
its
current
form
then
I'll
leave
it
so
also
that's
david
and
aaron.
If
you
do
get
to
it,
if
you
you
know,
you
spend
too
much
time
on
it.
Just
tell
me
to
break
it
apart,
and
I
can
try
to
do
that.
B
Okay,
I
think
it's
useful,
because
I
find
that
I
don't
want
to
waste
their
time
with
linting
reviews
aprs,
so
I
I
just
like
to
have
an
automation
to
it.
So,
okay,
next
thing
I
wanted
to
talk
about
was
the
metrics
sdk
alpha
release
status,
but
I
wanted
to
put
this
at
the
end
because
wow
that's
delayed.
B
I
feel
like
it's
going
to
take
up
time
so
david.
Maybe
I
can
hand
it
off
to
you
for
these
out
of
three
auditory
detectors
and
hand
it
off.
D
Sure
so
I've
been
exploring.
Our
goal
has
been
to
integration
test
as
much
of
the
gcp
related
stuff
against
actual
gcp
environments,
as
we
can
so.
D
We've
done
this
for,
like
our
collector
stuff,
we
did
this
cool
wrapper
that
exists
in
open,
telemetry,
collector
contrib,
with
most
of
the
logic
being
in
our
own
repo,
and
we
can
then
run
that
against
actual
cloud
monitoring,
apis
and
stuff,
like
that,
so
I've
been
looking
into
how
we
could
possibly
do
this
for
detectors,
but
it's
a
little
bit
tricky
because
we
could
have
the
detector
live
in
our
own
repo
and
then
run
our
own
integration
test
pretty
easily.
D
D
So
someone
will
go,
get
the
latest
detector
and
they'll
go
get
the
latest
say
hotel,
http
or
something
like
that
and
it'll
fail
on
resource
detection
because
they
won't
the
the
two
detectors
won't
agree
on
the
version
of
the
semantic
conventions
that
it
should
be
using.
So
I'm
I'm
curious
if
there
are
our
thoughts
or
if
anyone
else
has
thought
about,
where
detectors
should
live,
yeah
or
or
advice
to
offer,
it
would
be
helpful
as
well.
B
D
B
Okay,
yeah
all
right,
so
do
I
understand
this
correctly,
like
you're
saying
this
doesn't
work
that
well
and
to
make
it
work
better.
You
would
like
to
have
this.
You
know
in
the
repo
for
other
google,
so
resources.
D
Yeah
yeah,
so
there
are
two
pr's
I
listed
there.
One
was
an
earlier
proof
of
concept
that
I
have
the
first
yeah,
so
that
one
is
a
pr
that
I
was
working
on
to
improve
what's
already
there
and
then
the
second
one
is
virtually
the
same
thing,
but
moving
it
to
our
repo
okay.
The
second
one
would
allow
me
to
run
integration
tests
against
the
version.
B
So
I
do
know
that
for
the
semantic
convention
question
like
that
was
the
whole
purpose
of
the
schema
and
that
pathway
forward.
I
we
definitely
don't
have
an
implementation
for
doing
those
translations.
You
know
for
renames
or
moves,
but
I
thought
the
collector
did
right.
B
Yeah
yeah
yeah,
I
gotcha,
but
what
I'm
saying
is
is
that
if
maybe
this
is
a
good
motivation
that
we
need
to
include
some
sort
of
schema
logic
in
this
project
so
like
if
yeah
the
you
have
gcp
and
you
have
another
detector
like
a
host
detector
or
something
like
that,
and
one
is
a
you
know:
there
are
two
different
versions
it.
The
schema,
in
theory,
should
be
able
to
translate
from
the
old
version
to
the
new,
whatever
the
old.
B
In
that
in
that
situation,
is
we
don't
have
that
logic
currently,
like
you
just
know
like
we
just
fail
the
merge
at
that
point,
but
maybe
it's
time
to
to
look
into
building
that,
because
I
know
that
there
are
renames
that
have
already
happened
in
the
semantic
conventions
that
we
track
and
I,
if
I'm
not
mistaken,
the
semantic
conventions
are
trying
to
be
defined
in
a
forwards
compatible
way.
So
I
I
don't
know,
maybe
that's
the
answer
is
that
we
need
to
start
building
that
into
the
project.
B
I
I
mean
that's
my
first
guess,
because
I
mean
you.
We
still
also
have
that
problem
where
yeah
any
third
party
detector
could
have
a
different
resource.
B
Any
third-party
resource
creation
could
use
a
different
schema
right,
like
you
could
use
an
old
version
of
the
semantic
conventions,
and
I
think
that,
failing
because
there's
a
mismatch
in
the
schema
is
not
really
a
good
look,
I
think
it
was
a
default
look
that
we
decided
initially.
B
D
Right
well,
if
it
is
hosted
and
can
trip,
then
it's
sort
of
guaranteed
to
be
the
same,
because
it
we
do
updates
for
some
coffee,
yeah.
B
Yeah
no
and
right
like
I
think
if
that
would
solve
that
side
of
the
equation,
but
doing
the
integration
testing
then
yeah.
I
don't
know
how
to
solve
that
one.
Then
I
guess
what
I'm
saying
like
but
yeah.
If
you
kept
it
in
the
gcp
repo
and
we
supported,
schema,
merging
or
schema
translations,
then
we
could
do
that.
I
don't
know
the
other
way,
though,
like
I
have
no
problem
updating
the
one
in
our
contrib
repo
and
hosting
it
there.
B
But
if
the
desire
is
to
integration
testing,
I
I
mean
I
think
you
could
you
could
define
a
pipeline
right
where,
like
you,
would
have
a
release
and
contrib
and
whenever
you
know
you
have
some
sort
of
signal
that
goes
off
to
the
gcp
repo
that
pulls
it
in
as
a
sub
package,
or
something
and
like
I,
it
seems
like
I
guess
you
could
do
that
it
seems
really
convoluted
to
me.
But
that's
that's
the
only
thing
I
can.
D
B
B
Yeah
right
yeah,
that's
a
that's
a
tough
one,
because
I
think
that
also
kind
of
goes
back
to
that
whole
idea
of
ownership,
and
I
think
this
is
a
great
use
case
that
we
want
to
have
ownership
in
the
contrib,
but
that
distributed
ownership
also
comes
with
this.
This
side
effect
that,
like
it,
is
isolated
from
maybe
the
source
of
of
the
of
truth
like
in
aws
or
gcp.
So
it's
a
tough
one.
B
I
don't
know
I
I've
talked
a
lot.
I
don't
know
everybody
else
sent
me
a
sentence.
C
B
So
yeah,
this
is
a
good
question
and
a
version
of
represents
a
specification
release
and
that
doesn't
really
talk
about
the
version
stability
of
the
sim
conf
and
it's
not.
What
you
want
is
is
going
to
be
the
end
result.
B
The
tl
dr
here
is
it's
not
great,
so
I
I
know
that
their
api
can
be
breaking
so
the
one
thing
that
comes
to
mind
specifically,
I
think
it
was
the
cassandra
key
space
recently
in
version
1.10
changed
instead
of
defining
the
key
space
they
want
to
instead
define
it
as
the
database
name
and
so
the
semantic
like
distinction
of
what
the
database
name
for
a
cassandra
database
has
changed.
B
So
if
you
go
from
1.9
to
1.10,
like
your
telemetry,
if
you
go
to
the
backend
system
will
have
to
understand
that
differently,
and
so
you
can
go
look
at
the
cement
conventions.
Some
of
them
are
marked
stable
if
I'm
not
mistaken,
but
a
lot
of
them
are
still
experimental.
I
think
there's
a
very
small
subset
that
are
stable
and
the
meaning
of
what
stability
is
in
the
semantic
convention.
World
is
also
currently,
I
think,
being
discussed
pretty
actively
around
http
semantics.
B
I
know
in
the
specification
meeting
this
week.
I
can't
remember
her
name,
but
there's
a
few
people
that
are
actively
involved
in
this.
This
rework
of
http
semantics
that
are
like
required
and
like
the
idea
of
required
is
also
like
this
poorly
defined
thing
currently
in
the
semantic
conventions,
and
so
that
that
is
also
going
to
change,
and
if
that's
the
case
like
you're
again,
the
next
version
up,
you
may
see
things
that
are
going
to
be
like
changing
in
semantic
presence
or
even
in
their
meeting.
B
I,
and
because
of
that,
the
required
also
means
that,
like
how
you
define
stability
becomes
really
key,
and
so
I
think
both
of
these
things
are
still
under
development
of
what
the
definitions
are,
and
you
know.
Historically,
it
has
not
been
the
case
that
stability
in
the
semantic
conventions
is
the
semantic
meaning.
It's
stability
in
the
api
itself,
that's
how
that
was
defined.
If
that
makes
any
sense.
C
Yeah,
I
think
I
think
again,
your
code
would
continue
to
compile,
but
the
string
could
change
under
the
manifest
constant,
let's
say
or
yeah
I
mean
just
the
knowledge
analogously
if
it
was
a
library
with
procedures,
you
can
imagine
that
your
calls
to
the
function
would
still
compile,
but
the
behavior
might
change
significantly
like
your
code's.
Still
compiling
doesn't
necessarily
mean
that
it
is
yielding
the
same
result
or
the
same
meaning.
It
sounds
like.
B
Yeah,
exactly
exactly
and
now
that
I
think
about
it,
I'm
not
even
sure
if
the
api
stability
is
guaranteed
because
the
cassandra
key
space,
one
that
I
just
mentioned.
I
think
that
was
removed
in
our
release
of
the
1.10
semkov
package,
which
I
don't
know
if
that
should
have
been.
But
I
know
in
the
generation
it
wasn't
included
because
I
don't
think
that's
in
the
semantic
definitions
anymore.
It
was
removed
from
the
symmetric
definitions.
I'll
have
to
I'd,
have
to
double
check
on
that.
But
yes,
the
first
is,
is
absolutely
true.
B
So
in
in
the
case
of
david
over
here
trying
to
get,
you
know,
compatibility
like
it's
exactly
that
problem
like
it
may
still
compile,
but
it
may
not.
That
may
also
be
something
or,
and
then,
if
it
does
like
the
semantic
difference
should
probably
be
updated
by
people
who
have
concepts
of
it
and
trying
to
remain
current.
I
guess
is
the
key
thing
there.
A
So
it
sounds
like
the
action
item
here
is:
we
need
something
to
track
being
able
to
merge
different
versions
of
the
semantic
conventions
within
our
code,
because
the
ask
is
something
along
the
lines
of
we
see
problems
when
we
have
a
different
version
of
the
semantic
convention
than
any
other
detectors
that
we
have
and
they
should
be
able
to
play
nice
together
across
different
versions.
B
A
It
sounds
like
we
either
need
that
or
we
need
some
way
to
transport,
multiple
semantic
versions
within
the
same
resource
that
we
are
describing
when
we
transmit
telemetry,
which
that's
a
little
bit
beyond
the
scope
of
this.
This
seg.
B
And
I'm
trying
to
find
the
cassandra,
but
I
think
maybe
we've
kind
of
touched
on
it
david.
Does
this
make
sense
or
do
you
have
a
plan
forward
or
have
we
just
confused?
You.
D
No,
no,
I
I
think
we
reached
the
same
conclusion.
I
did
my
plan
forward
will
probably
be
something
like
write,
a
library
that
doesn't
depend
on
semantic
conventions
in
the
gcp
repo
and
then
depend
on
that
somehow
test
that,
so
that
it
does
what
I
sort
of
think
it
does
and
then
have
the
actual
usage
of
semantic
conventions
be
upstream
we'll
see
if
that.
D
B
Yeah,
I
think
I
was
able
to
verify
what
I
was
talking
about.
The
cassandra
key
space.
Our
api
is
stable,
our
instrumentation
for
cassandra
is
experimental
and
it
is
not
so.
This
is
a
great
example,
stephen,
so
the
the
table
it
looks
like.
Let
me
see
if
I
can
share
again,
because
this
is,
I
think,
good,
to
follow
up
on
the
table
used
to
include
the
key
space.
However,
now
the
key
space
is
included
in
the
database
name.
B
So
if
beforehand
you
are
getting
this
cassandra
table
cement
or
attribute,
you
would
have
expected
it
to
be
prefixed
with
the
key
space
it
no
longer
is
so
this
is
kind
of
a
good.
You
know
understanding
of
how
they
can
change.
Semantically
like
this
is
now
a
new
new
value,
and
a
new
version
is
why
that
is
so.
Is
it
that
the.
B
The
content
of
it
changed
so
yeah
it
was.
It
was
in
this
pr
if
you
wanted
to
take
a
look
1973
here
where,
essentially
you
are
removing
this
idea
and
and
just
using.
Oh
I'm,
sorry
key
space.
Okay,
maybe
there's
more
to
it.
Maybe
I
need
to
keep
looking
because
it.
B
Some
yeah
okay,
but
yes
here
you
go
and
then
this
is
the
the
schema
that
is
in
1.8,
that's
where
it
was
removed.
So
this
attribute
is
renamed
to
db
name
so
yeah!
That's
this!
Is
that
translation
here?
Okay,
so
our
api
is
likely
broken.
If
you
try
to
go
and
upgrade
from
1.8
to
1.9,
you
won't
get
it
to
compile,
because
this
type
won't
be
there
anymore.
B
That
might
not
be
a
good
thing.
We
may
need
to
try
to
retroactively
fix
that.
C
D
Sneakily
added
another,
if
that's
okay,
just
while.
D
Of
of
resource
detection,
I
actually
wrote
this
up
a
while
ago,
but
the
general
gist
is
that
right
now
detecting
a
lot
of
the
kate's
dot.
You
know
whatever
pod
name
or
something
lives
within
cloud
provider,
specific
detectors
so,
for
example,
in
the
current
gcp
detector,
they
attempt
to
detect
some
of
them,
although
they
use
sometimes
the
wrong,
like
they
use
container
name
instead
of
case.container.name.
D
My
hope
is
that
we
should
remove
this
from
cloud
provider
specific
detectors
and
have
either
recommend
people
use
the
hotel
environment
variable
to
set
those
which
I've
is
included
in
here
or
at
a
kubernetes
specific
detector
that
sort
of
standardizes
the
environment
variables
used.
We
use
environment
variables
because
the
kubernetes
downward
api
supplies
them
that
way.
So
if
people
have
time
feel
free
to
look
at
it,
it's
not
specific
to
the
gosig.
But
it's
specific
to
the
changes
I'm
hoping
to
make
to
the
gcp
detector.
C
Yeah
david
yep,
when
you
say
he
said
speaking
in
shorthand,
he
said
he's
the
hotel
environment
variable.
Did
he
mean
the
hotel
resource
attributes
variable
that
one?
I
just
didn't
remember
exactly
what
it
was
yeah.
No,
that's
because
I
have
some
experience
with
this
I've.
I've
tried
to
I've
tried
to
integrate
sort
sort
of
automating
with
speaking
too
much,
but
basically
writing
a
web
hook
that
injects
into
pod
specs
all
the
right
download
api
things
that
we
can
extract
and
then
glue
them
together
into
the
hotel
resource
attributes
variable.
C
The
problem
is,
though,
that
if
say
the
pod
author
already
had
some
attributes
that
they
were
trying
to
inject
with
that
variable,
combining
things
automatically
is
tricky,
and
then
I
filed
the
bug
against
the
spec,
because
the
format
that
we
use
for
that
environment
variable
is
borrows
from
the
baggage
spec.
I
think-
and
it's
very
fastidious
about
where
commas
go,
and
whether
there's
any
blanks
tolerated
or
extra
commas
at
the
beginning
or
end.
C
So
you
have
to
be
really
careful
when
trying
to
glue
together
contributions
from
multiple
places
to
compose
that
environment
variable-
and
I
know
it's
a
hard
problem,
but
it
just
it
doesn't
scale
well
to
having
multiple
things
trying
to
put
it
together.
D
Yeah,
I
agree
in
fact,
if,
if
you
could
leave
something
to
that
effect
on
the
description
of
that,
that's
the
alternative,
and
I
list
something
similar
to
that.
But
if
you
could
link
to
your
spec
issue,
that
would
be.
D
Sure,
because
someone
someone
pointed
out
something
similar,
but
it
would
be
good
to
get
some
consensus
on
that.
I
think,
if
nothing
happens
here
on
this
front,
it'll
likely
be
that
when
I
change
the
gcp
detector
I'll
advise
people
to
use
the
concatenated
downward
api
thing,
because
there
won't
really
be
an
alternative
and
I
don't
think
it
should
live
in
the
gcp
detector.
I
guess,
but
so
I
I
really
hope
this
this
succeeds,
but
we'll
see.
Okay,
I
appreciate
it
thanks.
B
Cool
yeah,
thanks
for
jumping
in
there
steven,
because
I
I
couldn't
have
provided
that
feedback.
I
know
we're
also
coming
up
on
the
half
hour.
I
know
that
aaron
and
steven
harris
were
needed
to
drop
off,
but
I
did
want
to
touch
base
on
the
metrics
sdk
progress.
I
don't
plan
unless
there's
a
desire
to
get
into
as
much
of
the
weeds
as
we
did
last
time.
B
There's
a
lot
of
really
great
discussion
happening
asynchronously
in
ish
asynchronously
in
issues
but
yeah,
just
kind
of
a
heads
up
we're
about
20
listed
here.
We
probably
have
a
lot
more
to
go
because
there's
you
know
open,
pr's
and
open
issues
that
are
not
captured
in
this
milestone.
But
taking
a
look
at
our
project
board,
we
definitely
have
a
lot
more
things
in
progress.
B
I
think
specifically,
we
can
take
a
look
here
if
you
want
to
see
what's
active,
there's
a
lot
of
discussion
happening
in
the
readers
package.
We
can
probably
talk
a
little
bit
about
this
in
just
a
second
and
there's
a
open
pr
to
address
that,
as
well
as
pr
to
address
the
manual
reader,
and
so
these
are
two
places.
I
think
that
if
you
can
participate,
if
you
want
to
participate
in
the
conversation
they're
worth
taking
a
look
at
yeah,
I
think
that's
probably
what
I
would
say
aaron.
B
A
The
the
only
thing
that
I
wanted
to
put
in
here
is:
I
wanted
to
have
at
least
one
implementation,
either
usage
of
an
implementation
or
an
actual
physical
thing
just
so
that
we
can
have
discussions
about
what
shape
makes
sense,
because
just
designing
the
shape
is
coming
is
going
around
conversations
that
are
we've
either
already
tried
it
in
one
case
and
that
and
there
there
are.
A
A
This
isn't
necessarily
the
way,
but
let's
let's
go
and
talk
about
it,
yeah
and
I'm
sorry
that
it's
in
such
a
rough
shape,
like
I
said,
I'm
at
a
conference.
So
I
this
was
literally
just
very
early
morning
me
putting
together
what
I've
had
finished
before
getting
here
and
then
saying.
Well,
it
has
to
be
good
enough
for
right
now,
otherwise,
we're
just
going
to
stall.
In
the
conversation.
B
Yeah,
so
thanks
for
putting
this
together
again,
I
appreciate
it.
I
agree
like
we
need
to
have
some
progress,
and
this
is
a
helpful
step
in
the
right
direction.
I
I
don't
particularly
agree
with
the
requirement
that
we
need
to
have
an
implementation
for
the
fact
that,
like
having
an
implementation,
I
think
is
really
helpful
to
have
a
thought
process,
and
I
think
that
that
is.
B
You
know
like
there's
a
lot
going
on
in
this
right
now
and,
like
you,
can
see
like
there's
a
lot
of
comments
that
I've
left
and
I
don't
think
they're
all
targeted
at
the
reader
interface,
and
I
think,
if
that
distracts
from
the
main
point,
that
until
we
are
able
to
satisfy
like
some
sort
of
minimal,
viable
reader
interface,
having
an
implementation
is
going
to
change.
So
having
a
discussion
about
an
implementation,
that's
going
to
change
can
be
very
wasteful
of
our
time,
so
I
just
want
to
be
careful
of
that.
B
I
I
agree
that
having
an
implementation
to
show
is
useful
of
an
interface,
but
I
I
don't
want
it
to
derail
the
conversation
when
it
comes
to
the
interface
itself.
I
guess
is
what
my
point
is.
B
So
I
I
I
wanted
to
say,
like
I
appreciate
it,
you
know
I,
I
find
it
weird
that
there's
one
interface
and
not
the
other,
and
I
think
that
one
of
the
things
that
I
would
really
like
is
you
know
having
a
clear
design,
I
think,
is
going
to
be
more
key
than
having
a
workable
example,
because
I
think
we
already
have
a
workable
example,
and
we
know
we
know
a
way
right.
B
I
think
that's
a
really
key
thing,
one
of
the
things
that
I
look
at
when
I
see
this
is
just
that.
Like
there's
a
lot
of,
I
think
a
lot
of
things
that
could
be
explained
in
comments.
One
of
the
things
that
you
kind
of
pointed
out.
A
B
That,
like
you,
learned
a
lot
having
the
manual
reader
about
the
shutdown
and
how
it's
going
to
need
to
do
things,
and
I
think
that,
like
you,
could
also
learn
a
lot
if
you
had
the
periodic
reader
in
here
as
well,
because
that
is
gonna
have
to
do
a
lot
with
the
force.
B
Flush
right,
like
there's
gonna,
be
something
going
on
there,
and
so
I
think
that
you
can
capture
a
lot
of
that
in
in
the
comments
around
the
reader
interface
itself
and
understanding
like
based
on
the
description
of
the
pr
as
to
like
how
the
use
of
that
is
going
to
be.
B
I,
I
was
reading
a
lot
of
the
golang
email
chains
and
discussion
groups
around
these
sort
of
things,
as
I
was
kind
of
linking
to
and
like
one
of
the
things
that
I
noticed
is
that
they
do
a
really
good
job
in
that
respect,
and
I
think
that
it
would
help
our
progress
if
we're
able
to
do
a
very
similar
thing,
where
they
put
some
sort
of
minimal,
viable,
cohesive
design
forward
and
discuss
that,
and
if
it
requires
an
implementation
like
I'm
not
opposed
to
it.
B
I'm
not
saying
like
don't
include
this
manual
reader,
but
I
just
want
to
make
sure
that
it
doesn't
derail
the
conversation
from.
I
think
the
purpose
that
we
need
to
get
the
reader
across
more
than
I
think
anything
is
kind
of
the
key
here.
A
Then,
how
do
we
make
progress
in
the
dis
in
the
discussion
around
the
design,
because
I
think
we've
come
to
a
some
sort
of
an
impasse
of
I've
said
my
you've
said
your
best,
but
we
haven't
reached
a
concord,
an
agreement
on
how
this
thing
should
be
shaped.
A
B
A
B
B
B
Edge
that
I
had
before
was
this
idea
of
jesus
there's
a
lot
here.
Sorry
about
that
the
producer
interface
becoming
a
a
function,
and
I
and
I
don't
think
it's
something
we
should
change
to.
I
think
I
think
maintaining
the
interface
is
the
right
approach.
I
don't
know
if
I
resolved
this.
Oh
I
didn't
yeah.
B
I
think
if
that
conversation
is
resolved,
I
I
think
there's
there's
some
good
thought
in
there
and
I
left
a
long
comment
to
try
to
explain
the
thought
process,
but
I
don't
think
that
we
disagree
on
that
anymore.
I
think
that
there's
agreement
on
that
more
than
disagreement.
B
The
only
thing
that
I
think
I
have
is
just
I
think
here
I
was
asking.
Maybe
we
want
to
return
an
error.
The
comments
still
seem
a
little
stale,
but
that's
more.
I
don't
know
if
that's
design.
B
It
is
just
communicating
our
our
thoughts
in
code,
I
think
is,
is
only
the
thing
I'm
asking
there
not
necessarily
like
changing
the
design.
A
Yeah,
thank
you,
but
I
have
to.
I
have
to
run
yeah.
Okay,
that's
helpful!
I'm
I'm
just
want
to
make
sure
that
we
are
continuing
to
make
progress
towards
some
kind
of
an
agreement
and
as
long
as
we're
doing
that,
I'm
I'm
happy
even
not
a
snail
space.
It's
that's
how
community
that's
how
I
expect
the
community
to
to
come
to
an
agreement,
especially
a
volunteer-led
community,.
B
B
I
see
josh
is
also
on
the
call.
I
don't
know
I'll
pause
here.
If
you
had
any
more
thoughts
on
the
reader
progress,
because
I
know
you
commented
as
well
and
I
don't
know
if
I've
responded,
but
you
have
your
hands
up
so
I'll
pause.
Yeah.
Sorry,
I
can't
see
it
when
I'm
presenting.
E
Thanks
tyler
yeah,
I
I
was
surprised
to
see
this
pr
just
now,
although
I
see
that
aaron
salad.
Yesterday
morning,
I
thought
we
were
having
discussion
in
issue
2809,
and
I
was
also
kind
of
wondering
why
no
one
had
responded
to
me.
So
I
you
know
it's
it's
interesting
to
listen
to
the
two
of
you
talk
about
about
the
like
evolving
disagreement
or
agreement.
E
While
I've
also
been
working
on
a
branch
which
which
aaron
forked
a
few
weeks
ago,
and
my
my
branch
has
also
been
iterated
on
a
lot
given
the
feedback
from
you
and
aaron.
So
I
actually
have
a
slightly
different
position
on.
I
think
all
this
so
I'd
like
to
be
included
in
the
conversation
either
way,
so
I
have
not
really
seen
aaron's
pr
or
aaron's
feedback.
E
B
Or
absolutely
I
just
want
to
point
out
josh
I
I
apologize.
I
thought
for
some
reason
that
you
and
aaron
were
in
sync
and
that
this
pr
was
something
that
both
of
you
have
understood.
I
didn't
realize
that
I
totally
agree
that
we
should
try
to
have
the
conversation
in
a
single
place
to
avoid
just
this
kind
of
confusion.
So
yeah.
E
Yeah
he-
and
I
are-
I
mean,
like
I
think,
he's
treated
me
and
his
stupid
negotiations
as
one
sort
of
like
forward-looking
direction,
as
well
as
yours,
as
a
sort
of
rearward-looking
and
kind
of
like
we're
all
moving
forward
together.
So
I
I
think
we
anyway,
the
point
is,
I
think
he
and
I
were
out
of
sync,
probably
because
he's
going
to
a
conference.
E
I
did
briefly
look
at
that
pr,
so
I
think
he
and
I
are
sort
of
moving
the
same
direction
in
the
week
since
the
last
time
I
spoke
to
you
here,
I
did
follow
on
follow
through
and
a
lot
of,
the
suggestions
I
got.
One
was
like
putting
the
main
reader
interface
in
the
sdk
metric
package
is
a
big
deal.
E
I
do
have
a
few
screens
just
present,
so
I
could
talk
through
them
if
you
wouldn't
mind
yeah,
absolutely
anyway,
okay.
So
this
is
the
issue
that
I
posted
basically
right
after
last
week's
meeting
and
I'm
basically
going
to
walk
through
some
of
the
code
that
hasn't
really
changed
from
here.
I
I've
definitely
worked
on
the
code
and
I
don't
have
some
things,
but
I
haven't
changed
this
much.
So
I
don't
want
to
read
that
to
you,
but
here's
just
sort
of
a
little
bit
of
a
snapshot
of
where
I
am
today.
D
E
The
prototype
that
I
was
working
on,
which
I
still
think
is
a
implementation
of
the
specification.
So
starting
with
like
how
a
user
would
see
it.
The
prometheus
example
you
create
an
exporter.
You
create
a
meter
provider.
You
now,
the
the
structure
of
the
reader
passing
the
reader
is
what
we've
been
debating
so
here.
It
is
you
of
course,
have
a
resource
that
was
always
there
now
with
reader.
So
it's
in
the
isn't
top
level
package.
E
The
reader's
interface
is
also
in
the
top
of
a
package,
and
I,
whether
we
agree
or
not
like
the
x,
the
prometheus
export,
is
an
implementation
of
that
reader
interface.
I'll
show
that
next,
what's
what's
also
worth
noting-
and
this
is
a
pretty-
I
think,
important
design
decision-
is
that
we've
kind
of
been
disagreeing
on
like
when
you
register
reader.
How
does
how
does
it
get
its
views
and
the
specification
says
there
will
be
one
set
of
views
for
the
whole
thing
and
the
like,
logically
speaking,
that
doesn't
make
a
lot
of
sense.
E
I
I
think
it's
there's
room
for
interpretation
and
specification.
Just
let
us
pass
views
to
each
reader
so
that
the
with
reader
now
takes
options
for
the
views
that
that's
why
I've
passed
the
exporter,
and
these
are
optional
now
view
clauses,
that's
a
slightly
different.
Does
that
that's
in
line
with
all
the
pr's
that
have
already
merged,
but
this
one
that's
open
is
going
to
deviate
from
what
I've
got
here.
So
we
should
discuss.
This
is
the
reader
interface
tyler
that
you've
been
looking
for
and
it's
really
the
same
place.
E
It
was
the
time
ago.
This
is
the
implementation
that
I
think
meets
the
specification.
Anything
can
be
one
of
these
readers.
A
prometheus
exporter
can
be
one
of
these
readers.
A
push
based
exporter
is
likely
to
use
periodic
and
I'll
show
that
next.
So
I've
tried
to
comment
in
this
comment
here.
E
How
we're
really
the
the
tough
challenge
of
addressing
here
is
that
there's
bi-directional
information
flowing
through
these
meter
providers,
you've
got
the
user
using
interface
and
you've
got
the
reader
collecting,
and
so
this
is
sort
of
the
nexus
of
that
bi-directional
thing
and
so
force
flush
and
shutdown.
I
actually
haven't
implemented
them
they're,
totally
out
of
scope
for
what
the
sdk
does.
That's
just
passed
through
to
the
readers,
the
provider
doesn't
do
anything
with
that,
so
I've
only
focused
really
on
the
register
function
and
I'll
show
you
how
that
works
in
a
sec.
E
There
yeah
so
in
the
metric
package.
There's
a
provider
producer,
that's
just
a
pointer
to
an
object.
That
is
when
you
construct
the
reader
or
sorry
when
you
construct
the
meter
provider
immediately,
it
just
registers
itself
with
each
reader,
so
register
is
passed
the
producer.
I
think
I've
answered
your
question.
The
producer.
B
E
Okay
and
but
backing
up
just
a
second,
so
I
showed
you
what
the
user
will
see
now
these
are
the
two
options
for
the
meter
provider
with
resource
has
always
been
there
and
with
reader.
Now
I
think
this
is
a
little
bit.
E
This
is
a
design
that
I
think
works
for
me,
but
I
think
it
might
raise
flags
right
now,
so
I
I'm
trying
to
find
a
way
that
works
for
you
guys
with
reader.
It
takes
a
reader
and
view
options.
E
The
and
then
inside
this
we
construct
a
view
of
view,
a
view,
a
views
object,
which
is,
it's
got
a
name
for
debugging
purposes.
When
I'm
creating
errors
downstream,
I
need
to
know
which
reader
and
I
don't
want
a
dependency
on
reader,
so
I
put
the
name
of
the
reader
into
the
views
so
that,
when
view
conflict
survives,
I
can
point
to
the
reader
name,
but
otherwise
the
the
keep
the
key
as
far
as
I'm
concerned
in
this
design
is
that
usck
with
reader
and
the
reader
can
have
with
view
options.
E
What
I
presented
last
week,
there
were
reader
options.
Those
are
gone,
there's
no
more
reader
package.
Even
I
put
the
manual
reader
and
the
periodic
reader
in
the
same
top
level
package
for
now,
there's
no
more
reader
options,
because
those
have
become
view
options.
So
the
view
is
now
more
cohesive.
I
think
because
the
views
have
a
bunch
of
clauses
and
then
they
have
these
defaults
for
each
instrument
type.
E
So
now
the
view
options
are
those
defaults
and
the
view
clauses
are
individual
clauses
in
the
views,
so
those
are
called
clause,
options
and
there's
a
with
clause,
which
is
what
you
saw
here
so
view
option
with
clause,
creates
one
clause
in
the
views
that
you're
building
okay,
I
showed
you
the
reader
interface.
I
told
you
flush
and
shutdown,
don't
even
matter
to
me.
They're
passed
through
the
sdk
doesn't
do
anything
with
that
manual.
Reader
is
about
as
simple
as
it
gets.
We
were
talking
about
this
last
week.
E
It's
got
nothing
more
than
a
name
for
identity
purposes
and
that
producer
so
and
because
man,
in
the
case
of
a
manual
reader,
I
I
didn't
think
it
was
even
worth
putting
a
lock,
because
if
you're
using
this,
you
know
not
to
start
using
the
producer
until
after
you've
constructed
the
sdk
moving
on.
I
wanted
to
show
like
one
example
of
a
pr
of
a
manual
reader
being
used.
This
is
the
test
package
that
copy
I
copied
originally
from
aaron's
branch,
so
a
collect
function.
E
E
The
of
the
yes,
no,
this
one,
you
wanted
to
see
the
exported
demonstration.
E
E
Yeah
it
just
it
just
registers
in
memory,
I
call
it
in
memory,
I
don't
know,
there's
names.
Names
are
hard,
okay,
so
I
was
showing
you
then
periodic.
This
is
the
debate
we're
having
kind
of
it's
like?
If,
if
you,
if
you
want
to
be
a
periodic
reader,
then
you're
probably
a
push
exporter.
So
I
created
a
push
exporter
interface,
and
this
is
when
shutdown
and
force
flush
begin.
E
Mattering
is
because,
like
for
the
push
exporter,
my
presumption
is
that
when
you
shut
down,
you
want
one
last
collection
and
then
flush
that
and
then
shut
down
without
data.
So
this
is
interpretive.
Now
I
think
the
flush,
the
the
idea
of
a
push-based
exporter
is
that
you
have
three
methods
called
export
shutdown
and
force
flush
and
they
all
take
a
current
data
data
set
with
them.
So
that's
how
I
would
interpret
this
so
then.
E
E
Ultimately,
all
of
these
call
it
collect
method,
they
take
a
lock
and
then
they
call
they
collect
data
and
they
call
through
the
same
method
on
the
underlying
reader,
so
you're
going
to
collect
data
and
then
force
flash
you're
going
to
collect
data
and
then
shut
down
you're
going
to
collect
data
and
then
export
so
that
that
should
be,
hopefully
very
fairly
straightforward.
I
didn't
actually
make
a
user
for
this.
I
this
is
sort
of
like
on
the
peripheral
of
what
I
was
working
on.
E
E
They'll,
take
a
lock
to
make
sure
that
that
that
reuse
is
safe,
and
that
means
that
from
one
collection
to
the
next,
I'm
actually
using
every
slice
in
the
same
way,
I'm
using
every
slice
of
instruments
in
the
same
way
in
the
same
position,
ordinally
speaking,
so
that
all
the
aggregators
can
be
reused,
and
so
that
you're
not
turning
memory.
That's
that's
personally
a
preference
in
mind,
but
even
if
you
pass
nil,
you'll
get
back
a
data
metrics
object
which
you're
free
to
try
to
reuse.
E
E
I
have
a
pipe
number.
I
debated
this
a
lot
back
and
forth
with
aaron.
The
code
came
out
to
clean
us.
This
way
is
that
there's
some
state
that
are
in
several
places
inside
the
sdk,
where
you've
got
to
do
one
thing
for
each
reader
and
it's
easier
to
have
the
state
right
where
you,
where
you
need
it,
so
you
have
a
slice
of
like
one
per
reader
in
various
places.
So
that's
that's.
Why
I'm
passing
pipe
number
then
to
collect
you
run
the
callbacks.
E
E
So
this
is
the
sequence
of
events
in
a
single
collection
for
a
single
reader.
This
pipe
number
will
be
used
down
inside
the
asynchronous
logic.
When
you
have
an
instrument,
you
look
up
the
correct,
compiled
form
based
on
your
reader
number,
which
is
in
the
context
so
anyway,
that's,
I
think
everything
I
had
to
show
you
here.
I
will
unshare
and
be
happy
to
discuss
or
answer
questions.
B
So
yeah
that
looks
great
josh.
I
think
I
think
we
ended
up
being
much
more
in
line
than
I
think
our
discussion
would
have
alluded
to
last
time
and
so
yeah.
I
think
that
looks
pretty
solid.
I
I
definitely
have
some.
I
think
review
comments
there,
but
I
think
I
I
just
I
want
to
say
like
by
and
large
the
overall
design
looks
looks
good
to
me
from
the
the
reader
perspective.
B
I
think
that
I'd
probably
ask
a
little
bit
more
about
and
maybe
recommend
against
passing
in
an
argument
that
we're
going
to
mutate
and
then
return
just
because
it's
going
to
be
sharing
memory
to
try
to
communicate
instead
of
communicating
by
sharing
values,
and
so
like.
I,
I
think,
there's
the
review
discussion
there,
but.
A
B
E
Well,
so
I
can
first
of
all
go
look
at
28.85
because
I
didn't
see
it
till
mid
meeting
here
and
then
maybe
just
try
to
describe
slight
differences.
I
see
where
I
was
after
this
week.
E
Aaron
has
asked
me
to
make
it
so
that
my
pr
builds
cleanly
and
has
all
the
tests
and
so
on,
like
copyright
notices
and
things
so
that
it's
easier
to
see
and
like
to
pull
up,
check
out
and
use,
and
I
will
just
say
that
I
haven't
written
tests
for
everything,
absolutely
everything,
but
it
has
reached
a
point
where
I
personally
wouldn't
make
any
changes,
I'm
happy
with
it
from
a
perspective
of
code
cleanliness
or
something
like
that.
E
It
could
use
more
comments
and
more
tests,
and
I
will
do
that.
I
actually
went
prior
to
this
meeting
to
pull
I
try
and
synchronize
with
your
brand,
the
current
new
sdk
main
branch,
which
meant
reorganizing
things
so
that
they
fall
into
the
pattern
that
is
in
the
you
know
in
those
files,
so
that
you
can
actually
view
the
diff.
So
my
pr
that
I
just
showed
you
was
from
pr2865.
E
Those
diffs
are
ahead
right
now.
So
you
can
read
the
pr
if
you'd
like,
and
then
I
keep
continuing
to
work
with
aaron
on
a
day-to-day
basis
and
and
to
try
and
help
as
I
can.
B
Yeah,
it's
greatly
appreciated.
I
I
think
that
I
foresee
a
lot
of
discussion
around
the
aggregation
pipeline
because
it
is,
it
looks
complex.
E
Yeah,
actually,
that
is
literally
what
aaron
and
I
have
been
discussing
and
and
and
I
I
will
say
that
I
did
a
essentially
thought
experiment
that
he
requested
challenging
the
notion
that
you
know
like
there's
something
that's
hard
to
read
here.
Why
is
there
a
snapshot
and
process
method
that
has
no
arguments
on
it
and
I
I
I
did
some
research
and
I
want
to
try.
I
tried
to
answer
that.
E
I
don't
think
that
now
is
the
time
for
me
to
spray
that
across
this
meeting,
but
I
have
an
answer
to
that
and
it
comes
back
to
that.
Bi-Directionality
of
information
flow
and
some
decisions
that
are
are
essentially
baked
in,
and
I
don't
really
feel
it's
worth
doing
the
experiment
to
try
our
completely
radically
different
approach.
But
there
is
a
different
approach,
a
radically
different
approach.
E
It
would
involve
some
sort
of
form
of
reference,
counting
and
so
on,
but
the
the
current
approach,
just
to
kind
of
give
it
a
synopsis
level
description,
is
that
there's
this
thing
called
a
compiler
that
that
that
knows
all
the
names
and
protects
all
the
conflicts
and
knows
where
all
the
distinct
unique
collectors
are
and
when
you
perform
collection,
you're
going
to
start
from
that
list
and
you're
going
to
just
collect
an
order.
E
So
the
question
is:
why
is
it
that
that
I
have
to
like
go
out
to
these
other
pieces
of
state
and
call
tell
call
a
zero
argument
method
on
all
those
things
and
then
get
back
to
myself
continue
collecting
they
answer
that
question
like
the
best
I
can
come
up
with
something
like
well.
This
is
called
a
compiler
for
one
thing:
it
sets
up
this
data
pipeline
which
ultimately,
every
accumulator
that
I
hand
out.
E
It
came
from
a
place,
and
I
know
where
it
came
from,
so
it
knows
literally
knows
where
how
to
put
the
data
into
the
output.
When
I
hand
you
an
accumulator,
then
the
question
is:
why
is
it
not
the
case
that
I?
Why
am
I
not
calling
the
accumulator
to
give
me
a
value
which
I
then
you
know
myself
hand
off
to
the
output?
Well,
the
answer
was
that
accumulator
was
created
by
the
output,
so
yeah
put
you
know,
so
it
knows
the
output
and
there's
essentially
there's
a
shortcut
because
you
store
a
pointer
there.
E
You
also
have
pre-calculated
the
attribute
filter
so
that
there
is
really
something
compiled
happening
here,
but
but
the
higher
level,
even
by
that,
is
that
the
person
who
has
those
accumulators
they
they
have
a
responsibility,
but
their
responsibility
ends
at
calling
that
zero
argument
method,
so
they're
they're
responsible
for
knowing
what
was
live.
E
If
you
ask
for
a
new
accumulator
and
update
it
you're
responsible
for
calling
snapshot
and
up
and
process,
that's
all,
though
you
don't
have
to
ensure
that
that
accumulator
is
unique,
you
can
use
more
than
one
of
the
same
name
and
that's
how
the
synchronous
and
asynchronous
pipelines
are
doing
their
own
different
things.
But
you
know
in
in
the
question,
is:
where
does
this
complexity
come
from
you?
E
Can
you
can
kind
of
back
out
and
see
it
at
different
layers
like
it's,
partly
that
when
you
have
more
than
one
reader
or
more
than
one
behavior
for
an
instrument
and
at
the
moment
of
use
you
have
an
attribute
set?
Do
you
want
to
end
up
looking
up
that
attribute
set
for
every
instrument
or
for
every
reader
behavior?
E
Or
do
you
want
to
look
up
that
attribute
set
once
and
then
do
all
the
things
and
the
current
organization
of
that
is
you
look
up
that
attribute
set
once
and
then
all
the
things
are
underneath
that
and
that
decision
leads
to
this
one
that
I
just
described
earlier,
which
is
that
the
thing
that
is
doing
all
that
synchronous
state
management-
it
just
has
a
cache
of
accumulators
and
is
every
every
time
it
sees
a
new
attribute
set.
E
But
you
don't
need
to
know
where
they're
going
because
they're
each
going
to
different
places
and
if
I
was
to
try
and
get
an
argument
back
from
the
accumulator
and
then
pass
it
to
the
collector
and
end
up
multiplexing
back
through
all
the
same
view.
Machinery
that
I
had
do
the
first
time
create
the
accumulator,
so
the
accumulator
could
be
a
multi
accumulator
for
multiple
readers,
if
you're
a
synchronous
instrument,
and
the
fact
is
that
just
having
the
accumulator
go
directly,
the
output
is
a
shortcut
anyway.
E
That's
the
short
answer,
I
think
of
that
as
an
internal
package,
and
so
at
some
point
we
kind
of
just
have
to
like
agree
to
have
some
complexity
and
it's
an
internal
package.
That's
my
short
pitch.
B
E
It's
evolving
too,
like
it's
iterating
and
my
understanding
improves.
So
aaron
is
the
one
who
pointed
out
that
hey
you
have
a
method
called
accumulate.
I
don't
even
know
what
it
does
and
and
that's
when
I
renamed
it
snapshot
and
process,
and
that's
when
I
tried
to
justify
if
you
look
at
the
implementation,
it
literally
has
two
met.
Two
things
going
on.
The
first
line
is
snapshot.
The
second
one
is
process,
but
they
deserve
to
be
together.
E
B
So
I
look
forward
to
having
the
discussion
when
I
have
more
context,
but
I
also
want
to
just
point
out
that
I'll
I
plan
to
continue
having
those
discussions
in
an
open
forum
on
issues
and
I'll
try
to
make
sure
that
everyone's
included
and
I
will
also
not
try
to
default
and
think
that
you
guys
are
in
sync
and
I'll.
Just
ask
that
question
the
pr
so
okay
cool
that
sounds
good.
We
have
six
minutes
left.
I
think
everyone,
maybe
there's
some
cool
user
stories.
B
I
want
to
pause
for
that
and
make
sure
that
we
give
some
time
at
the
end,
to
see.
B
Okay,
awesome,
I
know
brian,
is
on
the
call
and
he
has
a
pr
also
to
use
the
crosslink
tool
that
he
spent
a
lot
of
time
building.
So
please
go
take
a
look
at
that.
I
think
there's
some
discussion
about
whether
we
want
to
include
a
prune
option
or
not.
I
haven't
been
following
that
brian.
I
don't
know.
If
you
want
to
comment.
F
Yeah,
I'm
sorry,
I
don't
know
the
maintainer's
name
that
did
comment
on
it,
but
I
did
respond.
I
mean
he
made
me
think
about
it
and
there's,
I
did
add
the
prune
flag.
There's
really
in
the
context
of
this
repository.
There's
no
real
downside.
It
is
destructive,
but
it's
under
version
control,
so
it
doesn't
like
commit
it
for
you.
Anyways
you're
still
going
to
have
to
go
in
there
and
make
the
commit
anyways
and
it
yeah.
F
So
I
I
did
make
that
change
and
I
added
I
updated
the
the
log
logging
message
before
it
just
kind
of
improved
context
a
little
bit,
but
I
did
add
that
in
there
and
it
should
really
never
be
used.
Unless
you
know
major
changes
are
made
to
those
goal:
modules.
B
Yeah,
there's
also
kind
of
a
shameless
plug
to
go.
Take
a
look
at
the
pr,
because
I
think
the
tool
brand
rope
can
be
used
in
a
lot
of
other
multi-mod
go
projects
out
there,
so
if
anybody
else
is
also
in
use
for
other
projects,
keep
that
in
mind.
If
you
review
the
code
thanks
cool
well,
I'm
looking
at
the
agenda.
Nothing
else
is
there
I'm
not
seeing
anybody
jump
up
for
user
stories.
Anybody
else
have
anything
before
we
all
end
it.
B
I'm
seeing
smiles
cool,
get
four
minutes
back
thanks.
Everyone
for
joining
we'll
see
you
all
next
week
same
time
same
place
or
asynchronously,
bye.