►
From YouTube: Working Group: March 7, 2023
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
A
All
right,
it
might
just
be
a
small
group
today-
we'll
go
ahead
and
get
started
anyway.
Let's
see,
can
I
get
someone
to
volunteer
to
take
some
notes
today.
B
B
Do
I
for
notes,
unlike
the
rfcs,
do
I
take
them
into
rfcs
themselves.
They're
on
on
this.
A
Yeah,
we've
usually
done
actual
comments
about
the
rfcs
as
comments
on
the
the
rfcs
themselves
and
then
any
other
stuff.
You
could
probably
just
like
inline
into
the
agenda
wherever
it
makes
sense.
C
A
All
right
so
then,
speaking
of
rfcs,
let's
go
ahead
and
take
a
look
at
the
rfcs.
Let
me
share
my
screen.
A
And
I'm
going
to
skip
over
these
two
Java
ones.
Unless
there
are
some
objections
here,
I
feel
like
we've
talked
about
them
or
brought
them
up
at
every
meeting
for
a
while
and
not
making
much
progress
at
the
moment.
So
they'll
just
sit
there
and
actually
updated.
C
The
I'm
sorry
never
mind
no
you're
right,
never
mind.
Okay,.
A
Yeah
I
was
I,
I
was
about
to
open
this
up
and
we
can
talk
about
anything
that's
going
on
here.
So.
C
I
made
some
updates,
based
on
some
comments
from
Daniel
and
I've,
asked
the
build
maintainers
to
the
Builder
maintainers
to
review
and
comment
specifically
on
the
the
ownership,
the
joint
ownership
proposal.
C
A
A
But
other
than
that
I
read
through
it,
it
seems
like
it's
in
a
pretty
reasonable
State.
At
this
point,.
A
All
right
next
up
is
this
RFC
for
steering
committee
elections.
I
think
this
is
in
a
state
where
it
is
mergeable,
Dan
being
the
only
other,
actively
participating,
steering
committee
member.
A
We
have
today
so
myself
as
the
author
and
Dan's
approval,
puts
a
set
over
a
majority
and
so
I
think
we're
good
to
go
there,
which
means
we
can
start
to
play
in
the
actual
elections
process,
we'll
make
sure
that's
really
transparent
and
clear
and
folks
know
when
that's
going
to
happen,
but
yeah
we're
gonna
have
some
elections,
which
would
be
great
any
questions.
Anyone
had
on
this
or
or
any
comments
I
was
planning
to
go
ahead
and
merge
it.
After
this
meeting.
A
Great
everyone's
on
the
same
page
awesome
all
right,
and
that
brings
us
to
this
one.
That's
new
for
this
meeting.
I
think
we've
talked
about
this
a
little
bit,
but
also
you
want
to
give
us
some
background
on
this.
D
So
this
is
the
one
that
we've
been
talking
about
for
a
while,
which
is
the
idea
of
introducing
Ubi
based
base
images,
which
will
then
obviously
create
ubi-based,
Builders
and
Ubi
based
Run
images,
and
if
it
was
just
limited
to
that,
if
it
was
just
the
question
of
just
swapping
the
Ubuntu
stack
out
for
the
Ubi
stack
as
it
were,
then
it
would
be
a
relatively
small
RFC
but
I've
included
in
here
as
well
stacks
and
extensions.
D
So
we're
talking
about
here,
adding
extensions
that
will
provide
the
dependencies
for
runtimes
as
well,
because
that
gives
a
Ubi
Builder
the
capability
to
have
Java
or
node
installed
via
RPM,
rather
than
having
them
installed
via
the
downloaded
turbos.
That
happened
with
Poquito
today
and
I
think
that
fits
suitably
well
within
the
current
stuff
that
we've
got
within
the
keto,
because
you
already
allow
for
multiple
jdms
to
be
installed
via
different,
build
packs.
Essentially,
this
is
for
Java.
D
At
least
that
would
just
be
another
one
of
those,
but
for
node
that
would
be
probably
the
first
time
that
we're
allowing
a
a
second
implementation
of
node
to
be
offered
unless
people
were
playing
with
where
the
dependencies
came
from.
So
that's,
that's
it.
A
high
level
is
the
idea
that
we'll
end
up
with
a
ubi-based
builder,
we're
proposing
One
to
begin
with
just
the
single
Builder
image
for
Ubi,
we'll
support,
node
and
Java
off
the
off
the
bat
as
it
were,
because
you
know
we've
got
the
experience
in
those.
D
We
do
expect
them
that
we'll
bring
in
more
as
we
go,
but
the
the
goal
will
be
to
look
at
like
the
Poquito
Java
meta,
build
pack
that
has
all
of
the
subs
and
get
that
whole
lot
shifted
over,
so
that
it
can
run
on
top
of
the
the
Ubi
by
stuff,
if
so
I
mean
so
we'll
have
our
thing
providing
the
have
the
extension
providing
Java
for
our
RPM,
but
the
entire
rest
of
that
little
Java
meta.
D
Build
pack
from
Poquito
would
then
run
as
part
of
the
Ubi
Builder,
and
the
same
thing
would
happen
for
node,
where
we'd
have
node
exist
and
come
over
from
Poquito.
So
everything
that's
currently
there
for
building
node
apps
will
come
over
except
I,
think
it
node
engine
that
supplies
the
actual
node
installer
itself
and
that
part
would
be
I,
wouldn't
say,
superseded,
but
it's
effectively
it's
it
can
still
be
present.
It'll
just
never
have
a
chance
to
do
anything,
because
the
extension
will
kick
in
first,
because
you
know
extensions
and
build
packs.
D
Both
look
at
the
project
to
see
what's
whether
they
want
to
be
involved.
They'll
both
say
yes,
but
because
of
the
ordering.
The
extension
will
always
run
first,
so
the
extension
will
get
the
option
to
run
first
and
we'll
go.
Oh,
hey,
I
need
to
provide
node,
node
gets
provided
and
then
by
the
time
load.
D
I've,
never
written
one
of
these
few
guys
before
my
first
attempt
at
putting
together
an
RFC
to
sort
of
describe
what
I
think
is
needed
and
where
we
go
from
here,
which
is
to
ask,
for
you
know
a
bunch
of
repositories
to
to
come
into
existence
and
then,
hopefully,
from
there
start
setting
things
up
so
that
we
can
start
building
out
I.
D
Don't
expect
we're
going
to
be
releasing
like
in
the
next
week
or
two
magically
but
I'm
thinking
that
if
we
can
get
the
the
stuff
up
and
start
getting
pipelines
in
place
so
that
when
we
put
code
in,
we
can
produce
releases
of
this
that
eventually
result
in
images
being
created.
Then
at
least
we
can
get
this
stuff
rolling
and
yeah
yeah.
So
I'd
ask
if
you're
interested
in
Ubi
stuff
to
read
through
this
comment
on
it.
D
Let
me
know
if
you
happen
to
be
part
of
any
of
the
people
who
will
be
involved
in
creating
repositories
or
setting
up
build
pipelines
or
your.
D
You
know
the
people
who
are
currently
doing
this,
please
let
them
know
to
look
at
this
as
well,
because
you
know
there's
nothing
in
here
that
I'm
expecting
to
be
different
from
how,
for
instance,
when
Poquito
set
up
the
Jammy
Stacks
recently,
you
know
when
they
created
the
whole
new
tier
of
stuff
that
came
along
the
main
difference
with
this
one
is
we're
only
proposing
creating
one
image
instead
of
trying
to
do
three
and
that's
purely
to
try
and
limit
the
amount
of
testing
that
we
need
to
do,
because
we
want
to
get
this
down
so
that
we
can.
D
You
know
if
we're
concentrating
on
just
Java
and
node,
for
the
first
build
cut,
then
we
can
test
those
a
lot
make
sure
they're
working
well
and
as
they're
working,
then
we
can
start
bringing
in
other
runtimes
and
expanding
out
to
to
include
more
stuff,
and
that
may
then
lead
to
us
fragmenting
the
single
Ubi
based
Builder
image
into
a
collection
like
exists
for
Jammy,
but
I.
Don't
think
they're
all
for
Ubuntu
ones,
but
I
don't
think
that's
needed
at
the
beginning.
E
I
I,
actually
out
of
curiosity,
because
you
you
already
envisioned
there
might
be
other
builders
besides
the
base,
one
like
similarly
to
Jimmy,
why
you
would
think
it's
it's
necessary,
as
you
anyhow
use
RPM
and
like
the
the
Ubi
means
to
extend
that
like
where
am
I.
What,
where
I'm
coming
from?
We
currently
produce
our
own
Jammy
based
stacks,
it's
tiny
plus
a
little
bit
so
that
we
can
run
node
on
it
and
we
are
actually
going
kind
of
the
reverse
right.
So
we
have
a
it's
similar
to
Tiny.
E
So
for
us,
it's
basically
a
distress.
Now
with
the
latest
change,
we
have.
We
actually
even
reduce
the
build
image
to
be
destroyless,
basically
because
it
doesn't
need
any
of
the
things
that
are
in
Ubuntu,
2204
and
I
can
Envision
in
the
long
run.
Even
if
we
would
plan
to
extend
when,
when
all
the
extension
stuff
comes
into
place.
To
actually
like
have
the
Jammy
notion
in
the
stack
actually
as
a
that's,
where
we
fetch
the
packages
from
but
the
actual
base
image
for
run
and
build
is
from
scratch
and
here's
the
list
of
packages.
E
We
need
for
note
and
it's
the
list
of
packages
we
need
for
Java
and
here's
the
for
the
next,
so
I
would
be
imagining
actually
there's
no
need
for
different
Builders
other
than
Maybe
and
then
coming
maybe
to
the
RFC
of
of
of
Kevin
other
than
the
127
layer
limit,
because
you
can't
just
put
any
more
build
packs
onto
it
right.
But
in
terms
of
what
the
basic
Linux
base
file
system
is,
I,
don't
see
a
need
for
a
different
one.
So
I'm
curious.
E
If
you
do
see
the
need
in
the
future,
as
you
have
more
experiences
with
building
distributions
right,
I
have
none.
D
Well,
I've
got
more
experience
floating
around
Ubi
and
and
this
from
this
perspective,
the
problem
that
we
have
here
is
that
we
want
to
get
to
the
point
where
the
application
is
running
on
a
ubi-based
container,
with
the
runtime
being
installed
via
RPM
yeah
yeah.
Now,
if
you
were
to
start
off
with
a
builder
that
started
from
scratch,
we
still
need
to
build
the
application
using
our
supported
runtime
as
well,
so
that
had
the
runtime
that's
going
to
build,
the
application
needs
to
be
installed
for
our
RPM.
D
E
I've
gone
one
step
too
far
in
my
description:
I
guess
sure.
If
we're
basing
it
on
a
Ubi,
you
need
something
there,
but
it's
a
single
piece
right.
You
could
similarly
argue
that
maybe
for
a
Jimmy
stack,
you
actually
want
to
up
get
to
be
somewhere,
but
on
the
other
hand,
side
you
can
provide
extensions
that
will
manage
to
actually
do
it
even
without
up
again
not
being
there
in
the
first
place.
Similarly,
could
be
true
for
RPM,
but
it's
it's
it's
kind
of
not
the
case
for
you
right.
E
You
plan
to
base
it
on
a
distribution,
the
basic
change.
It's
like
I
as
an
sap
employee,
I
am
not
the
owner
of
a
distribution,
so
I'll
try
to
reduce
that
and
great
to
have
a
similar
means,
no
matter
what
what
that
is.
You're
coming
from
a
different
point:
you're
coming
from
being
a
distribution
provider,
sure
you
base
it
on
the
distribution.
I
was
just
more
wondering
if
you
would
really
go
for
here's
now
our
base
thing
and
we'll
add
another
one
that
has
a
different.
D
D
Yeah
at
a
minimum,
I
mean
envisaging
that
we'll
need
a
second
Builder
just
to
handle
native,
because
I
know
that
the
dependencies
for
building
a
native
app
are
complex
and
okay,
at
least
in
the
research
I've
done
so
far.
The
distribution
mechanism
for
those
dependencies
for
Ubi
Stacks
is
a
pre-built
Ubi
image
that
has
those
dependencies
installed.
So.
D
Point
I'm
in
trouble
because
then
I
can't
actually
install
the
native
dependencies
using
RPMs.
I
have
to
go
and
extend
that
native
bass
image
to
gain
those
capabilities.
So
then
I
need
to
Fork
my
base
images
to
have
one
that
has
you
know,
extends
from
essentially
ubi8
minimals,
so
that's
as
close
to
empty
as
you're
ever
going
to
get
really
and
then
the
other
one
will
extend
from
whatever
the
native
compilation
base
would
be
as
far
as
going
beyond
that
goes.
It
entirely
depends
I.
D
Think
then,
on
sort
of
customer
demand,
because
we
know
node
and
Java
are
needed.
If
it
comes
down
to
the
fact
that
there
are
more,
it
depends,
then,
on
how
big
and
I
suspect
these
are
the
same
problem
to
a
certain
problem.
D
E
E
D
This
is
something
we'll
need
to
look
at,
because
I
am
not
sure
how
many
layers
fall
out
after
an
extension
has
run,
because
the
extension
extends
the
Builder.
But
that's
temporary,
because
that's
only
used
during
the
build
anyway.
And
what
we're
using
here
is.
What's
swapping
the
Run
image
to
a
pre-canned
run
image,
which
is
why,
somewhere
in
there
only
talks
about
the
particular
images
that
will
be
being
built.
It's
talking
about
having,
whereas
that
we've
got
like
run,
Java
Ubi
8
base
and
run
node.js
Ubi
8
base.
D
D
So
I
guess
in
a
way
we're
probably
down
a
a
layer
or
two
layers
already
as
in
less
than
the
traditional
weapon
to
approach,
because
we're
not
using
a
layer
to
store
the
RPM
to
store
the
just
sorry,
not
using
a
layer
to
store
the
runtime,
because.
E
I
think,
actually,
that
the
biggest
layer
limit
problem
that
there
is
is
packing
the
build
tags
onto
a
builder
image.
I
guess
not
actually
for
the
ones
it's
like,
because
every
every
component
build
pack
becomes
its
own
layer
and
now
put
in
their
five
meta,
build
packs.
You
will
have
quite
a
list
of
I.
A
D
I
think
I'm
I'm
Keen.
If
we
can
to
make
that
a
single
one,
they've
got
at
least
for
node
and
Java,
because
I
know
they'll
run
alongside
each
other.
They
don't
conflict
they're,
nice
and
Tiny,
because
the
extensions
don't
contain
the
dependency
because
it's
downloaded
via
RPM,
it
doesn't
add
any
real
weight
to
the
build
image
as
a
as
a
container
image
size.
So
that's
an
advantage
so
I
think
at
this
point
it's
easy
to
just
keep
it
as
the
single,
but
mostly
for
a
release
cycle
type
thing.
D
So
we
can
just
keep
it
as
one
and
just
keep
it
pushed
out.
Also,
the
advantage
with
having
a
single
image
is,
of
course,
the
from
a
tooling
perspective.
If
we
want
a
customer
to
say
use
this,
we
can
point
them
just
set
your
Builder
image
to
this,
and
and
you're
done
no
more,
no
more
configuration
needed
everything's
good,
whereas
I
think
the
reason
why
there
may
be
other
Builder
images
out
there,
based
on
Ubi
in
the
long
run,
may
start
to
come
in
as
I
think
I've
talked
about
some
of
this
in
yeah.
D
Maybe
not,
but
we've
been
thinking
about
offline
like
what
happens
for
air
gap
systems.
What
happens
for
offline
systems,
because,
obviously,
if
the
Builder
image
doesn't
have
the
dependencies
in
it,
RPM
still
needs
to
download
those
from
somewhere.
Now,
usually,
what
happens
in
these
kind
of
environments,
with
a
Ubi
rheel
type
install?
D
It
do
as
well.
The
two
generally
go
hand
in
hand
is
one
thinking.
People
who
are
air
gap
tend
to
be
absolutely
focused
on
the
versions
of
everything
that
they're
running
and
knowing
that
it
has
the
same
version
that
it
did
when
they
built
before,
and
you
know,
there's
a
it's
a
huge
requirements
thing
that
usually
all
goes
together
in
one
hit.
A
Pay
well
aware
of
the
the
trade-offs
of
one
big
Builder
versus
you
know:
lots
of
Builders
playing
yeah
again
Kevin's
RFC,
it's
it's
a
definitely
a
big
trade-off
right.
The
ease
of
use
of
having
something
like
the
full
Builder
is
great
yeah,
like
we
run
into
these
limitations,
and
it's
preventing
I
mean
we
basically
are
in
a
state
where
we
can't
add
any
more
things
to
the
full
Builder
right
now.
D
A
D
A
Now
you
only
have
those
two
languages,
you're
supporting
so
you're
you're,
probably
well
below
the
limit.
At
this
point,
yeah.
B
D
The
goal
is,
or
at
least
that
my
goal
with
creating
these
is
to
make
sure
that
although
the
extension
can
install
the
runtime
and
will
do
by
default
but
to
have
a
flag
there
that
disables
that
so
then,
if
there's
a
customer,
that's
really
adamant
that
they
want
to
run.
You
know
bellsoft
liberica,
on
top
of
a
ubi8
stack,
and
so
they
can
run
it
in
Amazon
and
then
do
something
very
strange.
D
Then
we'll
it'll
still
be
possible
to
do
that
and
there's
no
reason
because
from
a
technical
perspective,
it's
just
disable
the
extensions
Behavior
through
a
flag
and
then
later
on,
Java
will
kick
in
and
do
whatever
it
would
normally
so
I
think.
That's
that's
key
is
I
want
this
to
work
with
the
existing
ecosystem.
That's
there
as
much
as
possible,
rather
than
becoming
a
special
case
for
it,
because
I
think
that's
that
rapidly
becomes
unmaintainable
yeah.
The
goal
here
is
to
have
these
basically
look
and
feel,
like
any
other.
D
You
might
have
a
slightly
different
level
of
bash
as
your
default
version,
you
might
need
to
be
careful
of
which
flags
you've
used
on
some
stuff
which
scripts
you've
used
that
kind
of
stuff,
but
in
the
whole
the
bigger
change
here
is
making
sure
that
the
dependencies
can
come
from
RPMs
and
that
those
that
that
becomes
the
default
option
for
the
the
Ubi
application,
Packaging
I
guess
as
well.
D
The
Run
image
selection
is
different,
because
today
all
Poquito
applications
are
based
off
of
a
you
know,
a
common
run
image
for
the
stack
which
is
tailored
using
you
know,
layers
to
apply
the
runtime,
that's
required
to
run
the
application,
whereas
here
the
extension,
speeds
and
switch
is
away
from
an
empty
run
image
that
does
nothing
to
a
run
image
that
has
everything
pre-canned
and
obviously
there
are
still
layers
that
kick
in
to
apply
things
like
ca
certificates
and
stuff,
but
they're,
not
layers
that
are
applying
the
runtime
in
the
same
way.
D
The
problem
with
that
is
that,
as
soon
as
you
start
allowing
run
image
customization
through
extensions,
you
lose
the
ability
to
rebase,
because
your
common
base
image
that
you
started
with
is
empty
and
doesn't
have
the
runtime
in
it.
So
if
you
rebase
to
something
else,
these
steps
that
were
played
to
you
know
the
extensions
that
applied
their
Docker
file.
Manipulation
to
the
Run
image
never
have
that
option
to
run
again
during
a
rebase
operation
and
so
by
default.
D
E
Interesting
that
that's
the
first
time,
I
hear
something
where
I
really
consider
rebase
useful
again,
because
I
understand
it
like
for
the
for
the
Ubuntu
Stacks
I,
don't
get
it.
There
are
as
many
vulnerabilities
or
possible
vulnerabilities
in
the
Java
virtual
machine
than
there
are
in
the
base
packages.
So
rebates
is
not
really
an
option.
Do
you
anyhow
have
to
regularly
rebuild
and
actually
do
the
whole
thing
for
this?
D
D
So
the
rebase,
in
this
case
you'd,
be
rebasing
the
layer
that
has
your
Ubi
based
container,
which
could
have
known
things,
and
this
is
why
Ubi
images
are
refreshed
quite
regularly
and
they
list
all
the
cves
that
they
fixed
against
it
and
then,
if
you're,
looking
at
a
Ubi,
runtime
image,
which
are
also
put
out
regularly
and
supported,
then
you're
looking
at
those
guys
follow
the
Ubi
base
images
but
they'll
also
roll
out
the
you
know
the
zero
day
fixes
for
Java
and
stuff
like
that.
D
So
those
are
the
levels
that
you
need
to
be
on
if
your
application
wants
to
be
as
good
as
you
can
get
it,
and
this
I
mean
rebase
presents
a
really
really
attractive
way
here.
To
get
your
application
into
a
container.
That's
like
say
you
were
running
on
Ubi
Java
that
you
built
with
yesterday
and
they've
just
released
a
new
one.
Then
a
rebase
and
you're
up
and
running
again.
E
Yeah
well
my
my
point:
there
is
that
I
see
the
the
see
the
integration
Point
mainly
out
of
the
system
so
put
that
into
the
CI
CD
system
and
when
you
anyhow
have
to
run
cicd,
you
can
also
go
on
and
just
build.
The
the
whole
app
run
your
tests
by
the
way.
So
a
change
in
any
of
these
layers
also
down
there.
It
could
lead
to
problems
so
yeah.
You
want
to
have
the
additional
Assurance
of
your
tests
and
then
the
distinction
of
rebase
or
rebuild
is
very
slim.
I
mean
I.
E
E
If
you
don't
build
them
in
the
system,
anyhow,
somebody
has
to
trigger
the
bill
for
that
image.
Yeah
yeah,
it's
different
right
from
a
root
file
system
that
actually
gets
exchanged
on
on
a
Diego
cell,
so
I
get
I,
get
the
rebase
functionality
of
CF
I.
D
I
think
it
has
some
nice.
It
has
some
nice
advantages
that
I
think
the
a
lot
of
coop
customers
aren't
used
to
thinking
about
in
that
manner
and
I.
Think.
As
a
result
of
that,
you
have
got
a
much
better
ecosystem
from
the
coupe
side
where
people
have
got
used
to
the
idea
of
rebuilding
because,
as
you
say,
that
allows
you
to
rerun
all
of
your
aggression
tests
to
make
sure
that
the
new
container
actually
still
passes
whatever
quality
metrics.
D
You
need
before
you
deploy
it,
but
I
think
also
there's
a
lot
of
cloud
Foundry
customers
that
are
finding
themselves
moving
towards
Kube
and
wanting
to
hold
on
to
their
old
way
of
thinking
and
for
those
companies.
This
is
a
Lifeline
in
a
way
a
very
attractive
one
I
think
as
well
cool,
a
shame.
There's
not
more
people.
D
I
was
hoping
to
get
a
lot
of
feedback,
but
I
think
the
good
thing
is
that
when
even
if
I
get
started
on
this
as
soon
as
possible,
there's
still
plenty
of
time
for
feedback
and
discussion
and
changing
it
as
it
as
it
evolves.
Because
I
think
my
main
motivation
here
is
just
to
try
and
actually
get
things
going
so
that
we
can
get
started
on
it.
So.
A
Yeah
I
made
sure
to
add
a
bunch
of
the
maintainer
teams,
got
pinged
for
reviews
on
this,
so
hopefully
you'll
start
to
get
some
feedback.
I'll
also
bring
it
up
with
the
folks
from
the
VMware
side,
when
we,
you
know
meet
for
our
daily
stand-up
to
talk
about
build
pack
stuff,
excellent.
D
D
A
All
right,
I
think
this
is
the
last
RFC
great.
So
that's
rfc's
done
here.
Next
up,
we've
got
CNB
updates
and
questions
I
think
the
latest
CNB
stuff
I've
seen
has
been
that
there
is
like
movement
on
the
removal
of
Stack,
IDs
and
mix-ins,
which
is
great
it'll.
Allow
us
to
make
some
of
the
build
packs
quite
a
bit
more
stack
agnostic,
which
is
wonderful,
considering
the
Ubi
stuff
we're
just
talking
about.
A
We
can
start
to
just
you
know,
say
this
works
on
a
Linux
distro
and,
like
that's
a
pretty
reasonable
thing
to
say
other
than
that
I
know.
There
was
also
some
movement
on
the
The
Run
image.
Extension
stuff,
I
haven't
seen
anything
come
out
concrete
though
at
this
point
I
just
saw
the
folks
are
making
progress
on
it.
A
A
E
Sound
like
it
you're
just
adding
one
thing
to
the
stack,
ID
stuff,
I'd
really
like
to
see
potato
moving
away
from
using
the
stack
ID
still
and
it's
used
for
tiny,
like
it's
used
for
detecting.
Oh,
we
are
on
Tiny
and
make
some
some
decisions
based
on
that
there
might
be
something
coming
from
from
our
end
to
to
do
some
changes
there,
one
one
of
them
being
there.
That's
is
it
somewhere,
yeah
I
think
there
are
places
where
it's
the
choice
between
running
something
directly
or
Running
With
A
bash.
E
We
have
a
stack
that
is
not
tiny
right
from
the
ID,
so
we
are
already
running
there,
but
we
also
plan
to
remove
bash.
So
we
will
maybe
even
come
with
something
to
align
on.
Let's
try
to
use
whatever
a
shell
is
available,
but
that's
a
different
topic.
A
Okay
in
the
project
update
section
I,
don't
know
that
there's
a
lot
today
there
was
a
new
release
of
the
jam
CLI
major
version
to
2.0.
The
reason
being
is
we
removed
support
for
updating
dependencies
that
are
pulled
from
the
dev
server.
This
is
like
the
common
depth
server
infrastructure,
where
we
were
like
hosting
dependencies
because
all
the
dependencies
work
over
the
last
you
know
nine
months
or
so
has
finished,
and
we
basically
don't
have
anything
on
the
depth
server.
A
That
should
be
hosted
there
anymore,
that
stuff's
been
deprecated
for
a
while
the
command
or
support
for
it
got
removed
today,
and
we
had
a
major
version
for
that
specific
thing.
So,
if
you
were
relying
on
that
for
any
reason
which
can't
imagine
a
lot
of
people
were
it's
broken
now
or
doesn't
work,
yeah
I
think,
that's
it
not
a
lot
in
the
last
week.