►
From YouTube: Working Group: 2020-07-07
Description
* Idle Issues
* Roadmap Draft: https://docs.google.com/document/d/1XkjA966jDJVyR1Bx94HYHZNIOUDyg4YvyrWSnEKhXhc/edit
* GraalVM and Tiny
* Dependency Prefixes
A
A
A
B
C
C
B
Alright,
let's
kick
things
off
so
first
thing
on
the
list
is
review
outstanding
project
level,
RFC's
I
think
there's
one
project
level
RFC,
which
is
the
Cato
Community
Charter
Forest.
You
didn't
add
that
to
the
agenda
jus
want
to
talk
about
that
today,
it's
in
draft,
so
we
wouldn't
talk
about
it.
Normally
yeah.
D
D
D
E
Yeah
I
just
noticed
that
there
are
some
issues
in
those
two
repos
that
appear
to
the
idle
aren't
being
worked,
haven't
been
responded
to
in
some
time,
and
whoever
the
maintainer
--zz
of
those
repos
are
should
probably
have
another
passive.
Those
make
sure
that
the
community
is
being
prioritized
their.
B
Makes
sense,
I
think
they're
currently
reach
hardening
to
just
focus
their
team
on
stacks
and
builder,
like
like
I,
guess
not
builders
in
particular,
because
that's
more
of
an
a
grading.
It
build
packs
with
the
stacks,
but
but
on
stacks,
and
so
we
should
figure
something
out
for
builders
like
who
who
should
monitor
that
repo
and
then
I'll.
Let
the
relevant
team
know
to
keep
track
of
the
stacks.
We
both
there
are
officially
part
of
the
project
and
should
I
show
up
here.
B
F
F
B
B
E
Assume
Tiny's
already
been
released
many
times
since
some
of
it
went
in
it
was
the
so
Livesey
gets
to
come
back
out
and
we
get
to
basically
send
tiny
back
to
what
it
was
originally
tons,
consumed
that
they
were
going
to
only
statically
compiled
in
like
Lib
standard
C++
and
whatever
the
hell,
the
other
one
was,
but
they
went
whole
hog
and
added
flimsy
as
well.
So
good
result
an
unexpected
result
on
their
part,
but
it
does
take
us
even
closer
to
what
distro
listen.
What
time
you
used
to
be
next.
B
Week,
you
don't
have
a
lot
of
people
using
that
tiny
image
and
productions
are
practically
at
this
point.
I
think
it's
okay
to
movie
thing,
but
in
the
future
we
should
think
about
how
we
might
cuz
it
would
be
an
API
breakage
to
remove
it.
Alright,
it's
technically
like
not
that
not
the
thing
we're
supposed
to
do,
but
I
think
it's
okay.
For
now,
maybe.
B
B
Io
build
packs,
decks
Bionic
when
we
distribute
that
we
put
all
the
package
names
in
mix-ins,
regardless
of
whether
they're
defined
to
be
in
the
base
thing,
anyways
and
so
like.
But
what
matters
is
how
we've
defined
a
little
tax
tax
by
on
it,
because
instead
of
packages-
and
we
haven't
defined
tiny
package
anywhere
formal
assets,.
B
F
E
Somebody
asked
a
question
about
when
they
are
running
Paquette
Oh
build
packs,
specifically,
so
not
the
other,
not
tamsui,
build
packs,
but
picado
build
packs
in
enterprise
environments,
whether
that's
inside
of
something
like
a
pack,
a
pack
directly
on
the
machine.
What
have
you
something
like
that?
It
is
very
common
for
enterprises
to
have
firewalls
that
disallow
certain
domains
and
github
is
a
common
one.
E
In
enterprises
they
don't
want
people
pushing
their
corporate
code
to
github
the
a
very
large
number
of
our
build
packs
download
from
github
the
ones
that
don't
there
was
I
managed
to
go
extract
the
entire
list.
Coincidentally,
there
are
exactly
100
dependencies
in
our
Bionic
builders
re
our
full
C
F
builder.
At
the
moment,
other
ones
are
domains
that
will
not
have
been
allowed
either.
Typically,
these
are
handled
as
broadly
both
allowed
and
disallowed
lists,
and
basically
no
one's
going
to
be
able
in
those
environments
their
current
download
behavior
is
going
to
be
completely
broken.
E
It
is
common
for
developer
critical
things.
Then
they
just
replicate
them
in
to
a
repository
somewhere
in
their
own
enterprise,
but
not
necessarily
in
the
same
directory
structure.
So
you
can't
do
something
as
simple
as
swapping
out
a
domain
name,
the
way
you
might
like
a
maven
repo
or
a
go
repo,
or
something
like
that.
Sometimes
it's
just
like
a
bunch
of
flat
files
just
sitting
somewhere,
so
the
developers
can
have
access
to
them,
and
so
we
likely
want
to
come
up
with
some
sort
of
general
solution
about
this.
E
B
F
E
B
They're
also
very
large,
and
so
it's
they're
not
always
the
best
solution
for
solving
a
problem
of
like
like
they're,
a
great
solution.
If
you
need
to
have
totally
air-gap
builds,
which
is
a
use
case,
that
a
lot
of
enterprises
have,
but
one
because
there
are
some
things
that
don't
have
a
nice
redistribution
licenses
in
them.
We
don't
want
a
package
with
the
build
packs
and
then
ship
on
you
know
largely.
E
What
a
user
want
it
right
like
the
first
time,
somebody
does
your
pack
bill
that
goes
and
downloads,
it
downloads
say
the
BellSouth
library,
cuz
JVM,
build
pack
that
we
packs
by
default.
For
most
users,
they
only
need
about
30
Meg's
of
the
dependencies
in
there.
If
we
packed
on
our
package
and
offline
bill
pack
could
be
like
800
Meg's
of
dependencies,
only
30
of
which
they'd
ever
use.
So
there
is
a
compelling
argument
that
for
most
non
air-gap
solutions,
offline
build
packs
are
actually
worked.
This
one
is
debatable.
B
Dan's
Ric
would
support
his
packaging
just
or
like
for
my
interpretation
of
it
dan.
You
can
correct
me
if
I'm
wrong
would
be
you
know
just
packaging,
the
latest
patch
versions
or
the
latest
patch
version
of
latest
dependency
line
or
whatever.
How
would
you
weigh
that
against
you
know,
just
the
ability
to
to
package
build
packages
that
way?
How
would
you
weigh
that
against
the
ability
to
configure
the
prefix.
E
It
doesn't
particularly
help
me
because
I
only
basically
have
the
latest
8
the
latest
11,
the
latest
14,
so
major
lines,
but
I
need
both
JDK
and
JRE.
Cuz
I,
don't
know
if
you're
going
to
compile
from
source
or
not,
and
so
with
the
exception
of
maybe
leaving
out
before
teens,
which
almost
nobody
should
be
using
the
difference
between
8-11.
You
know:
you've
got
to
have
four
of
the
six
of
those
to
be
sort
of
broadly
applicable
picking.
E
Just
the
JRE
411
isn't
likely
to
be
a
great
use
case
for
for
most
Java
developers,
but
unlike
the
but
weighing
that
against
the
prefixed
thing.
I
have
no
idea
like
we
did
this
in
the
in
the
old
Java,
build
pack
in
the
cloud
foundry
job
and
build
pack
by
basically
having
a
way
for
you
to
change
the
hostname
and
you
were
required
to
replicate
our
repository
right
are
unified.
All
downloads
come
from
your
repository
in
its
structure.
E
We
even
wrote
a
script
to
do
like
an
AWS
sync
against
our
bucket,
but
we
moved
to
this
new
dependency
thing
where
we
don't
maintain
any
centralized
structured
repository
that
all
links
could
go
to
and
you
could
get
away
with
doing
a
uniform
replication
and
swapping
out
a
hostname
and
even
that
a
lot
of
people
complained
about,
but
like
we
don't
have
that
right.
Some
of
them
go.
You
know
and
look
at
they'll
sauce
URL.
Some
look
at
github
URL.
E
E
B
E
B
E
B
Config
map
that
represents
that
does
a
file
per
directory
vert
like
there
I
think
you
can
do
it
any
way
you
want,
because
it
can
figure
out,
can
be
any
number
of
files
in
here
to
this.
It
could
be,
you
know,
within
a
directory,
and
you
could
use
the
directory
structure.
I
present
the
names
of
versions
or
it
could
just
be
one
giant
tamil
file,
but
don't
extrinsic
it's
about
two.
This
yeah.
E
It's
it's
not
that's,
certainly
not
the
worst
thing,
I've
heard
so
I'd
be
willing
to
give
that
a
go
yeah,
but
it
is
a
very
weird
thing
like
this
is
one
of
those
things
that,
like
the
Heroku
team,
never
has
to
deal
with
right
because
they're,
basically
always
online
they're.
Never
behind
these
weird
firewalls,
these
weird
exclusionary
network
setups,
so
that.