►
From YouTube: Foundational Infrastructure Working Group [Oct 28, 2021]
Description
Call recording from the open source Cloud Foundry Foundational Infrastructure Working Group held on 28th Oct 2021.
Minutes:
Autobump bot PR don’t require reviews (just green ci)?
Changes to CI owned by a specific vendor does not require reviews
[RK] produce guidelines around which repo’s can auto merge after review and for which ones we need manual controls to spread the workload load of the VMware CI Pair.
A
I
co-prepared
this
from
somewhere,
so
we
we
do
new
faces.
Maybe,
as
everybody
tells
maybe
a
bit
about
themselves,
I
mean
we're
not
going
to
do
that.
Every
call,
but
I
mean
for
now
it's
useful.
So
I
will
start.
I
am
reuben
koster
I've
been
working
with
bosch,
for
I
don't
know
a
long
time,
seven
years
or
something
at
least
for
a
long
time
at
starcom
wayne
and
recently
for
vmware,
where
I'm
not
part
of
the
party
ecosystem
team
and
on
the
foundation
and
infrastructure
working
group.
I'm
the
tech
leads
so.
C
Yeah
hi,
I'm
behind
I'm
from
sap,
I'm
working
with
porsche.
I
think
since
2015
I
did
torture
at
that
time
in
san
francisco
and
I've
been
part
of
the
bosch
team
europe
so-called
and
since
then
I
am
working
with
bosch
and
at
the
moment
I
am
working
on
some
different
things
in
cloud
foundry
from
customer
perspective
and
I'm
the
technicality
from
sap
site
for
push.
D
Should
I
go
next,
so
I'm
diego
I'm
based
out
of
london
and
I
work
for
vmware,
I
joined
vmware
through
the
pivotal
acquisition.
I
joined
pivotal
back
in
2016
and
I
think
since
then
I
work
with
bosch.
I
worked
at
various
teams
at
pivotal.
I
worked
with
the
bosch
team
at
some
point
and,
and
I
think
that's
it
really
fernando.
Would
you
like
to
go
next.
F
G
Hi
folks,
my
name
is
ram
ayangar,
I'm
based
out
of
chennai
in
india.
I
work
with
the
cloud
foundry
foundation
as
a
developer,
advocate
and
yeah
I'm
here
to
help
folks
with
any
support
that
they
might
need
in
terms
of
organizing
the
working
groups
or
anything
else,
and
also
here
to
learn
as
much
as
I
can
from
everybody.
H
Chris
well
yeah,
I'm
chris
clark
operations
manager
for
the
cloud
foundry
foundation,
so
yeah
recently
relocated
from
the
bay
area
to
atlanta
georgia,
which
makes
these
calls
a
lot
easier
and
yeah.
You
know
for
anyone
that
needs
any
any
technical
support
over.
You
know
operational
things
like
need,
new
repositories
or
stuff.
You
can
reach
out
to
me,
obviously
very
soon,
hopefully,
once
once
all
the
working
groups
are
set
up
and-
and
things
are
really
in
motion-
there'll
be
other
mechanisms
for
that.
A
Okay,
with
everybody
next
item
on
the
agenda,
I
thought
might
make
sense
to
like
review
a
bit.
What
we've
been
doing.
We
did
like
a
soft
start
of
like
trying
to
so
one
of
the
main
objectives
we
have,
as
a
group,
I
think,
is
like
making
sure
that
the
requests
get
merged
and
for
that
we
need.
We
have
approvers
that
need
to
approve
for
requests.
A
A
Let
me
show
what
we
are
currently
doing,
so
we
have
a
project
board.
Also,
I
think
in
the
meeting
invites
I
don't
know
if
it's
there
at
least
so
yeah
incoming
things,
and
so
what
I'm
currently
doing
is
assigning
the
incoming
items
just
a
bit
at
random,
like
just
do
like
a
quick
estimate
of
like
who
would
be
a
great
a
good
fit
for
this
based
on
context,
but
that's
like
I
can
be
off
there.
A
A
F
A
F
I
think,
because
it's
still
in
the
beginning,
I
think
we
can.
We
can
do
a
bit
of
both.
So
if
you
see
that
it's
already
there
for
a
week,
you
can
just
assign
people,
I
don't
know
just
once
a
week
you
can
just
say:
okay
still
hasn't
been
assigned
to
someone.
Still
someone
hasn't
picked
it
up.
Now
I
basically
force
you
to
review
the
damn
thing.
A
Yeah
someone
needs
to
pick
it
up
and
you're
the
one.
So
the
thing
is
like
with
a
week.
I
think
that's
too
long
as
in
currently
not
all
things
go
to
through
pull
requests.
I
mean
we
still
have
the
the
vmware
folks
who
just
commit
to
master
sometimes,
but
if
so,
I
ideally
we
iterate
on
this
process
and
get
things
merged
more
quickly
right,
because,
ideally,
everything
should
go
through
pull
requests,
but
we
before
we
can
start
doing
that
we
need
to
have
like
a
proper
throughput.
A
F
E
I
don't
know
if
it's
the
right
time,
but
I
noticed
that
we
didn't
diego
normie
presented.
Why
or
what
kind
of
work
we
are
doing
in
those
repositories
and
why
we
are
here
in
this
working
group.
So
maybe
that's
something
to
share
context
with
you,
because
we
don't
know
what
will
be
the
best
way
to
collaborate
and
to
work
in
those
repositories.
So
maybe
it's
not
ideal
that
we
have
merged
permissions
or
it
is
ideal,
but
with
some
conditions.
So
I
don't
know.
D
Cool,
I
can
do
that,
so
the
cryogenics
team,
at
vmware,
tries
to
take
some
components,
can
be
like
vmware
components
or
components
that
components
from
cloud
foundry.
The
platform
that
the
vmware
ships
within
it's
like
proprietary,
not
proprietary,
but
enterprise,
offering
of
cloud
foundry,
and
we
try
to
automate
as
much
as
we
can
in
terms
of
bumping
packages
making
sure
the
project
is
healthy,
automate,
minor
releases,
for
example,
releasing
patches
and
things
like
that.
D
Just
so
that,
like
we
can
reduce
the
burden
of
like
maintaining
those
projects
and
waiting
until
the
point,
someone
wants
to
come
and
add
any
features
to
that
project.
So
the
cryogenics
team
won't
be
actually
adding
features.
We're
just
trying
to
work
on
this
automation
to
make
sure
that
the
components
are
healthy
and
being
looked
after
and
being
bumped.
And
things
like
that.
D
That's
okay.
I
think
what
you'd
like
what
we
are
interested
on
is
discussing
a
model
where
we
can
still
sort
of
abide
by
the
rules,
or
you
know
the
processes
that
we're
all
designing
right
now,
but
also
something
that
we
could
leverage
and
keep
this
sort
of
an
automation
aspect
of
our
work,
and
you
know
like
for
changes
that
are
not
like
adding
features
or
like
changing.
The
design
of
the
code.
D
Just
like
bumping
depends
and
the
you
know,
small
things
like
maybe
ci
configuration
we'd
like
to
keep
those
flowing
in
a
sort
of
a
more
automated
way
and
automate
those
as
much
as
possible.
In
order
to
do
that,
we
need,
like
credentials
of
you
know
like
some
machine
user.
That
would
be
able
to
like
auto
merge
if
the
pipeline
is
green
and
things
like
that.
G
A
Was
clear,
yeah
that
was
clear
and
I
think
the
so
the
goal
is
to
have
like
there's
we're,
not
gonna
step
in
the
way
of
bots.
I
think
it's
just
the
the
situation
that
has
happened
with
the
backup
and
restore
repo,
I
think,
has
something
to
do
with
the
move
from
the
cloud
foundry
incubator
to
the
cloud
foundry
org
and
then
the
permissions
were
basically
reset,
so
we
just
have
to
figure
out
the
right
permissions
for
that
bot
user
to
resolve
those
issues.
A
A
Are
those
things
we
want
to
review
right
or
how?
How
do
we
want
to
deal
with
those?
Because,
in
my
experience,
like
fixing
pipelines
and
having
to
go
to
vrs
or
having
to
go
to,
can
be
a
bit
painful
and
like
slow
you
down
a
bit
and
usually
when
you're
fixing
ci
you're
a
bit
in
a
hurry,
or
you
want
to
to
have
it
green?
But
that
would
be
maybe
something
to
bring
up
with
the
toc
in
general
right.
A
It's
not
something
I
think
we
can
decide,
but
maybe
having
an
exception
for
like
ci
directories,
right,
something
where
the
tasks
and
the
pipelines
live
could
be
something
potentially
interesting
to
like
for
for
speed
purposes.
I
mean
we
can
try
it
first
without
and
just
do
a
pr
based
model,
but
if,
if
that
starts
to
become
to
slow
us
down,
I
think
ci
would
be
a
potential
interesting
area
to
have
different
rules
for.
E
I
think
it
is
in
more
interest
to
cryogenics
and
vmware
in
general
to
for
those
pr
that
we
merge
to
provide
some
visibility
on
on
the
the
validation
we
have
performed.
I
I
think
it's
something
we
are
working
on,
so
that
may
helps
to
to
have
better
visibility
on
why
things
get
merged
automatically
and
so
on,
not
completely
opaque
about
the
processes
and
so
on.
C
E
D
D
Maybe
take
this
idea
that
cryogenics
wanted
to
like
fast-track
pr's
that
are
like
our
brs
bumping
dependencies
or
like
prs
just
you
know
changing
like
bits
of
ci
and
things
like
that,
and
maybe
differentiating
that
from
like
prs.
That
would,
like
you
know,
change
other
things
like.
I
think
this
conversation,
this
differentiation
hasn't
happened
for
bosch
yet,
and
I
think,
like
the
components
we've
been
talking
about
and
at
the
top
of
my
head,
that
we
look
after
and
which
are
in
the
this
working
group,
are
the
bbr
components.
I
think
only.
E
A
Yeah
I
mean
like
why
I'm
especially
talking
about
this
is
because,
for
example,
we
have
a
lot
of
repos
that
just
like
have
nci
dependency,
bumper
jobs
right,
that
would
bomb
dependencies,
run
some
tests
and
then
commit
and
push
so
those
don't
even
go
through
a
br
right
and
in
essence,
dependable,
is
the
same.
It's
just
creating
a
pr.
A
A
Those
types
of
pr's,
also
like
in
the
automation
for
for
generating
a
board.
I
have
explicitly
excluded
dependables
and
there's
a
few
other
bots
that
do
similar
things.
I've
excluded
those
because
they
just
generate
noise,
and
I
don't
think
it
makes
sense
for
this
whole
review
process
to
go
over
the
exchange
so
yeah.
Those
should
just
be
like
free
to
merge,
basically
for
the
team.
Maintaining
that
repo.
A
But
I
I
would
even
go
further,
maybe
right
with
like
maybe
saying
we
don't
need
reviews
on
like
the
ci
directory
as
in
like
pipelines
and
tasks
and
those
types
of
things,
but
I'm
not
sure
about
that.
Yeah
right,
that's
more
something
to
bring
up,
maybe
with
the
dlc.
If
we
have
like
a
bit
more
mileage
with
this
process,
and
we
noticed
that
it's
becoming
cumbersome
that
I
think
would
be
a
good
candidate
to
also
have
differentiation.
D
D
D
I
think,
as
as
long
as
it's
10,
something
like
bender,
provided,
I
feel
like
teams,
would
just
keep
like
changing
ci
and
like
just
try
to
roll
them
like
to
push
them
through,
I'm
just
bringing
that
up,
for
example,
because
like
in
some
of
the
pipelines
we
have,
we
have
like
specific
vmware
bits
and,
for
example,
if
I
ask
someone
who
is
not
vmware
to
review
that
with
me,
it
would
be
like
I.
I
don't
see
a
meaning
in
doing
that.
A
F
F
F
A
A
So
I
think
that
would
be
a
good
candidate
to
to
have
that
like
where
we
would
review
ci
changes
right,
because
there
you
are
collaborating
on
the
whole
thing
for
the
rest
for
most
of
the
other
repos.
For
now,
I
think
it's
better
to
focus
on
like
functional
changes
or
like
things
that
are
actually
changing
the
behavior
of
the
software
and
not
so
much
the
ci
but
yeah.
F
D
That
was
my
understanding
as
well
back
to
your
point,
ramon
and
also,
I
think,
for
components
that
follow
in
this
case,
where
ci
is
provided
by
a
company.
I
think
that
companies
should
have
more
flexibility
in
terms
of
you
know:
yeah,
maybe
merging
their
own
cia,
their
own
pr's,
or
you
know
like
just
pushing
to
master
because
like
they
would
have
all
the
context
on
their
ci
right,
and
it
would
be
weird
for
other
companies
to
like
review
pull
requests
with
them.
F
A
A
A
B
A
Yeah
and
and
bots
in
general,
we
still
want
bots,
I
mean
they
are,
but
I
don't
think
we
need
to
have
a
rule
or
something
about
that.
It's
just.
We
need
to
fix
the
cryogenics
thing
for
that
one
specific
repo,
but
I
don't
think
that
it
was
just
caused
by
something
else
right:
the
move
of
the
incubator
stuff.
A
A
C
D
Can
I
add
something
yeah?
This
is
maybe
something
that
cryogenics
can
contribute
with,
because
in
many
of
the
components
we
own
right
now
we
have
configured
our
pipelines
to
run
tests
all
the
tasks
we
have
against
every
pull
request
and
we
update
the
pull
request
commit
status
on
github
following
the
results
of
our
ci
so
like.
If
you
submit
a
pull
request,
the
pipeline.
G
D
D
F
D
I
think
in
a
world
where
there
is
a
ci
like
a
shared
ci
being
run
by
the
cloud
foundry
foundation,
I
think
like
this
would
not
be
a
problem
anymore.
No,
I
was
like
people
would
have
access
to
the
logs,
but
right
now,
as
the
ci
is
on
our
end,
and
it's
not
publicly
available,
the
only
feedback
people
would
have
is
the
pull
request
saying.
Oh,
these
tests
have
failed
and
like
without
details,
actually.
E
A
Yes,
yeah.
There
needs
to
be
like
a
level
of
trust
right,
so
if
we
can
limit
it
to
people
that
have
can
create
branches,
so
we
limit
it
to
br
from
foundation
members.
I
think
that
would
be
already
a
different
thing
and
I
mean
it's
not
so
much
a
problem
if
you're
running
unit
tests
right
because
that's
cheap,
but
in
lots
of
cases
we're
running
against
like
shared
infrastructure
that
keeps
like
it's
more
long
running
and
it's
creating
actual,
is
resources
and
costing
real
money.
A
A
But
I
mean
to
get
back
to
this
this
topic-
I
I'm
sorry
I
mean
so
we
could
say
something
like
running
tests
just
run
the
unit
test
right
and
then
we
at
least
we
do.
The
review.
You've
done
your
best
with
unit
tests
and
we
can
always
revert
the
pr.
Maybe
if,
like
something
big
breaks
down
the
road,
but
then
at
least
people
have
already
looked
at
it.
I'm
verified
that
it's
okay,
ish.
A
C
A
A
It's
not
so
much,
there's
not
so
much
road
map
work.
I
mean
we
can
collaborate
with
the
toc
on
things
like
the
the
jj
stem
cell
and
stuff,
but
for
it's
not
like,
we
can
decide
in
this
group
to
say
yeah,
we're
gonna
do
this
yeah,
we
can
say
we're
gonna
do
this,
but
then
still
someone
needs
to
do
the
work
so
and
that's
up
to
like
a
volunteer.
C
C
A
A
F
A
A
C
C
A
Of
view,
it
should
satisfy
the
requirements,
yeah
yeah,
and
it's
also-
and
it's
not
a
breaking
change,
which
I
like.
So
because
the
alternative
is
like
really
hard
to
coordinate
right.
Then
we
need
to
make
sure
that
all
the
vr's
get
merged
and
released
and
that
all
those
things
get
bumped
into
bosch
deployment
before
we
can
merge
that
vr
and
that
that
would
potentially
mean
that
we
have
something
locked
on
the
board
for
a
month
or
more.
A
C
A
F
A
A
F
A
Yeah
in
theory,
but
in
practice
the
the
thing
is,
we
also
have
like
ci
that
can
be
read
and
stuff.
That's
not
visible,
so
I
think
for
most
of
the
repos.
It
makes
sense
that,
like
one
of
the
vmware
folks,
who
also
deals
with
ci,
would
do
the
final
merge
right,
because
we
we
want
to
like
have
some
control
of
that
like
not
all
ci
is
red
all
the
time
right.
We
want
to
have
a
bit
of
coordination.
Like
is
ci
green
enough.
Can
we
merge
this?
A
Can
we
take
this
thing
in
but
like?
No?
That's
not
true
for
all
repos
right,
some
repos
are,
but
I
yeah
we
probably
should
set
up
something
there
to
make
that
more
clear,
which
things
can
be
like,
basically
auto,
merge
or
like
just
if
there's
approvers,
we
can
merge
and
some
things
where
we
want
more
manual
control.