►
From YouTube: 2021-08-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).
B
C
D
A
A
Okay,
hey
nathaniel,
the
this
workflow
to
publish
a
package
from
code
owner
tag
is
this?
Is
this
like
an
urgent
thing
like?
Is
this
what
we
defined
as
what
we're
going
to
be
doing
for
the
workflow?
A
I'm
just
reading
aaron's
comments
so.
E
No,
I
wouldn't
say
it's
urgent,
but
I
would
say
it's
ready
in
terms
of
code
completeness,
it
doesn't
add
too
much
code.
It
does
solve
the
issue
of.
We
eventually
will
need
a
way
to
release
collector
or
contrib
components.
That
is
easy
for
maintainers.
So
this
is
something
that
they
did
in
dot
net,
which
just
allows
a
tag
to
be
set.
So
I
thought
I
could
add
on
to
it
and
do
that
here.
F
E
Even
approver
wouldn't
be
able
to
because
you
can
add
a
tag
to
any
branch,
but
you
can't
add
it
to
a
main
branch.
Only
a
maintainer
can
add
it
to
a
main
branch
really.
F
E
A
F
F
I
added
that,
yes,
just
something
that
I
I
want
to
discuss
here,
so
that
everybody
is
aware
of
what's
happening.
We
are
kind
of
facing
a
ci
crisis.
A
bunch
of
prs
are
getting
stuck
running
their
tests,
and
apparently
this
is
not
only
happening
to
us,
but
this
problem
has
been
reported
by
other
members
of
the
community
alex
started
a
thread
in
the
in
the
slack
channel.
F
F
I
now
think
that
even
make
that's
making
the
problem
even
worse,
I
guess
so
because
we're
taking
more
resources,
I
filed
a
ticket
yesterday,
just
github,
so
sorry
for
the
inconveniences,
we're
a
bit
powerless
in
this
situation
here
so
wanted
to
give
the
attendees
of
this
meeting
situation
that
we
are
in.
A
Nice
yeah,
so
everyone
will
just
have
to
wait
a
bit
for
their
yards
to
run.
So
I
think
that's
the
nathaniel,
that's
what
you're
going
to
be
waiting
on
for
the
for
this
aggregated
resource
here.
E
A
I
see
cool
nice
break
early
if
container
id
is
found.
Oh
I'm
also
not
sharing
my
screen.
E
E
But
the
change
here
just
makes
it
so
that
subsequent
container
ids
are
these
bogus
ones
so
that
the
detector
should
be
able
to
just
pull
it
out
from
the
very
first
line,
which
already
has
the
container
id
it
shouldn't
keep
trying
to
read
the
lines
from
the
next
ones,
because
they
should
always
be
the
same
container
id.
So
this
is
just
a
quick
fix
for
that.
A
I
see,
can
you
add,
like
a
comment
in
here
just
saying:
it's
implying
that,
like
the
first
container
id
we
find
is
the
one
that,
like
everyone,
everything
else
if
exists
would
be
the
same.
E
A
E
A
That's
good
cool
thanks
thanks,
yeah
I'll.
Take
a
look
at
that
pr
to
outline
what
it
means
to
be
a
code
owner.
A
Yeah,
so
I
think
we,
I
think
we
just
we,
we
put
aside
the
contrib
and
code
owner
discussions
for
a
while
right
now,
because
we're
focused
on
all
the
distro
stuff.
Is
there
something
you
want
to
say
about
this
nathaniel
like
any
anything?
That's
like
urgent
right
now,
because
I
haven't
really
taken
a
look
at
this
much.
E
I
guess
I
just
want
to
answer
any
questions
that
you
guys
might
have.
Instead,
it's
a
very
small
change
and
I
know
for
example,
dale
commented
like
concerns,
like
you
know,
we're
not
even
ready
for
1.0
like
we
to.
We
can't
assume
that
we
are,
and
that's
totally
fair.
I
I
agree
with
that.
This
pr,
all
it
does
is
just
do
one
of
the
little
things
that
we
need
to
do
before
we
get
to
one
point
on
contribution
that
is
just
define
what
a
code
owner
is
and
just
do
that
separately.
E
So
I
just
added
the
things
that
I've
seen
other
sigs
do
and
address
people's
comments
about
what
a
co-owner
should
be
and
just
put
that
all
in
the
code
under
file
in
one
place
for
everybody
to
look
at.
So
I
think
this
can
be
merged
today,
because
it's
again
just
updating
like
docs
and
stuff,
but
if
you
guys
have
questions
I'd,
be
happy
to
answer
them.
F
Yeah
later
can.
F
F
F
Yeah,
I
think,
as
as
it
is
right
now,
I'm
I'm
okay
with
what's
being
stated
here.
F
I
just
I
think
I
I
was
stepping
away
a
little
bit
from
the
purpose
of
this
pr.
F
When
I
added
some
comments,
because
I
was
concerned
about
the
fact
that
the
version
number
and
the
existence
of
a
code
owner
are
separate
things
not
necessarily
related
to
one
another,
because
a
package
may
be
released
and
and
the
code
owner
may
leave
their
duties
afterwards
and
or
a
package
may
have
a
code
owner,
but
the
code
I
mean
work
is
still
being
done
and
it
is
still
not
1.0.
F
One
important
thing
about
1.0
and
is
the
fact
that
the
package
has
an
api
that
has
that
is
considered
to
be
something
that
the
other
can't
commit
to
so
nothing
new.
Maybe
I
don't
know
if
you
like
just
to
add
that
line,
because.
A
I
agree
if
we're
gonna
have
this
checklist
right
here.
There's
the
line.
That's
stating
like
you
know,
besides
from
like
what
it
means
to
be
stable
in
terms
of
the
open,
telemetry
community
right,
the
like
the
definition
of
stable
and
stuff
there's
like
a
excerpt
in
the
specs
page,
and
then
these
that
that
that's
fine
with
me.
A
A
A
Do
we
care
about
like
what
versioning
means
right
like
there's
nothing
to
do
with
anything
right
like
I,
I
understand
like
going
to
the
the
specifics
of
it
is
like
what
we
have
to
worry
about
in
terms
of
like
what
we
version
things
and
what
it
means
to
break
and
stuff,
but
what
it
means
to
be
stable.
It's
like
like
I'm
like
the
scope
of
this
pr,
is
pretty
small
right
like
do.
We
need
to
worry
about
all
this
stuff.
F
What
I
mean
is
that
the
the
only
thing
that
we're
missing
from
that
list
is
just
a
link
to
the
semantic
versioning
website,
something
that
says.
Okay,
that
view
code
is
considered
a
stable
by
this
definition,
because
so
far,
the
these
four
points
that
three
points
that
we
have
here
in
this
list.
F
I
mean
there
are
things
that
are
important
for
us,
I'm
sure,
but.
A
A
Semantic
versioning
like
in
our
what's
it
called
rationale.md
that
I
created
we
already.
A
G
Yeah,
I
I
think
what's
happening
is
that
this
conversation
that
I
was
having.
F
It
was
getting
off
topic
and
it's
something
that
we
can
discuss
later.
I
mean
for
the
purposes
of
this
pr.
I
think
it's
enormous.
A
Is
this
right
now
I
see
so
just
looking
at
this
nathaniel
like
the,
I
don't
think
we
need
to
answer
the
question
of
them
leaving
just
yet.
I
think
I
think
we
do
have
to
kind
of
like
have
a
plan
of
what
it
means
to
be
a
code
owner
and,
like
all
of
the
you
know
what
what
that
means
in
terms
of
like
open
source
and
everything
right
if
we
want
to
come
up
with
the
robust,
comprehensive
list
right
now,.
E
Yeah
my
my
reasoning
for
not
doing
anything
right
now
was
one
like
it
does.
It
hasn't
happened
yet.
So
I
guess
it'd
be
hard
to
say
what
we
should
do
when
it
happens
and
two
like
they
if
their
encoder
and
they
release
it
as
1.0.
There's
no
need
to
like
unrelease
it
right
once
they
have
released
it
and
so
sure
like
if
they
leave
and
they're
not
active.
E
We
just
won't
release
like
1.1
or
1.2,
but
1.0
as
it
stands
should
be
standalone,
independent
of
there
being
a
code
owner
or
not
I'd,
be
happy
to
add
a
list
of
things
we
should
do
like.
I
don't
know
that
would
get
a
code
on
or
like
kicked
off
the
project
or
something
but
like
I
don't
see,
we
don't
need
anything
to
unrelease
a
package
at
1.0
right
once
the
coder
has
gone
through
all
the
steps
and
yeah.
A
Really
that's
unfortunate,
I
don't
think
I
was
referring
to
specific
to
unreleasing
a
package
it's
more
like
like
it
would
be
part
of
like
defining
what
a
coder
is.
Those
contingencies
right
and
also
a
big
part
of
like
going
to
1.0
stable,
is
like
the
supportability
story
right
and
that
extends
past
it
being
released
right.
Someone
has
to
make
sure
that
it
is
stable
quality
all
the
time.
A
F
A
F
H
We
don't
have
a
precedent
in
this
repo
like
in
this
open,
telemetry
python,
maybe
yet
or
python
contribute
but
like
in
open
census,
which
me
and
leighton
are
working
on
for
python.
I've
been
doing
for
node,
it's
like
literally
everybody's
left
the
project
and
it's
kind
of
silly
because
they
still
get
tagged
on
pr's
and
stuff
like
that,
like
we
just
have,
should
have
a
note
about
like
when
they
should
get
removed
and
then
also
when
a
new
person
comes
on.
They
need
to
know
the
api
wants
to
know.
H
If
it's
going
to
be
a
breaking
change
and
and
maybe
we
should
be
able
to
mark
a
package
like
orphaned
if
the
co-owner
hasn't
responded
like
a
certain
amount
of
time,
and
then
that
way,
it's
clear
that
hey.
We
want
somebody
to
maintain
this
one.
F
A
F
H
Yes,
so
nathaniel,
I
would
just
say
like
even
before
we
say
that
we
could
just
say
like
hey.
If
somebody
wants
to
leave,
we
create
an
issue
that
says
hey.
This
package
is
orphaned
and
then
somebody
else
can
try
to
take
over
ownership.
Just
something
simple
like
that,
I
wasn't.
E
H
C
H
D
F
I
I
was
I'm
happy
with
them
just
adding
a
message
in
slack
channels.
I
think
yeah.
A
The
low
pressure
as
well
all
right,
nice-
I
think
those
are
all
of
the
pr's
that
were
added.
We
can
go
ahead
and
use
the
remaining.
Oh.
Does
anyone
have
any
other
topics
that
they
want
to
bring
up.
F
Oh,
oh
yeah,
we
just
are
having
trouble
getting
our
prs
completely
executed
by
ci,
because
apparently
github
is
having
an
issue
or
we
have
reached
the
organization
limits
for
resources.
So
anyway
we
have
filed
a
ticket,
but
we
are
a
bit
powerless,
so
we
just
wanted
to
let
people
know
that
expect
this
to
happen.
D
F
A
Yeah,
okay,
yeah,
okay,
cool
okay.
So
if
there's
nothing
else,
we
can
continue
with.
E
Nathaniel
sorry
go
ahead.
I
just
want
to
make
sure
you
had
a
chance
to
talk
about
this
release
from
a
tag.
Pr
that
I
had,
because
it's
pretty
I'd
say
it's
pretty
novel,
even
across
the
different
sdks
and
aaron
and
dale
have
helped
me
refine
it.
A
lot
just
want
to
make
sure
like
to
the
sake
of
this
is
something
that
we
want
the
release
when
a
tag
is
pushed.
H
Yeah,
I
I
think
this
is
good.
I
think
I
think
that
there
you
mentioned
that
to
push
a
tag
they
have
to
be.
They
have
to
have
a
maintainer
access.
Is
that
right.
E
Yeah,
so
I
think
it
will
still
require
us
bothering
the
maintainers
to
push
a
tag.
Okay,
no
matter
what.
H
I
think
that's
fine
to
start
and
then,
if
we
need
to,
we
could
cook
something
up
with
the
github
action
or
something.
But
that
seems
pretty
reasonable.
A
So
this
is,
after
we
coded
orders
for
everything.
E
E
A
E
A
F
Yeah
just
a
short
short
one:
it's
probably
in
the
next
after
the
next
week,
I'll
be
staying
in
europe,
so
nothing's
gonna
actually
change.
I
mean
I'll
still
be
attending
the
meetings
and
anything
else,
but
I
just
wanted
to
let
you
know
in
case
you
see
a
bit
of
late
responsiveness
for
me
like.
A
F
F
A
How
did
he
come
up
code
under
gonna?
Add
some
pics,
that's
pics,
all
right
cool.
We
have
about
30
minutes
left.
So
do
you
wanna
you
wanna,
take
over
and
share
your
screen.
Yeah.
F
All
right,
let's
talk
about
that
topic
once
again
this
can
you
see
my
screen
yep,
all
right?
Okay,
so,
in
the
past
106
we
have
been
discussing
this.
F
It's
a
big,
complicated
issue,
it's
about
distros
and
instrumentation,
and
configuration
so
away
lydon
and
myself.
We
think
that
this
is
the
problem
set
that
we
have
right
now
and
each
of
solving
each
of
all
of
these
individual
problems
should
fix
the
overall
problem.
F
What
we
need
now
is
a
plan
to
solve
this,
which
pretty
much
means
making
decisions
which
issue
we're
gonna
we're
gonna
tackle
first,
so
I
think
this
is
we.
We
just
want
to
have
an
open
discussion.
Correct
me.
If
I'm
wrong
away
or
later
I
I
want
to
say
that
I
I
still
don't
have
a
a
defined
plan
or
on
what
we
should
do.
First,
I
only
have.
F
I
only
think
that
this
issue
can
leave
for
the
last,
but
the
yeah,
so
if
people
want
to
show
their
ideas
now
or
if
they
want
to
add
them
to
this
discussion
later,
be
very
welcome
to
do
so.
Please.
A
All
right,
so
the
overarching
problem
that
we're
trying
to
solve
is
if,
if,
if
I'm
a
user
or
if
I'm
a
developer
right
and
I
come
to
open
telstra
like
I
want
to
be
able
to
use
open,
telemetry-
and
you
know,
come
here
and
either
auto
instrument
or
instrument
manually,
how
would
I
be
able
to
do
that
and
what
is
the
recommended
solution
and
I
want
to
be
able
to
be
able
to
configure
my
sdk
as
well,
as
you
know,
add
any
vendor
specific
stuff
that
I
want.
A
Does
that
problem
kind
of
make
sense?
I
guess
specifically
nathaniel
too,
because
I
I
know
there's
a
bunch
of
distro
stuff
that
you're
depending
on
does
that
make
sense
to
to
you
guys?
Yes,
but
I
I
think
that.
F
That
you
have
just
mentioned
only
concerns
issue
two
and
three
here
issue.
One
is
not
concerned
related
to
what
you
have
mentioned.
I.
A
Know
I
know
I'm
just
I'm
just
well.
Actually
it
is
because,
like
if
you
scroll
down
the
issue,
is
there
because,
like
oh
users,
may
want
to
perform
the
configures
the
configuration
files
or
whatever?
If
we
deem
that
that's
important,
then?
Yes,
it
is
an
issue
right.
No.
F
A
A
F
I
think
the
the
topic
that
you're
discussing
right
now
is
of
utmost
importance
and
something
that
we
have
been
trying
to
solve,
but
I'm
not,
I,
I
think
it's
getting
a
little
bit
off
topic
if
we
try
to
find
a
a
solution
for
that
big
problem,
instead
of
just
finding
the
this
solving
the
smaller
smaller
problem
of
in
which
order
are
we
going
to
tackle
this
for
no.
A
F
C
A
F
A
strategy
I'm
just
a
bit
confused,
because
I
was
another
impression
that
we
want
to
discuss
now,
just
the
order
in
which
we
want
to
discuss
right.
A
I
just
I
just
proposed
a
question
to
the
sick,
possibly
unrelated
to
this
right:
oh
okay,
to
get
us
on
the
same
page
because
they
were
not
in
the
meeting
that
we
were
just
in
so.
A
So
everyone
here
right
does
everyone
understand
the
general
issue
that
we're
trying
to
solve.
F
E
Yeah,
I
think
so.
I
think
this
is
at
least
what
I
see
as
the
major
issues,
maybe
one
that
it's
kind
of
defined
here
is
this
seems
like
it's
the
user
experience,
but
also,
I
would
say
we
need
the
developer
experience
like
if
how
does
a
developer
develop
additional
distros,
but
yeah
this?
This
looks
like
everything
that
we.
A
E
I
I'd
like
to
chime
in
just
briefly
as
a
user
and
and
I've
tried
to
contribute
some
things.
I've
found
that
the
way
the
packaging
is
set
up
with
contrib,
depending
on
core
and,
like
you
know,
like
interdependencies
like
that,
and
if
you
look
at
the
auto
instrumentation
all
of
it
is
doing
honestly
kind
of
magic
monkey
patching
here
and
there
I
find
it
both
confusing
both
as
a
developer
and
as
a
user.
I
I
understand
that
the
idea
is
to
give
you
know
every
web
framework
every
database,
everything
you
know
the
same
interface
and
you
know,
reuse
different
internal
pieces.
But
then,
when
you
hit
a
problem,
it
becomes
extremely
confusing
because,
instead
of
doing
something
like
oh
here's,
a
middleware
that
you
can,
you
know
that
is
written
for
your
specific
framework
and
you
just
give
to
your
constructor,
like
you
would
with
any
other
middleware.
I
Now
you
have
to
go
looking
through
the
source
code
to
see
where
things
are
being
monkey
patched
and
changed,
because
otherwise
you
can't
even
understand
what
the
failure
or
the
bug
is.
I
So
in
that
regard,
I
I
generally
feel
that
it's
better
to
lean
towards
simpler
solutions,
even
if
they
require
the
user
to
like
understand
how
to
install
middleware
in
their
framework,
as
opposed
to
going
down
the
route
of
you
know,
meta,
programming
and
monkey
patching
and
stuff,
because
then
you
end
up
being
boto
three
and
we
no
one
wants
to
be
both
three.
A
Oh
yeah,
okay,
so
adrian
that's
great
feedback.
Is
that
specific?
If
was
your
experience
specific
to
trying
to
auto
instrument.
I
Well,
two
things
happen:
I
tried
to
auto
instrument
falcon
framework
and
I
got
errors.
I
found
that
it
was
because
there
was
something
being
monkey
patched
internally
that
only
worked
for
falcon
2
and
not
falcon
3..
I
I've
tried
to
contribute
the
fix
to
that
back
and
I've
run
into
countless
issues,
then
as
a
developer,
because
I
need
to
clone
the
contrib
package
to
be
able
to
run
things
in
the
core
package
and
this
whole
like
cycle
of
interdependencies
that
is
complicated,
so
yeah,
both
as
a
developer
and
as
a
user.
I
found
that
the
way
that
the
packaging
is
interdependent
and
the
way
things
are
monkey
patched
and
made
magical
becomes
confusing.
I
I
I
personally
would
much
rather
lean
towards
a
structure
where
you
have
a
core
package
which
depends
on
nothing
else,
an
sdk
package
which
depends
only
on
the
core
package
and
then
there's
library,
specific
instrumentation
packages
which
depend
only
on
the
sdk
and
which
don't
do
try
and
do
any
kind
of
magic
and
instead,
for
example,
provide
a
a
middleware
for
a
web
framework
or
for
an
http
client
that
has
event
hooks,
provides
event
hooks
and
then
maybe,
if
it's
a
package
that
has
no
other
option,
because
it
provides
no
no
type
of
hooks,
then
you
maybe
have
to
resort
to
monkey
patching
something.
I
But
in
that
situation
I'd
also
try
and
you
know
open
an
issue
with
a
package
owner
and
say:
hey.
You
know
we
want
to
provide
users
all
the
instrumentation
for
your
package.
Do
you
think
you
could
provide
us?
You
know
some
hooks
or
some
callbacks
or
something
not
just
the
default
being
hey,
let's
just
monkey
patch
everything
and
try
and
make
everything
magical.
F
First,
so
sorry,
first,
I
would
like
to
apologize
to
you
for
all
the
problems
we're
having.
We
we're
facing
an
unprecedented
ci
crisis
and
lots
of
pr's
are
being
stuck
now.
You
mentioned
that
this
is
then
an
sdk.
The
package
that
depends
on
this
core
package.
That's
actually
how
things
are
right.
Now
I
mean
we
have
this
open,
telemetry
api
package,
which
has
no
dependencies.
We
have
these
open,
203
sdk
packages.
F
That
only
depends
on
the
open,
23
api
package,
and
I
I
understand
that
the
monkey
patching
is
magical
and
can
be
a
little
a
little
bit
confusing,
but
that
is
a
design
requirement.
The
what
we
have
now
is
a
tool,
the
open
format,
instrumentation
tool
that
has
to
work
for
a
lot
of
different
components.
So
it's
very
general
purpose.
It's
just
a
function
named
instrument
that
is
being
called
by
by
a
site,
custom
site
customized
by
file
and
the
details
of
how
the
instrumentation
happens
are
very
specific
to
the
library
itself.
F
You
mentioned
that
you
would
like
to
have
just
middleware
that
is
not
possible
in
all
cases,
because
not
all
libraries
follow
the
middleware
approach.
Some
of
them
use
something
completely
different,
so
it
is
a.
F
It
is,
it
is
something
that
has
to
be
like
that.
I
mean
we.
We
have
to
provide
a
general
purpose
solution
that
works
for
a
bunch
of
different
levels.
F
F
B
I
still
think
that
sorry,
sorry
such
an
interrupt.
I
think
these
are
very
valid
points.
I
think
the
point
we
raised
about
the
instrumentations
that
they
like
at
core.
They
can
be
just
middlewares
or
just
alternate
back-ends
for
libraries
and
that
can
be
just
plugged
in
without
monkey
patching.
And
then
I
think
that
sounds
very
good
to
me
and
if
we
can
do
that
and
then
on
top
of
that,
auto
instrumentation
can
go
in
monkey
patch
as
in
automatically
inject
or
replace
that
back
end
or
that
middleware
for
you.
B
I
Fair
enough,
the
last
thing
I'll
I'll
mention
regarding
I'm
not
super
familiar
exactly
with
what
the
district
thing
is.
But
I'll
say
when
I
was
trying
to
contribute
a
change
to
the
core
package.
It
I
was
being
required
to
clone
the
contrib
package
to
run
the
tests,
and
so
that's
the
kind
of
thing
I'm
referring
to.
I
don't
know
if
this
distro
thing
is
a
similar
issue,
but
having
to
have
the
contrib
package
to
run
tests
on
the
core
package
seems
like
right.
Yeah.
B
Yeah
yeah,
I
think
that's
that's,
because
you
want
to
make
sure
that
no
changes
in
core
end
up
breaking
anything
in
contra,
but
I
think
going
forward.
It'll
probably
be
able
to
loosen
those
requirements
a
little
as
we
switch
to
pin
versions
of
packages,
so
you'd,
probably
you're,
like
your
test,
would
probably
use
counter
package
from
wi-fi
directly
in
the
future.
F
Yeah,
I
also
agree
that
the
the
approach
that
we
have
right
now
having
to
clone
the
the
the
country
repo
it's
it's
unusual,
to
say
at
least
right-
I
don't
know-
maybe
we
can
find
another
solution
that
follows
a
more
traditional
approach
by
just
using
it,
so
something
that
can
be
improved
in
you
know
in
a
process,
but
but
yes,
the
that
topic
itself
is
not
related
to
this
rules.
These
throws
are
something
a
different
package
that
are
not
related
to
these
issues
that
that
you're
having.
A
Discussion
about
that,
I
totally
agree
and
understand
that
shitty
developer
experience.
So
it
is
a
separate
discussion,
though,
so,
if
you
could
open
up
one
that
we
could
continue
right
there
yeah.
F
A
F
We
definitely
encourage
you
to
open
up
a
discussion.
This
is
very
valuable
because
I
don't
think
we
have
had
much
user
feedback
so
far,
so
any
little
piece
of
user
feedback
yeah.
That
was
really
good.
Thank
you.
A
Cool,
so
on
to
the
remaining
issue
that
we
have
so
before,
tackling
any
of
this
stuff
in
the
problem
set,
which
possibly
could
be
related.
A
We
have
to
like
look
at
the
overarching
like
what
we're
recommending
towards
cust
for
customers
right
as
a
solution
for
our
open
telemetry
like
libraries
right
without
that,
like
we,
we
shouldn't
start
building
anything
related
to
auto
instrumentation
or
configuration
or
anything
right.
F
Yes,
I'm
just
a
little
bit
afraid
that
we,
okay,
what
I
think
you're
saying
is
that
we
first
need
to
set
our
big
design
goals
before
diving
into
implementation.
That's
of
course,.
F
J
A
Yes,
that
that
is
true
so
since
and
if
we
could
like
open
up
a
new
discussion
and
everything,
but
I
feel
that,
like
it,
won't
be
addressed
quick
enough
or
like
because
this
is
a
pretty
big
blocker
for
a
lot
of
things
that
we
want
to
do
since
we
have
15
minutes
left
in
the
sig
like
please
like
speak
up
like
now
like,
if,
if
you
have
any
ideas
on
how
we
should
tackle
this
right,
because
this
will
affect
like
every
every
vendor,
that's
going
to
try
to
use
our
library
right.
F
I
think
the
discussion
that
you
just
mentioned
is
critical
is
necessary
and
something
that
you
haven't
defined
yet
for
a
while,
but
I'm
afraid,
I'm
not
sure.
If
that's
the
case
here,
it
may
not
be
happening,
but
I'm
afraid
that
there
are
some
certain
pr's
that
depend
on
this
particular
discussion
and
if
we
start
a
new
bigger
discussion,
they
will
suffer
and
we'll
have
to
wait
right
right
right.
F
The
other
thing
is
that
this
approach
that
you
mentioned
sounds
like
something
that
other
six
may
need
as
well,
and
it
may
be
a
topic
of
discussion
that
will
have
to
be
discussed
at
the
spec
level.
Maybe.
A
Maybe
yeah
so
it's
it's!
Maybe
it's
something
that
we
have
to
prepare
for
more,
instead
of
just
like
quickly
talking
about
it
in
15
minutes,
but
it's
like
we
couldn't
have
a
brainstorm
session
right
like
it's,
it's
not
very
common
and
that
we
all
get
together
like
this,
and
I
don't
want
to.
C
B
B
So
I
I
think
it's
important
to
to
address
what
you
brought
up
the
user
experience
I'll,
try
to
open
a
discussion
and
try
to
like
document
what
I
think
at
least
what
I
have
seen
in
the
field,
the
personas,
the
sure.
B
Who
use
hotel
python
and
and
what
they
what
they
require
and
try
to
try
to
document
a
hypothetical
like
package
or
interface
that
not
hybrid,
okay,
I'll
try
to
document
how
two
or
three
different
ways
people
get
started
with
at
least
splunk's
distribution,
for
example,
from
my
own
experience
and
signal
for
that.
Maybe
that'll
give
us
a
better
idea
and
for
for
next
week
can
if
anyone
anyone
who's
interested
in
this
solving
this
issue,
should
that.
B
A
I
think
that'd
be
good
yeah!
Okay,
if
you
could
start
that
would
be
great
nathaniel,
I'm
if
you
could
like
write
down
what
you
just
said
in
the
chat
in
that
discussion,
like
any
any
point
of
like
any
data
point
that
we
can
get
would
be
great.