►
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
B
30
to
like
10
p.m,
one
day,
but
not
all
of
it
was
the
the
workshop
like
the
last
like
you
know,
between
like
six
and
ten
p.m
was
like
dinner
and
and
but
we
were
still
chatting
over,
like
you
know,
a
lot
of
stuff,
so
that
was
one
day
and
then
the
next
day
it
was
like
10
a.m.
To
what
was
it?
It
was
still
like:
10
10
a.m,
to
like
6
p.m,
or
so
that's.
B
D
C
B
F
B
So
I
know
there's
been
you
know
between
like
I
guess,
beginning
of
December
till
now,
there's
been
a
lot
of
different.
You
know,
planning
meetings
and
yeah
yeah
that
folks
have
been
sort
of
pulled
into
so
I
know.
We
haven't
had
too
much
regular
attendance
to
this
meeting
but
hoping
moving
forward.
We
can.
We
can
do
that,
so
the
agenda
item
I
have
for
this
week,
but
also
open
to
other
agenda
items.
B
Like
the
Sterling
tool
chain,
integration
coming
from
the
governing
board-
and
actually
some
of
the
folks
over
at
City
might
have
some
more
Insight
onto
some
of
that,
because
I
know
that
John
is,
is
heavily
invested
in
the
Sterling
tool
chain.
Stuff!
That's
coming
out
of
openssf
cool!
So
before
getting
into
like
details
on
the
roadmap,
does
anybody
have
any
sort
of
General
questions
comments?
Anything
like
that.
G
G
G
A
G
B
Hey,
that's
something
that
we're
looking
to
actually
catch
the
stuff
like
walk
is
to
say:
hey
somebody
updated
a
release
without
actually
updating
the
version
number
or
the
hash.
You
know
or-
or
you
know,
yeah
pretty
much
that
sort
of
thing,
because
it
is
quite
annoying
cool,
yeah
yeah
that
that
sounds
good
and
actually
one
of
the
I
know.
B
One
of
the
ticket
items
we
have
is
well
not
quite
that,
but
related,
which
is
one
of
the
things
I
think
we
would
like
to
see
for
2023
is
a
is
a
better
way
of
updating
the
hashes
of
images
as
things
get
updated
for,
like
pipelines
and
for
tasks
and
so
on.
I
know
that
doesn't
really
affect
this
thing,
because
this
was
sort
of
a
version
like
the
the
hash
change
without
the
version
actually
changing.
B
B
B
So
just
keep
that
in
mind
so
that
the
idea
here
would
be
I
you
might
think
through
is
like
Fresca
might
be
a
thing
that,
let's
say,
consumes
as
to
c2f
like
artifacts
that
are
compliant
with
it
like
dependencies
and
whatnot,
does
a
bunch
of
building
and
then
produces
salsa
compliant
artifacts
on
the
outside.
So
that's
that's
something!
B
That's
kind
of,
and
that's
also
a
big
push
as
part
of
the
salsa
1.0
release,
as
well
as
part
of
some
of
the
guidance
coming
from
the
governing
board
and
the
tech
which
is
just
like
hey.
We
want
to
start
showing
off
actual
implementation
stuff
on
some
of
these
things
and
actually
those
implementation
things
being
part
of
the
open
ssf
itself.
So
this
is
stuff,
like
Fresca
being
potentially
a
secure,
build
tool
that
people
can
use.
B
So
that's
actually
also
another
thing
for
potentially
maybe
having
actually
a
release
this
year
might
be
nice
to,
even
if
it's
like
a
Beta
release
and
not
a
full
like
1.0
sort
of
hard
and
release
I
think
we're
looking
to
kind
of
have
something
like
a
pretty
soon,
at
least
maybe
have
something
like
a
v0.1,
because
another
thing
that
came
up
in
a
couple
of
other
General
open
ssf
meetings
is
people
are
sort
of
looking
at
Fresca
and
going
well.
Is
there
a
release
of
this
thing?
B
B
People
just
don't
know
how
to
look
at
it
yet
so
that
that's
another
thing
that
I
think
we
want
to
kind
of
get
done
this
year
is
start
creating
something
like
a
release
process
tied
to
that
I
think
is
the
dependabot
ability
to
update
versions
of
things
and
that's
both
on
the
components
we're
actually
pushing
out.
I
know
that
Tim
has
done
some
work
on
the
vendor
me
stuff,
which
then
I
know
is
now
part
of
the
the
build
Tech
work
itself.
E
Yeah
I
think
the
the
issue
with
Frisk
has
always
been.
What
exactly
is
a
release
of
Fresca
exactly
because
the
the
way
that
we
put
it
the
way
that
it's
set
up
on
GitHub
right
now
is
really
more
for
users
of
Fresca
to
get
it
running
or
sorry
developers
of
Fresca
to
get
it
running
as
opposed
to
what
somebody
would
actually
consume.
E
So
I
think.
If,
if
we,
you
know,
maybe
sought
a
demo
of
some
of
the
stuff
that
Sonny's
been
working
on
in
terms
of
you
know
splitting
out
splitting
it
splitting
up
Fresca
into
effectively
the
two
distinct
kinds
of
clusters
and
what
would
be
a
more
representative
environment
than
releasing
the
actual
pipeline
piece
of
Fresca
I.
Think
is
something
that
we
could
definitely
do
by
Summer.
B
B
We
would
be
interested
in
seeing
a
demo
from
from
sunny
on
some
of
the
stuff
he's
been
working
on,
because
I
think
you
know
kind
of
going
back
to
sort
of
the
principles
in
the
in
the
readme
right
like
Fresca
is
you
know
a
set
of
components
that
are
open
source
components
that
are
configured
to
operate
securely
right
with
you
know,
recognizing
that
secured
you
know.
Security
means
lots
of
different
things,
but
just
generally
like
in
the
general
sort
of
sense
of
like
yeah.
B
You
know
maybe
not
being
able
to
compromise
everything,
and-
and
also
we
do
have
some
folks
who
are
working
on
a
threat
model
on
Fresca
soon,
but
I
think
that
sort
of
thing
is
is
something
that
were
interested
in,
maybe
locking
down
a
bit
more
to
say,
yep
and
that's
the
principles.
And
then
this
is
how
we're
actually
hitting
you
know
the
sort
of
goals
defined
there
and
then
separately
the
you
know,
Fresca
being
like
a
space,
an
easy
set
of
abstractions
that
as
an
end
user
right.
B
Is
the
key
Verno
policy
that
I'm
associating
with
this
build
and
here's
the
you
know
here
is
some
information
regarding,
like
you
know
the
what's,
it
called
secrets
and
and
config
maps,
and
and
all
that
good
stuff
like
it,
should
just
be
something
that
is
kind
of
like
all
one
holistic
package,
while
remaining
relatively
flexible.
So,
if
folks
need
to
add
and
change
stuff,
they
should
be
able
to.
F
B
One
is
we
want
to
make
that
that
command
line
wrapper
as
simple
as
possible
right,
because
we
don't
want
to
end
up
creating
something
that
becomes
so
tied
into
how
how
a
lot
of
that
sort
of
stuff
works.
So
that's
kind
of
where
the
cue
stuff
comes
in
and
I'll
show
off
the
queue
stuff,
and
then
we
can
talk
a
little
bit
about
how
that
might
interact.
B
And
just
as
an
FYI,
the
folks
also
from
Q
are
interested
in,
maybe
in
the
next
couple
weeks,
maybe
showing
up
to
the
next
meeting
or
something
like
that,
because
they're
very
interested
in
in
seeing
what
they
could
also
do
to
see
how
like
what
are
we
struggling
with
and
so
on.
But
let
me
just
show
you
like
what
this
might
look
like,
potentially
as
an
end
user.
Once
again,
this
is
purely
a
POC.
This
is
not
intended
to
be.
B
B
B
And
the
thing
that's
you
know
you
can
do
is
at
every
level.
You
can
sort
of
say.
Let's
say
at
the
org
level,
the
org
has
a
set
of
constraints
and
then
a
department
in
an
org
can
have
a
set
of
constraints
and
once
again
this
is
all
very
flexible
to
whatever
the
end
user
needs,
but
we'll
obviously
have
some
defaults
here.
But
the
basic
idea
is
like:
if
a
department
has
additional
constraints,
those
constraints
have
to
be
additional,
like
a
department
can't
say
as
an
example
and
I'll
show
this
in
a
second
like.
B
If,
let's
say
the
org
says,
we
only
support
python
go
and
rust.
If
somebody
comes
in
with
C
plus
plus
a
department
says:
hey,
we
support,
C
plus
plus
sorry
the
org
doesn't
support
C
plus
plus.
We
don't
allow
that
right
and
and
that's
kind
of
a
simple
example,
but
you
could
imagine
like
policy,
and
you
could
imagine
naming
schemes
and
all
that
sort
of
stuff
being
generated
here
so
you'll
see
here
at
the
team
level,
There's
a
constraint
on
build
type
to
go
and
build
packs.
B
So
that
means,
if
I
switch
this
to
go
and
run
the
same
thing.
You
know
it
now
gets
the
go
pipeline
associated
with
the
project.
But
if
I
go
in
and
I
were
to
say,
like
I,
don't
know,
I
want
to
use
the
python
Builder,
and
this
is
also
where
the
command
line
would
come
in
to
help
with
some
of
the
error
handling,
but
pretty
much.
This
is
just
saying:
hey.
B
There
is
a
conflict
here,
because
you
set
up
a
constraint
that
says
either
build
packs
or
go,
and
you
gave
me
python
right
and
the
command
line
here
would
create
better
end
user
sort
of
error
messages.
But
this
this
is
kind
of
the
thing
that
you
know
is
is
allowed
and
what
is
it
isn't
allowed
right,
and
so
the
other
thing
here
right
is
so.
If
I
push
this
back
to
build
packs-
and
let's
say
you
know-
I
removed
build
tax.
That
would
no
longer
work
as
well.
B
The
other
things
here
are,
you
know
you
can
potentially
inject
additional
sort
of
constraints
or
whatever
additional
resources
into
the
kubernetes
that
we're
using
for
Q,
also
via
the
same
sort
of
mechanism.
So
here
we've
just
decide
defined.
A
almost
like
Q
doesn't
have
functions,
but
something
similar
to
a
function
in
Q
that
allows
us
to
say:
hey,
I
want
to
create
a
policy,
a
key
verto
policy
in
this
case
it's
a
giverno
image
policy
and
it's
called
baz
and
I'm.
B
So
here
there's
a
bunch
of
policies
that
are
associated
with
at
the
org
level,
but
because
we
don't
restrict
it
at
the
lower
levels.
We
can
say
Okay
a
department
is
allowed
to
create
additional
policies,
but
they
can't
delete
the
orgs
policies
right.
They
could
say
hey,
we
are,
you
know
we
have
additional
stuff
and
so
on
and
then
over
here
here's
the
like
complete
list
of
allowed
builds.
B
B
There
is
nothing
at
the
org
level
to
actually
support
that.
So
that's
another
sort
of
thing
there.
In
addition
to
that,
we
can
set
up
stuff
like
naming
schemes
as
part
of
this,
so
that
you
know
an
individual
organization
can
come
in
and
say
great.
All
of
my
images
that
are
built
should
look
in
the
form
of
org--department-team
Dash
project
and,
if
I
look
at
this
here,
you
can
see
it
creates
images
in
that
sort
of
form
here
of
like
ttl.sh,
which
is
the
default
as
part
which
I'll
show
you.
B
What
that
looks
like
in
the
library
in
a
second,
but
it's
org
x,
dash
Department,
Y,
dash
team,
Z,
Dash
Foo
right
and
where
Foo
only
had
to
say,
what's
my
project
name
Foo
and
you
know
some
of
us
who've
worked
in
banks
have
known
like.
Sometimes
there
is
a
naming
scheme
out
there,
you're
not
told
what
that
naming
scheme
is,
and
you
just
kind
of
have
somebody
go
and
say
like
no.
B
I'm
doing
in
here
are
probably
not
two
best
practices
I'm
still
trying
to
figure
some
of
that
out
myself,
but
to
now
go
to
into
sort
of
this
is
what
like
live.
Configuration
might
look
like
right,
so
this
is
what
you
know.
An
actual
organization's
configuration
might
look
like
okay,
what
about
the
actual
like
helper
functions
and
the
library
piece
of
it?
B
Well,
that's
where
you
know,
and
I'm
trying
to
kind
of
emulate
go
style
packaging
for
now,
but
obviously
this
could
change
or
whatever,
but
we
have
stuff
like
here
is
the
build
tax
pipeline
right
and
a
lot
of
this
stuff.
For
folks
who
are
not
super
familiar
with
q
and
I'm
not
going
to
get
too
deep
into
it,
is
you
can
import
stuff
into
queue
directly?
B
So
if
you
have
some
yaml,
you
could
just
do
Q
import
that
yaml
and
it
will
convert
it
into
queue
and
then
using
some
of
the
other
Q
functions.
You
can
actually
turn
some
of
these
things
into
automatically
into
schemas,
so
it
can,
let's
say
for
example,
say
well.
This
is
a
string.
I
know
this
is
a
string,
so
you
know
I
can
just
sort
of
create
a
schema
out
of
that.
B
You
know.
There's
some
things
in
here,
just
to
kind
of
give
you
an
idea
of,
like
this
defaults
to
the
example
build
packs,
but
anybody
can
put
in
any
string
right.
So
if
somebody
does
not
put
in
the
name
of
an
image,
it's
a
falsely
example
build
packs
stuff
like
that,
and
then
the
other
thing
here.
That's
kind
of
neat
about
how
you
could
do
this
in
queue.
Is
you
can
test
a
lot
of
stuff
in
queue
by
just
sort
of
creating
of
you
know
a
folder
called
test.
B
B
Here
we
go
found
in
in
want,
you
know
so,
and
some
in
once
again
the
the
I
one
thing
I
will
say
is
the
error.
Messages
in
queue
are
not
great
here,
but
anyway,
if
I
go
over
to
the
go
one
here,
this
is
what
the
go
one
looks
like
and
then
the
other
thing
that
we're
trying
to
kind
of
start
to
Define
is
we're
trying
to
Define
like
standards.
B
B
Sorry,
a
a
sort
of
not
a
subset,
but
a
further
constraint
of
that
task.
Right.
It
has
to
like
match
the
Fresca
clone
task
schema,
and
so
you
might
imagine
right,
like
as
we're
building
something
out
a
secure
pipeline
task
or
sorry
secure
pipeline
might
include
tasks
that
hit
certain
requirements
like
you
must
include
an
s-bomb
generation
task.
B
You
must
include,
you
know
a
secure,
publishing
task
and
whatever
right,
but
because
of
this,
this
sort
of
makes
it
very
easy
for
folks
who
are,
let's
say,
building
their
own
pipelines
to
sort
of
generate
whatever
they
want.
So,
if
I
look
here
right,
a
a
pipeline
input
is
relatively
simple
and
once
again
for
most
folks,
they
don't
have
to
look
at
this.
B
This
is
mostly
for
folks
who
are
developing
on
Fresca
itself
or
for
people
who
want
to
generate
some
custom
pipeline
type
for
their
specific
need,
but
the
inputs
here
are
just
like
they
look.
You
know
like
you
would
call
a
function
or
something
and
just
sort
of
say
hey.
This
is
a
test
pipeline
test
image,
yeah.
B
There's
a
bunch
of
stuff
that
it
it
it
deploys
and,
and
so
on
so
actually
before
kind
of
continuing
do
folks
wanted
to
kind
of
like
is
there
anything
does
this
seem
like
what
we
should
be
doing?
Do
folks
have
kind
of
a
different
opinion
curious
to
hear
like
feedback?
If
this
seems
like
something
we
should
be
focused
on.
G
B
Yeah
I
I
think
on
that
front
we're
trying
to
kind
of
figure
out
as
much
as
possible.
We
want
to
just
sort
of
pull
stuff
directly
from
tecton,
but
we
also
like
some
of
the
stuff
that
I
think
we've
been
noticing
is.
We
might
not
want
to
just
pull
whatever
from
tecton
if,
if
some
of
the
folks
will
just
sort
of
update
a
thing
and
not
do
the
release
and
and
some
of
the
other
stuff
there
I
think
like
I
think
we
might
want
to
do
something
like
that,
but
there's
two
pieces.
B
We
noticed
this
issue
with
the
thing
and
we
want
to
include
it
or
not
include
or
whatever,
but
the
other
thing
I
think
that
might
be
useful
from
the
Fresca
side
is
I.
Think
our
catalog,
if
we
had
one,
would
be
significantly
smaller
right.
We
just
sort
of
say
yep
because
of
how
things
are
looking
right
like
we
are
going
to
support,
you
know:
go
we're
going
to
support
python.
If
somebody
wants
to
add
let's
say:
Java
support.
B
Okay,
great,
you
can
add
Java
support,
but
I
think
the
other
thing
too,
is
we're
not
looking
to
kind
of
support
like
every
different
thing
under
the
sun.
We're
looking
to
say
here
is
like
a
secure
clone
task
right
and
so
we're
not
going
to
support
every
cloning
task,
where
this
is
just
going
to
support
this
secure
one
and
if
folks
want
to
come
in
and
build
their
own,
we
can
definitely
do
that
and
I
think
some
of
the
other
stuff
that
kind
of
makes
this
nice
is.
B
B
Q
can
automatically
support
sorry,
kubernetes
resources
and
custom
resources,
so
you
can
just
actually
include
custom
resources
like
you
would,
let's
say
a
go
package
and
it
automatically
is
able
to.
Then
you
can
then
feed
in
and
it
can
match
against
that
schema.
So
you
know
you
can
go
and
say
hey.
This
is
what
you
know
just
as
an
example.
B
This
is
what
a
Fresca
task
looks
like,
and
a
Fresca
task
could
potentially
consist
of
these
particular
things,
and
so
you
must,
in
order
to
be
a
a
task.
You
must
have
these
things,
and
so
some
of
the
things
that
we
might
be
able
to
do,
for
example,
is
say:
all
tasks
must
have
images
with
pin
hashes.
We
do
not
allow
folks
to
just
sort
of
pin
to
a
tag
you
must
pin
to
a
hash
and
we
can
actually
enforce
that
at
this
level.
B
B
E
G
G
You
know
a
process
say
at
you
know
at
the
time
that
we
produce
the
frisker
release
whatever
that
is
to
for
us
to
automatically
do
that
right,
based
on
which
version
of
that
get
clone
test
that
we're
using
and
then
also
to
I.
Think
Mike
talked
about
it
a
little
bit,
but
at
least
having
a
mechanism
for
other
people
to
add
their
their
own
particular
flavor,
of
whatever
task
that
is
right
to
get
clone
task
or
whatever,
and
making
that
easy.
G
I
will
say
that
some
of
the
newer
versions,
the
new
version
of
Q,
is
going
to
make
it
a
little
bit
easier
to
determine
what
gets
evaluated
during
when
you're
doing
the
queue
evaluation
and
not
be
so
strictly
hierarchical
and
further
going
to
doing
it.
Doing
the
evaluation
within
go
sort
of
opens
some
more
doors
on
what?
What
sort
of
labors
of
the
constraints
that
you
want
to
pull
in
and
you
want?
You
won't
be
sort
of
stuck
to
this.
G
You
know
you
have
to
have
you
know
certain
constraints
at
the
the
top
level
directory
some
at
the
mid-level
directory,
and
then
you
know
some
of
the
lower
level
directory.
You
can
sort
of
pull
in
sort
of
mix-ins
as
it
will
from
you
know,
you
could
have
like
command
line
options
say
I
want
to
include
you
know
some.
You
know
host
builds
test
like
this
or
some
constraint
like
that,
and
it
would.
G
B
G
D
B
Yeah,
the
other
thing
I
did
like,
and-
and
maybe
even
the
mix-ins
would
probably
help
here
with
some
of
the
testing
to
be
able
to
sort
of
mock
stuff
out
and
and
and
so
on,
is
is
I.
Do
like
sort
of
like
the
the
the
idea
of,
if,
if
you
can
sort
of
verify
like
because,
like
one
of
the
other
things
that
that
is
very
confusing
about
Q
is
like
sometimes
it
can
be
very
difficult
to
know
like.
B
B
It's
just
as
something
something
as
simple
as
hey:
I
have
a
list
of
build
tasks
and
I
just
include
this
one,
and
because
this
one,
you
know
because
this
Fresca
build
test
task,
is
an
official
task
right
like
it
meets
that
those
constraints
defined
by
the
Fresca
task.
Yep
that's
valid
right,
and
so,
if
somebody
were
to
come
in
with
like
a
task
that
you
know
doesn't
meet
those
requirements,
it
wouldn't
work
which
is
which
is
great,
yeah
I.
Think
the
the
concerns
from
our
end
is
is
always
like.
B
B
You
know
I
think
because
from
from
our
end
from
folks
who
seem
to
be,
you
know
reaching
out
in
the
the
slack
chat
or
or
even
just
you
know,
asking
to
have
some
some
chats
about
some
stuff
who
are
looking
at
this.
You
know
they
did
say:
hey
like
nobody
wants
to
move
off
of
their
CI
system
right,
because
everybody
has
too
much
complexity
there,
but
a
lot
of
folks
are
looking
at
something
like
a
Fresca
as
either
for
Greenfield
environments
of
like
great
I.
B
Don't
need
to
use
the
old
stuff,
and
this
thing
just
generates
us
bombs
for
me
and
and
handles
a
lot
of
the
the
heavy
security
stuff.
That's
that's
pretty
big
and
then
the
other
thing
I
think
folks
are
have
been
interested
in
is
also
sort
of
just
sort
of
that
General
easy
button
and
the
ability
here
right
where
I
don't
think
we
want
to
push
for
this
right,
but
some
folks
have
said:
hey
could
I
make
this
just
take
over
the
build
scan
Etc
tests,
but
Mike
Jenkins
still
handles
the
QA
pipeline
right.
B
I
think
folks
have
sort
of
seemed
interested
in
doing
that,
and
it's
not
necessarily
that
I
recommend
it.
But
if
that's
the
way
folks
are
going
to
go,
that
might
still
be
relatively
reasonable,
because
I
think
the
thing
that
folks
are
recognizing
is
if
they
have
to
generate
s-bombs
on
their
own
and
enforce
that
and
do
all
the
various
security
scans
and
make
sure
that
the
s-bombs
get
published
all
the
right
places
and
the
things
have
the
salsa
attestations
and
so
on.
I
think
they've.
E
The
other
question
I
have
on
on
this
whole
thing
is:
who
exactly
is
the
user
for
something
like
the
command
line
like
who's
doing
it,
because
I
think
the
the
one
thing
I
want
to
make
sure
that
we're
that
we're
that
we're
clearing
is
I,
don't
imagine
or
again
well.
This
is
this
is
a
question.
It's
a
poorly
phrased
question,
but
you
know
I,
don't
imagine.
G
G
It
more
as
a
sort
of
onboarding
the
the
project
or
whatever,
to
the
build
infrastructure
right.
So
more
of
a
more
of
a
one-time
thing
to
say:
okay,
this
is
my
project.
I
want
you
to
set
up
a
pipeline
to
monitor
it
and
build
it
when
it
changes
through
it
and
not
necessarily
having
the
developer
initiating
the
the
pipelines
themselves
after
they
make
changes
to
their
project
right.
Does
that
make
sense?
G
E
E
To
a
certain
extent,
yeah
I
guess
my
my
question.
That
was
even
even
in
a
place
like
not
to
list
any
specific
tools
that
anybody's
using
but,
like
you
know,
even
in
somewhere,
it's
more
like
city,
you
there's
I,
think
oftentimes
you're
likely
to
still
have
even
another
more
abstracted
interface
or
way
to
submit
requests
that
folks
typically
use.
E
So
it
seemed
likely
to
me
that
this
would
still
kind
of
even
still
be
abstracted
away
from
the
onboarding
stuff,
because
that
would
you'd
be
four
and
cities
not
alone
in
this.
A
lot
of
folks
have
a
thing
that
they
have
to
use
to
onboard
do
stuff.
You
know
like
when
I
want
to
submit
a
request
for
something
I
go
to
this
site
and
I
fill
in
some
things,
and
then
that
submits
a
ticket
and
on
the
back
end
it
might
even
just
call
this,
but
I
I
can't
find
that
many
folks.
E
E
B
Yeah
yeah,
I
I
think,
like
whatever
the
command
line
tool
ends
up
being
it's
more
of
the
API
into
Fresca,
even
if
it's
the
deployment
API.
In
addition
to
other
things
as
well,
I
think
one
of
the
things
that
that
I
know
folks
have
expressed
concern
about
right
is
devs,
do
not
want
a
difference
between
what
they're
running
locally
and
what
they're
running
in
CI
as
much
as
is
possible
Right,
because
they
they
don't
want
to
kind
of
find
out
like
wait.
B
B
That's
just
not
you
know
once
again
I'm
not
saying
that.
There's
a
easy
way
to
do
this,
but
I
know
some
folks
have
have
discussed
like.
Could
you
run
the
same,
builds
that
are
running
in
Fresca
as
a
full-fledged
thing?
Could
you
run
that
locally
and
I
mean
the
answer?
To
some
extent,
is
yes,
if
you
have
mini
Cube
and
yeah,
but
could
we
make
that
also
easy,
so
that
folks
know
that,
like
you
know
before
they
get
to
the
full-fledged
Fresca
that
actually
the
way
they've
structured?
B
This
thing
the
s-bomb
stuff
is
going
to
fail
because
not
because,
like
the
s-bomb
step
is
broken,
but
because
the
way
they've
developed
their
code,
it
just
makes
the
the
s-bomb
stuff
break
or
whatever
I
think
that
that's
something
that
we
we
need
to
kind
of
figure
out
to
make
it
as
easy
as
possible,
because
yeah
I
think
to
Tim's
Point.
Nobody
actually
wants
to
use
any
tool
right,
like
no
tool,
is
better
than
a
tool,
because
now
it's
another
thing
I
need
to
think
about.
B
But
if
so,
if
you
can
sort
of
say
hey
as
a
developer,
I
don't
need
to
touch
this,
except
in
this
case.
I
think
they'd
be
much
happier,
and
that
includes
developers
who
are
working
on
building
out
Fresca
itself
right,
like
I,
think
we
can
imagine,
there's
probably
from
an
API
standpoint
folks
who
are
building
out
a
Fresca
deployment
and
building
out
their
own
stuff.
B
They're
going
to
want
to
be
able
to
say,
hey,
you
know,
Fresca
new
Pipeline
and
it
generates
a
new
pipeline
in
the
catalog
or
Fresca
new
task
and
and
generates
a
task
that
automatically
hits
all
the
basics
and
then
using
a
couple
of
you
know.
Usually
a
couple
of
basic
commands
can,
let's
say
generate
one
that
you
know
includes
this
command
or
that
command
without
actually
having
to
go
into
the
queue
itself.
I
I
I
was
wondering,
as
you
kind
of
as
folks
kind
of
asked,
these
questions
right
and
the
target
audience,
and
all
that
I
mean
this
is
a
very
implementation,
specific
kind
of
question
and
I
guess
highly
dependent
on
now
that
CI
engine
is
tagged
on.
Is
that?
Can
we
build
some
of
those
things
to
a
native
kind
of
CLD,
so,
like
I,
mean
there's
nothing
too
new
to
learn,
but
then
I.
B
Yeah
so
I
know
a
while
back.
We
looked
at
both
operators
and
controllers,
as
potentially
some
way
to
do
this
and
I
know.
One
of
the
problems
became
like
when
you
have
a
bunch
of
custom
resource
definitions
with
them
themselves,
their
own
operators
and
controllers,
and
then
you
have
another
one
that
tries
to
like.
B
E
Somehow
you
know
so
so
you
can,
you
know
people
might
want
to
use
KMS
or
or
or
maybe
they
already
have
their
vault,
and
it's
not
not
likely
something
that
they're
going
to
want
out
of
the
box
anyway.
That
is
where
a
lot
of
the
complications
were,
because
even
you
know,
Brendan's
probably
familiar
with
this
too
right,
like
installing
cert
manager
in
abstracting
away,
like
the
install
of
a
lot
of
those
other
components
through
your
own.
E
G
So
another
thing
is
that
I
think
I
think
there
was
some
initial
hope
that
dagger
was
going
to
be
sort
of
that.
That
thing
that
you're
talking
about
Sonny,
where
they're
going
to
have
some
sort
of
abstract
sort
of
build
pipeline
definition
and
then
from
from
that
be
able
to
generate
that
for
different
sorts
of
environments.
G
Whether
that's
you
know
GitHub
or
you
know,
tecton
or
whatever,
but
it
I
I
think
there's
still
a
lot
of
value
to
be
gained
from
or
gems
that
they
have
in
in
how
they've
done
things,
but
they
basically
set
up
their
own
sort
of
build
infrastructure
that
they
that
they
use
right
to
do
their
builds,
and
they
can.
They
can
sort
of
wedge
that
inside
of
inside
of
tech,
it
can
run
inside
of
tecton.
It
can
run
inside
of
GitHub
actions.
They
can
run
inside
of
of
other
things,
but
it's
it.
G
B
B
It's
quite
difficult
to
kind
of
get
some
of
the
stuff
done,
and
so
they've
switched
to
sort
of
more
like
here's,
how
to
build
pipelines
using
let's
say
a
python
API
or
go
API,
and
that
kind
of
thing
I
know
that
what
they've
set
up,
which
is
which
is
interesting,
is
they're
using
graphql
behind
the
scenes
as
their
actual
model,
so
that
you
can
say
like
hey.
This
is
a
this
sort
of
command
or
whatever
and
then
based
on
different
contexts.
B
It
could
say
well,
I,
know
locally
I,
just
run
this
command
or
locally
I
run
this
command
in
a
container
remotely
I
run
this
command
in
a
VM
or
whatever,
or
you
know,
I
I
think
there's
some
interesting
stuff
that
they've
done
there
I
think.
The
the
challenges,
though,
is
how
do
you
like
guarantee
that's
done
safely
and
securely
is,
is
a
whole
other
thing.
I
think
from
a
Simplicity
standpoint
that
I
think
they've
gotten
that
thing
and
I
think
that
would
be
something
interesting
to
maybe
see.
B
B
The
problem
is
just
yeah,
but
can
you
define
a
set
of
constraints,
and
can
you
sort
of
say
that
no
a
developer
can't
come
in
and
just
say,
run
RMR
slash
on.
You
know
the
CI
box,
like
that's
what
I
I
couldn't
seem
to
find
there,
whereas
I
I
think
with
what
we're
trying
to
do
with
Fresca
is
like
the
idea
should
be
yes,
this
should
be
a
secure,
build
that
that
matches
all
that.
H
D
H
H
H
B
You
know
because
I
I
know
from
the
salsa
side,
and
some
other
sides,
like
a
lot
of
folks,
are
very
interested
in
what
Fresca
is
attempting
to
do,
but
I
think
when
it
comes
to
you
know,
who
are
the
actual
folks
who
are
potentially
adopters
of
Fresca
I,
think
we'd
be
interested
in
seeing
some
more
of
that.
So
if,
if
folks
know
folks
who
are
interested
or
whatever,
we
definitely
also
want
to
hear
some
more
feedback
from
them.
I
I
I
mean
yeah,
their
definition
of
what
I
want
may
be
different
than
this
and
the
definition
of
security
in
a
way
what
they
want
to
control
may
be
different
as
well
like,
although
fundamentally
yeah,
you're
cloning,
a
thing
that
can
be
common
enough
for
everybody
but
like
beyond
that,
yeah
I
can
see
some.
You
know,
preferences
difference.
H
But
I
just
want
to
give
an
update
for
the
tecton
stuff.
It
is
moving
forward,
so
this
guy
named
prakash
he's
pushing
the
PRS
forward
for
us
on
the
techton
side
on
the
Techno
pipelines
and
chains
for
the
Spire
work,
so
that
is
moving
along.
This
is
taking
a
long
time
still
yeah.
There's
a
lot
a
lot
of
comments
and
everything
so
yeah.
B
I
wonder
if
that's
something
we
can
bring
up
to
some
of
the
CD
Foundation,
because
at
this
point
it's
it's
actually
over
like
it's
over
a
year
since
this
work
started,
and
there
was
a
lot
of
pushback
from
the
tecton
side
on
on
on
some
of
this
so
yeah.
Let
me
reach
out
to
some
of
the
folks
on
on
that
on
the
techton
site,
as
well,
just
kind
of
say,
hey
look,
I
know
David
was
like
yeah.
This
is
definitely
a
priority
and
I
know
that
it's
moving
along,
but
it's
like.
B
H
That
is
also
going
to
be
released
as
an
alpha
right,
so
it's
not
like
it's
enabled
by
default.
You
have
to
fit
like
actually
enable
it
and
set
it
up
and
so
forth.
So
it's
not
like
it's
going
to
break
functionality
out
of
the
box
or
something
so
yeah.
It's
not
it's
not
going
to
be
a
full-fledged
release
of
it.
Anyways
until
it's
been
tested
and
all
that
kind
of
stuff
trying
to
lose
that
Alpha.
So.
H
But
yeah
so
that's
moving
along
and
then
the
runtime
attestations
I
think
Brad
attended
it
last
time,
yeah
we're
going
to
do
the
the
we're
gonna
push
the
attestation
forward.
So
there's
a
meeting
after
this
for
the
Toto
and
we're
going
to
push
the
runtime
out
of
stations
in
into
as
a
0.1,
so
I'm
gonna
get
that
push
forward,
and
then
we
can
always
make
revisions
on
it
as
we
as
we
see,
fits
at
the
same
time.