►
From YouTube: Working Group: 2021-01-26
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
There
we
go
all
right,
let's
go
ahead
and
get
started
with
this
meeting.
Let
me
share
my
screen
really
quickly
with
the
agenda
on
it
and
we
can
get
started
so
one
second,
sorry
I
gotta
get
mine.
Gotta
get
my
whole
zoom
setup
going
there.
We
go
okay,
standing
items
start
recording.
We
did
that
excellent
next
up
review
outstanding
project
level
rfts.
A
So
here
we
are
in
the
project
level.
Rfc's
thing
it
looks
like
there
are
a
couple
of
new
ones
in
here
start
from
the
top
and
work
our
way
down
moves
implemented,
rfcs
into
a
slash,
implemented
directory
per
rfc
process
ryan.
It
looks
like
you
put
this
in
an
hour
ago.
B
This
isn't
an
rfc,
it's
just
a
pr
that
moves
a
bunch
of
files
around.
If
you
read
the
readme
and
the
rscs
repo
one
of
the
very
last
things
it
says
is
once
an
rfc
is
implemented
that
it
should
be
moved
to
the
implemented
directory.
B
I
personally
would
find
this
really
helpful.
It
would
help
me
recognize
when,
like
we
have
something,
that's
been
lingering
in
the
accepted
state
for
a
long
time
and
we
haven't
implemented
it.
I
think
it
makes
it
much
clearer
that
we
have
like
outstanding
rfcs,
like
the
web
server
rse
and
the
rust
rfc
that
have
been
just
sitting
there
for
quite
a
while,
and
we
should
probably
start
to
do
something
about
them.
A
C
C
B
A
This
is
an
rfc
that
already
has
a
little
bit
of
discussion
on
it
is
there
anything
needs
to
be
done
with
this,
or
do
you
plan
on
discussing
this
later
in
the
working
group
meeting,
or
are
you
still
working
on
it.
B
So
the
idea
generally,
is
that
the
the
build
pack
repos
that
we
maintain
have
grown
to
like
such
a
point.
We
have
you,
know
more
than
a
hundred
repositories
across
the
paqueto
build
packs
and
the
keto
community
orgs
it's
really
hard
for
me
as
a
maintainer
or
contributor
to
a
bunch
of
things
to
see
where
there
may
be
like
minor
fires
growing.
So
I've
got
like
a
whole
bunch
of
questions
that
I've
wanted
answers
to
and
every
time
I
want
an
answer
to
it.
B
I
have
to
like
reverse
engineer,
how
to
figure
out
the
answer
to
that
question,
rather
than
it
being
something
that's
like
readily.
You
know,
discoverable
via
some
sort
of
dashboard
and
github's
ui
for
a
particular
like
a
specific
build
pack
is
actually
pretty
good.
B
I
can
just
go
visit
the
build
packs
like
the
the
repositories
page
and
discover
the
answers
to
like
most
of
these
questions
but
like
when
I
want
to
view
the
like
organizations
in
aggregate
to
discover
things
like
are
we
you
know
failing
to
release
buildbacks
in
any
sort
of
timely
manner
for
a
particular
language
family?
It's
like
I
have
to
go
visit.
Five
or
six
different
repos
to
like
discover
the
answer
to
that
question.
B
So
you
know
over
the
last
couple
of
months
I
just
threw
together
something
that
I
was
finding
useful,
which
was
a
dashboard
that
just
showed
me
radiated
some
of
this
information
by
just
crawling
the
github
api
and
like
exposing
it
to
to
me
through
a
ui
that
I
could
look
at
so
there's
a
couple
examples
here.
You
can
see
that
the
yarn
install
example.
What
that's
showing
me
is
that
the
yarn
install
repository
has
four
open
issues:
no
open
pull
requests,
the
most
recently
released
version
is
0.2.2
and
it's
six
commits
behind
main.
B
B
B
The
dashboard
also
includes
a
listing
of
like
open
issues
and
pull
requests.
I
don't
have
a
picture
of
it
in
the
rfc,
but
if
you
actually
visit
the
dashboard,
you
can
see
there's
a
listing
of
open
issues
and
prs
in
like
reverse
chronological
order,
which
is
useful
for
just
finding
issues
that
have
been
open
for
a
long
time
so
that
you
can
hopefully
do
something
about
them.
D
I
just
read
through
this:
I
think
it's
a
great
idea
and
one
question
and
one
somewhat
selfish
concern
the
one
question
being
I'm
surprised
there
isn't
something
we
can
pull
off
the
shelf
to
do
this.
Did
you
spend
any
time
looking
whether
there's
something
that
might
be
free
for
open
source
projects?
That
creates
a
dashboard
like
this?
For
us.
B
I
saw
things
that
were
like
pieces
of
it.
There
were
like
there
certainly
was
stuff
that
was
like
you
know.
You
can
just
pull
in
this
like
plug-in
for
a
vue.js
app
and
it
will
like
show
you
a
bunch
of
stuff,
but
then
like
extending
it
beyond
that
to
get
answers
to
like
some
of
the
other
questions
I
had
was
like
not
really
all
that
possible,
you
immediately
would
be
like
cool.
I
have
this
plugin.
B
That
does
one
thing,
but
then
I
need
to
like
customize
it
in
some
other
way
or
like
completely
from
scratch.
Do
something
else,
and
I
couldn't
really
find
anything
that
was
like
a
like
a
sash
sausage,
offering
I
don't
know.
I
was
kind
of
surprised.
D
And
then
my
selfish
concern
is
that
I
don't
like
the
the
commits
being
read
because
our
travel
build
packs,
get
spammed
with
commits
whenever
we
update
ci
scripts.
But
maybe
that's
something
that
we
could
work
on
on
our
side
to
make
it
less
noisy.
B
Right
and
yeah,
as
far
as
implementation
goes,
it's
like
a
pretty
straightforward
react
app.
So
if
folks
are
interested
in
doing
like
react
development
or
want
to
make
modifications
to
any
of
it,
it's
right
there
to
change
so.
A
A
Okay,
let's
move
on
to
default
values
for
language
ecosystem
in
var,
set
by
build
pack.
This
is
yeah.
E
This
rfc,
with
a
catchy
name,
has
some
updates
on
it.
I
think
we
talked
about
it
in
the
last
working
group
meeting
or
otherwise.
There
was
just
some
discussion
on
the
rfc
itself,
and
so
I
changed
the
proposal
of
the
rfc,
basically
in
light
of
the
solution
that
people
seem
to
be
gravitating
towards.
So,
if
you
look
back
at
it
now,
it
proposes
something
completely
different
than
it
did
before,
and
I
think
this
proposal
is
probably
better
and
almost
a
no-op
in
a
lot
of
cases.
A
All
right,
dependency,
library,
rfc.
A
A
B
B
I
think
that
the
determination
we
came
to
was
that
the
the
changes
that
we
would
make
is
basically
to
move
the
or
transfer
the
hp
to
http,
go
function,
build
pack
into
the
kettle
community
and
put
it
under
the
golang
family
and
then
not
introduce
a
top
level
functions
build
pack
instead,
for
this
kind
of
experimental
phase,
just
expect
the
the
folks
using
the
build
pack
to
kind
of
do
that
manually
either
through
a
custom
builder
invoked
at
the
pack
build
flag
kind
of
level.
B
It
looks
like
emily
has
approved
this,
and
I've
approved
this.
I
think
this
can
be
merged.
I
can
handle
that
after
the
meeting
and
then
we
can
see
about
getting
matt
to
transfer
the
repo.
What
if
we
made
a.
A
Oh,
you
can't
do
that,
never
mind.
I
was
about
to
say
what,
if
you
made
a
definition
for
like
a
like
a
package,
tommel
and
and
another
bill
pack
tommel
locally,
but
that
feels
and
then
I
just
remember
you
just
can't
do
that
so
never
mind.
A
I
was
like
what,
if
we
did
like
a
a
you
know
our
own
definition
such
that
you
could
build
it
using
pack,
but
maybe
we
just
leave
the
instructions
to
like
the
order
grouping
that
you
would
want
to
use
for
a
metabuild
pack
or
something
like
that,
so
that
you
could
build
a
meta
build
pack
around
it.
A
A
Sorry,
all
right,
and
I
think
with
that
we
are
done
with
top
level
rcs.
So
I
think
that
means
that
we're
going
to
get
into
language
specific
ones,
and
I
actually
think
that
we
do
have
a
new
language-specific
rsc
to
talk
about.
So
let
me
just
is
there.
I
assume
I
assume,
as
has
been
the
last
couple
of
weeks,
there
has
not
been
any
movement
on
this
php
restructure,
rfc.
A
E
I
mean
we
could
discuss
it
now,
there's
a
lot
of
like
technical
particulars
that
still
need
to
be
worked
out
with
this
right
now.
This
rfc
is
like
welcoming,
reads
and
dialogue
on
some
of
the
technical
open
questions
that
it
poses
for
a
little
bit
of
background.
E
There
is
currently
a
go
generate,
build
pack
that
was
like
written
by
some
users
in
open
source,
and
this
rfc
is
around
trying
to
figure
out
a
way
of
using
the
build
packs
api
a
little
bit
more
for
a
go
generate,
build
pack
so,
rather
than
just
having
it
detect
on
a
sort
of
you
know,
run
generate
environment,
variable
or
something
have
it
do
something
more
sophisticated
in
detection
and
hopefully
do
something
clever
about
understanding
what
tooling
is
going
to
be
needed
to
run
the
go
generate
directives
inside
your
source
code,
which
opens
up
many
cans
of
worms,
so
that's
kind
of
what's
being
hashed
out
in
the
rfc
right
now.
D
I
have
a
question
about
the
use
cases.
Maybe
this
is
just
particular
to
the
way
used
go
generate
in
the
past,
but
I'm
used
to
seeing
go
generate
something
people
run
sort
of
before
committing,
rather
than
as
part
of
the
build
process.
But
what
are
clearly
a
lot
of
people
are
running
generate
as
part
of
the
build
process.
If
we're
getting
community
contributions
around
it,
I'm
just
curious
what
the
when
someone
wants
to
do
that
versus
when
they
want
to
generate
code
that
actually
gets
committed.
E
B
I
mean
one:
that's
like
a
relatively
common
example
of
this
is
a
static
file
one,
but
not
in
the
way
that
you
would
expect
it's
not
necessarily
like.
Oh,
I
have
some
like
generated
text
files
or
something
that
I
want
to
embed
into
the
the
binary
that
maybe
gets
built.
Instead,
it's
more
like
I
have
an
executable
or
like
a
massive
tarball
that
gets
downloaded,
and
I
don't
want
that
checked
into
my
repo,
because
I
don't
really
consider
it
to
be
something
that's
part
of
my
source
code.
B
I
I
view
it
as
like
a
build
artifact.
It's
like
those
are
a
couple
of
cases.
I've
heard
that
seem
reasonable
to
me,
where
you're
running
a
go,
generate
command
at
build
time
rather
than
like
ahead
of
time
and
checking
it
into
your
repo.
E
E
So
like,
for
example,
you
can
use
a
go
generate
directive
to
run
just
about
any
tool
and
go
will
manage
to
do
it
if
it's
on
the
path
and
it'll
fail,
if
it's
not
on
the
path,
so
that
sort
of
opens
up
this
whole
thing
of
well,
okay,
you
know
you
can
go
generate.
I
don't
know
curl
something,
and
if
you
have
curl
installed
on
the
system
like
on
the
path,
then
it'll
work,
otherwise
it
won't.
So
how
could
we
have
the
build
pack
know
that
it
needs
that
tool
and
then
behave.
A
Cool
it
sounds
like
you're
just
looking
for
feedback
right
now,
so
if
y'all
have
any
feedback
or
vested
interest
in
your
ability
to
run
go
generate
during
the
build
process
of
your
container
feel
free
to
check
it
out.
A
Have
you
reached
out
to
the
cnb
group,
because
I
know
that
you
correct
me:
if
I'm
wrong,
they
do
use
the
go,
build
packs
currently
to
generate
containers
with
their
code
inside
of
it.
I
think
lifecycle
containers-
maybe
maybe
I'm
maybe
I'm
totally
wrong
about
that,
but
have
you
reached
out
to
them
as
a
potential
group
to
be
interested
in
looking
at
this.
D
We
definitely
looked
into
using
the
go
build
pack,
but
the
weird
thing
is
that
you
want
to
install
the
life
cycle
into
life
cycle
and
that's
one
of
the
paths.
You
can't
install
things
too
right,
like
there's
rules
about
what
paths
the
final
binaries
have
to
be
at
that
make
it
a
weird
case
for
build
packs,
but
I
think
there
definitely
was
at
some
point
an
effort.
I
don't
know
whether
it's
been
done
or
not,
to
build
pack
containers
with
the
go
build
pack.
A
I
I
also
think
that
I
was
confused
and
the
the
team
I'm
thinking
of
was
actually
build
service
as
well.
I
think
build
service
belts
built
some
of
their
artifacts
using
pack,
but
that
could
also
be
wrong
so
yeah.
It
might
be
interesting
to
reach
out
to
the
teams
that
do
like
kpac
and
cnb
and
see
if
any
of
them
care.
E
A
Awesome-
and
I
think
with
that
we
are
at
the
end
of
all
of
the
standing
items,
so
we
can
get
into
the
rest
of
the
agenda.
First
off
is
the
self-hosted
blog.
B
Yeah
we
had
community
outreach
as
a
thing
that
we
were
going
to
want
to
focus
on
in
the
2021
roadmap
and
the
blog
we
have
today.
That's
linked
from
the
website
is
currently
like
a
medium
style.
Blog.
B
B
B
It
would
allow
everyone
to
contribute
blogs
pretty
easily
through,
like
a
pr
process
before
I
like,
went
and
wrote
up
a
whole
rfc
about
doing
this.
I
was
just
interested
if
folks
had
some
obvious
objections
to
doing
that,
or
if
it
was
something
folks
feel
like
is
a
good
a
win.
I
think.
A
You
know
it's
a
relatively
easy
thing
for
us
to
implement,
but
if
it
is
a
thing
that
is
already
implemented
for
us-
and
I
don't
know
medium
kind
of
feels
like
and
then
like
an
endemic
technology
in
a
way
for
doing
this,
I
don't
know
how
I
don't
know
if
it's
necessarily
a
huge
issue
to
continue
to
use
it
for
a
while,
and
I
don't
know
I
just
don't
know
that
I
necessarily
see
enough
upside
right
now
for
doing
a
self-hosted
blog
to
make
me
want
to
do
that
over
just
medium.
D
Posts,
it
might
be
worth
doing,
self-hosted
blog.
My
other
devil's
advocate
point
would
be
that
just
from
a
design
angle,
I
feel
like
right
now.
The
experience
of
landing
on
medium
feels
cleaner
and
professional
than
landing
on
paquetto
io.
D
Because
we
haven't,
you
know,
put
as
much
thought
into
that
user
experience
right,
because
we're
mostly
focused
on
shipping
pillpacks
and
also
you
get
features
like
people
can
like
it
and
share
it
and
stuff
like
that.
That
we
probably
would
be
too
lazy
to
build
into
the
custom
one.
At
least
out
of
the.
E
A
B
Depends
upon
your
definition
of
pay,
I
think
me
having
to
spend
time
to
sign
up
and
manage
the
credentials
for
a
medium
account
is
a
cost
to
me,
regardless
of
the
currency,
that
I
pay
it
in
sure
yeah.
I
think
it's
it's
hard
enough
to
like
drum
up
interest
around
some
of
this.
Without
you
know
having
people
go
through
other
hoops,
even
if
that
hoop
is
just
logging
in.
B
I
think
it's
also
like
a
relatively
common
criticism
across
the
tech
blogging
ecosystem
that
people
are
relatively
frustrated
at
tech
blogs
being
hosted
on
medium.
For
exactly
this
reason,
I
feel
like
at
least
once
a
week.
I
see
a
tweet
scroll
by
in
my
feed
that
someone's,
like
oh
couldn't,
read
this
article.
It's
hosted
on
medium
hit,
the
like
pay
wall
and
like
frustration
with
that.
B
All
right
I'll
give
that
a
think,
so
the
things
we
care
about
it
sounded
like
that
were
brought
up.
It
was
like
it
should
look
good.
I
think
that's
like
reasonably
addressable
with,
like
I
probably
could
find
some
sort
of
theme
or
something
that
will
seem
like
mark
down,
really
nice
and
pretty,
and
then
the
second
one
was
like
shareability
like
having
some
sort
of
link
that
lets
you
like,
post,
a
facebook
or
post
a
twitter.
That
kind
of
thing,
I
think,
was
a
an
ask
and
the
last
one
was
liking
or
upvoting.
D
D
A
Sweet,
let's
get
into
implementing
the
rust,
build
pack
rfc.
B
Yeah
in
opening
that
pr
that
we
discussed
earlier
about
what
are
the
things
that
are
in
the
accepted
state,
but
not
yet
implemented,
there
were
these
two
rfc,
so
the
rust
one
and
then
the
web
service
rc
that
stood
out
to
me
as
things
that
have
been
accepted
for
quite
a
while,
but
we
haven't
done
anything
about
them.
I
think
step
number
one
is
for
both
of
them
establishing
maintainer
teams
so
that
they
can
have
someone
actually
look
after
them.
B
So
the
thing
I
think
I
want
to
gather
feedback
about
is,
if
folks
are
interested
in
maintaining
these,
so
that
we
can
find
a
couple
sets
of
maintainers
to
act
as
the
initial
groups
of
folks
doing
maintenance
for
this
from
there
once
we
have
humans
involved.
I
think
the
rest
of
it
is
more
technical
steps
of
just
transferring
repos
and
setting
up
permissions.
A
I'd
be
I'd,
be
more
than
happy
to,
I
guess,
sponsor
the
rust
buildback
in
that
capacity.
A
B
So
I'm
going
to
open
up
discussion
forum
topics
for
both
of
these
things
and
I'll
give
it
a
week,
and
we
can
discuss
it
next
week.
Anyone
who
is
interested
in
being
a
maintainer
for
one
or
both
of
those
build
packs
just
register
your
interest
on
the
discussion
forum,
topic,
yeah.