►
From YouTube: Working Group: 2020-12-08
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
C
A
D
A
quick
kind
of
big
update
on
the
pacquiao
side,
steven
and
ben
have
kind
of
decided
to
move
away
from,
like
the
steering
committee,
which
means
we
have
two
new
folks.
We'd
like
to
like
push
up
comes
as
no
surprise.
Emily
and
ben
have
been
doing
lots
of
awesome
work
since
we've
launched
the
project,
and
things
like
that.
So
ben
and
steven
would
like
to
promote
emily
and
ben
into
the
steering
committee.
D
Like
it's
my
mistake,
emily
and
ryan,
I
meant
I'll.
Let
ben
and
steven
talk
through
the
change
a
little
more.
We
want
to
share
out,
like
kind
of
a
feedback
form
as
well
just
to
solicit
any
feedback.
General
questions
you
all
might
have
and
perhaps
like
next
working
group
meeting,
we
could
talk
through
some
more
of
this
but
again
super
exciting
stuff.
Thanks
again
steven
ben
for
all
your
hard
work
and
hand
it
off.
A
To
you
guys,
yeah
I'll
go
ahead
and
get
started
here.
Obviously
many
of
you
realize
that
I
have
recently
taken
a
new
position
inside
of
vmware
working
sort
of
a
little
bit
higher
in
the
the
bu,
taking
a
look
more
broadly
at
developer
experience.
So
I
think
it
makes
sense
for
me
to
step
away
and
allow
people
who
are
you
know,
involved
day
to
day
with
the
pacquiao
build
packs
and
the
communities
that
they're
involved
in
to
take
over.
For
me,
I
couldn't
nominate
anybody
better
than
emily.
A
Obviously
she
is,
you
know
technically,
as
adept
as
you'd
ever
hope
and
to
go
along
with
that.
She
is,
you
know,
deeply
involved
with
the
spring
team
and
the
java
community
and
really
has
a
good
pulse
there.
She's
also
worked
for
you
know
quite
a
long
time
with
our
partner
products.
People
like
the
google
team
and
the
azure
team,
bringing
our
various
integrations
as
well.
A
B
And
similarly,
ryan
has
really
driven
out
the
architecture
of
you
know
the
modularization
of
sort
of
this.
This
whole
system
across
different
languages-
you
know
over
the
last
year
so
and
I've
recently
been
pretty
hands-off
anyways,
so
the
really
happy
to
to
have
ryan
kind
of
take
my
spot
there.
The
I'm
also
like
this
is
also
kind
of
driven
out
by
me
kind
of
having
a
bigger.
B
You
know
group
of
people
to
look
after
in
the
organization,
and
but
this
is
sort
of
still
within
my
my
purview,
and
so
I'm
happy
to
stick
on
for
as
long
as
kind
of
emily
and
ryan
need
to
feel
like.
I
would
make
sense
for
me
to
stick
on,
but
just
just
let
me
know
yeah.
A
Yeah,
congratulations
to
you.
Both
cash
up
mentioned,
and
I
want
to
reiterate
there
is
an
anonymous
feedback
form.
We
realize
that
you
know
this
is
two
leaders,
basically
picking
what
their
next
two
leaders
are
going
to
be,
but
we'd
love
to
have
your
feedback
on
it
good
or
bad.
It's
anonymous
we'll
address
everything
that
comes
in.
That
needs
to
to
be
addressed,
to
make
sure
that
you
know
the
the
members
of
the
community,
the
contributors
to
a
project
like
this
feel
comfortable
with.
What's
going
to
come
next,
the.
B
Governance
process,
for
this
would
be
for
steering
committee
members
to
appoint
new
steering
committee
members
by
vote
right
and
so
that
this
is.
This
is
the
normal
way
it
would
happen.
Just
usually
doesn't
involve
two
people
stepping
down
at
the
same
time
as
two
people
being
elected
there
for
folks
that
are
wondering.
A
I
think
that's
it
and
we
can
move
on
to
the
next
bit
stephen
since
you
actually
run
this
meeting
normally
I
do.
I
guess
I
do.
B
Next
thing
is
review
outstanding
project
level
rfcs,
it
doesn't
feel
like.
I
run
this
meeting
because
it's
been
on
vacation
since
the
last
one.
The
let
me
share
my.
B
E
So
first
thing
we
have
is
dependency
library
rfc
from
marty.
I
think
this
was
discussed
in
the
last
meeting
and
there
wasn't
too
much
feedback
around
it.
I
think
it's
just
waiting
for
approval
now,
if
I
understand
correctly.
B
Are
you
just
just
still
looking
for
feedback?
No,
no
immediate
actions
right
now,.
B
Next
on
the
list
is
propose,
go
http.
Functionful
pack
is
this.
Is
this
the
agenda
today
to
talk
about.
B
See
matt,
you
put
a
link
there
so
yep,
so
I'm
gonna
skip
over
that
until
we
get
to
it
done,
lost
docker
hub
distribution.
F
I
don't
think
that
there
was
anything
that
was
blocking
this.
I
just
have
to
go
through
a
lot
of
the
buildbacks
and
open
issues
to
say
this
is
what
needs
to
be
done.
B
B
E
And
that's
it
for
project
level,
grab
the
link
to
language
level,
ones.
B
So
these
are
all
merged.
Do
we
ever
figure
out
how
to
I'll
just
go
with
the
one
star
merged
this
one
migrate
from
build
pack
gamma
to
environment
variables,.
H
I
don't,
I
don't
believe
there
are
any
unresolved
issues,
they're,
just
waiting
for
the
merge
from
the
maintainer.
B
Cool
I'm
gonna
go
through
this
kind
of
quickly
migrate
from
build
pick
your
mobile
environment
variables
for
go
forest.
Any
updates.
There.
E
Cool
and
I
think
that's
it.
B
All
right
next
thing
on
the
list
is
rfc
29
on
that.
I
I
think
the
only
thing
that's
changed
here
is:
I
incorporated
some
feedback
from
ryan
last
week.
Otherwise
I
don't
know
what
is
next
in
the
process
for
this
stuff.
So
I
put
together
the
a
go
fm
repo
that
basically
implements
the
sort
of
meta
build
pack
that
attaches
the
function,
build
packs
at
the
front
of
the
order
for
the
existing
picato
build
pack
to
get
the
go,
build
packs
without
inlining
the
order.
So
that
was
a
nice
trick
to
avoid
you
know
needing
to
explore
the
guts
of
all
the
existing
build
packs.
B
B
I
Right
so
I
mean,
I
think,
every
one
of
the
function
build
packs
is
going
to
need
deep
language
expertise
that
you
know
I
y'all
are
certainly
much
broader.
You
know
at
in
terms
of
language
expertise,
you
have
written
nude,
build
packs
and
python
build
packs
and
all
the
ruby
build
packs
right.
So
I
I
mean
part
of
the
reason
I
started
with
go
here
was.
I
That
is
where
I
can
pretend
to
be
a
language
expert,
not
because
you
know
yeah,
so
I
I
think
that
you
know
I
in
the
fullness
of
time
yeah.
I
I
think
part
of
the
reason
that
this
is
sort
of
a
top,
an
interesting
top
level.
Rfc
is,
I
think
it's
eventually.
This
will
be
interesting
for
all
the
different
languages,
and
so,
if
there's
considerations
that
should
be
made
more
broadly,
you
know,
I
think
earlier
is
better
there,
but
yeah
gotta
start
somewhere.
So
this
is
this.
Is
me
starting
somewhere,
so.
J
Maybe
even
practically
speaking,
it
appears
that
the
go
function
build
pack
runs
on
top
of
our
current
existing
go
build
pack
without
any
other
modification
internal
to
go
the
build
pack.
So
it
seems
a
little
weird
to
treat
it
as
if
it
is
a
component
of
the
underlying
go
buildback,
but
I
could
maybe
be
I
mean
I.
I
can't
that's
not
too
far
of
a.
F
Jump,
I
think,
for
some
of
the
other
languages,
especially
those
that
are
dynamic
languages.
I
think
there
was
a
question
of
whether
or
not
the
function
build
packs
themselves
would
be
able
to
do
anything
if
they
couldn't
look
at
say
some
of
the
function
signatures
of
what
the
node
codebase
was
providing,
in
which
case
like
you
might
need
node.
In
order
to
do
the
inspection
itself.
I
Yeah,
so
I
think
we're
playing
with
having
node
in
the
detect
phase
and
being
able
to
fuss
around
a
little
bit.
I
think
you
know
a
distinction
worth
making
is
how
much
you
can
do
with
zero
configuration,
which
I
think
you
know,
is
sort
of
a
lovely
goal.
I
But
you
know
it
may
be
an
intractable
role
for
dynamic
languages,
where
you
can't
do
more
sophisticated,
like
signature
analysis,
because
you
know
who
knows
what
it
does
right
just
by
loading
it
to
look
at
the
signature,
you
might
have
side
effects
which
yeah.
So
it
is
possible
that
some
amount
of
configuration
will
be
needed
in
certain
language
contexts,
but
you
know
it
at
least
for
go.
I
I
think
we've
been
able
to
get
pretty
far
with
some
of
the
language
libraries
in
terms
of
being
able
to
have
effectively
zero
configuration
in
the
sort
of
default
case,
but
having
configuration
to
customize
aspects
of
how
it
works.
So
you
know
which
package
and
function
name,
for
instance,
get
wrapped
are
configurable
things.
It
can
default
to
a
particular
package
and
function
name
if
one
are
specified,
given
the
the
ability
to
do
that
detection.
I
So
so
yeah
I
mean
it
may
make
sense
to
define
sort
of
conventions
for
the
kinds
of
you
know:
environment
variables
or
whatnot
that
are
used
across
languages.
It's
sort
of
like
you
know,
there's
been
some
conversations
about
like
you
know,
bp
food
target
sort
of
variables
or
whatnot.
I
At
least
that
was
discussed
last
time
a
little
bit,
but
you
know
having
conventions
around
that,
I
think
is
one
thing
to
possibly
consider
and
then
keying
off
of
those
variables
in
the
function
build
packs.
You.
A
I
It's
sort
of
a
hacky
detect
method
to
be
like,
oh
yeah,
this
environment
variable
was
set,
I
am
going
to
say,
yeah.
I
detected
it
right,
but
that
is
what
virtually
every
existing
function
build.
Pack
does
I
mean
so
riff
had
rift.tamil
the
google
build,
packs,
use
google
function,
target
and
well
the
the
red
hat
ones.
Don't
use
environment
variables,
they
package
each
as
its
own
builder,
so
I
think
their
detect
has
just
you
know
been
true
or
whatever,
but
yeah.
So
I
I
think
that.
F
So
I
think
to
me
what
stands
out
as
kind
of
the
next
steps
are
probably
a
top
level
rfc
establishing
a
sub
team
to
kind
of
own
and
maintain
a
set
of
function,
build
packs
in
the
community
organization
and
then
us
going
ahead
and
pulling
in
as
a
top
level
language
family
of
functions
build
pack.
That
includes
currently
the
implementation
that
the
two
implementation
function
build
packs
that
you've
written
and
the
go
build
pack
together
as
a
functional
unit
and
from
there
we
can
start
to
kind
of
incubate
and
explore
node
and
python
and
java.
F
B
F
I
think
at
this
point
it's
kind
of
dependent
upon
what
we
learn
right.
We
may
learn
that,
like
we
can
accomplish
this
as
kind
of
an
orthogonal
concern
for
all
the
different
language
families,
and
it
may
make
sense
to
have
a
separate
sub
team,
that's
capable
of
maintaining
those
across
a
number
of
languages.
F
We
also
might
learn
that
you
know
it's
way
better
to
have
them
like
highly
integrated
with
the
language
families
themselves,
in
which
case,
like
those
things,
would
probably
be
adopted
all
the
way
up
into
their.
You
know,
language
family
build
pack
proper,
but
I
think
I
don't
know
from
what
I'm
hearing
right
now.
It
sounds
like
we
need
more
information
before
making
a
decision
like
that.
A
One
place
to
look
at
this
might
be
actually
the
rift
build,
packs,
they're,
sort
of
the
same
kind
of
function,
model
they're
a
bit
more
oriented
towards
streaming,
rather
than
sort
of
individual
eventing,
the
way
the
canadian
style
is,
and
while
it's
not
I'm
not
saying
adopt
their
build
packs,
they
actually
have
a
range
of
languages,
and
I
think
the
the
takeaway
was
that
those
implementations
end
up
being
so
far
from
one
another
and
so
tied
to
individual
build
packs.
They
ended,
ended
up
being
you
know,
very
tied
to
the
particular
languages
themselves.
A
B
D
This
is
me,
I'm
more
of
a
messenger
here.
I'm
not
quite
sure
I
understand
the
request,
but
figured
I'd
bring
it
up.
I
think
ryan
maybe
set
up
the
paquetto
slap
instance.
Originally
stephen.
D
B
Yeah,
I
think
our
tls
search
for
all
the
potato
domain
and
sub
domain
stuff
for
management
github
pages,
except
for
slack.kato.io,
which
is
like
app
on
pws
and
pws,
is
going
to
go
down
soon,
so
they
were
going
to
offer
to
move
it
for
us,
but
I
wanted
an
ssl
cert
for
slack.kato.io,
so
I
think
there
are
a
bunch
of
ways
we
could
deal
with
this.
We
could
just
do
it
on
github
pages
with.
B
I
think
it's
just
a
static
link
like
it's
just
a
redirect,
so
we
can
do
it
on
github
pages,
with
a
meta
refresh
or
something
so
like
if
we
really
wanted
to
not
have
to
deal
with
it,
but
that
that's
gonna
go
down
soon.
So
we
should
think
about
it.
D
B
All
right
anything
else
for
the
end
of
the
agenda,
any
other
items
anybody
forget
to
write
down
like
that.