►
From YouTube: Kubernetes SIG Release for 20230523
Description
Kubernetes SIG Release for 20230523
A
Hello:
everyone
welcome
to
the
May
23rd
Sig
release
weekly
meeting.
My
name
is
Jeremy
and
I'll
be
the
host
today.
I
have
placed
the
notes
into
the
chat
I'll.
Do
it
one
more
time,
just
in
case
anybody
joined
after
we
started.
If
you
could
go
ahead
and
add
yourself
as
an
attendee,
that
would
be
super
awesome.
So
we
have
an
idea
about
who
attended
and
if
we
have
anybody
that
wants
to
volunteer
to
be
a
note
taker.
That
would
also
be
really
great.
A
All
right
with
that
go
ahead
and
open
it
up.
If
there's
anybody,
that's
new
has
never
attended
a
Sig
release,
meeting
or
hasn't
attended
in
a
long
time
and
would
like
to
say
hello
again
feel
free
to
come
off,
mute
and
introduce
yourself
and
tell
us
a
little
bit
about
what
you're
interested
in.
C
Yeah,
my
name
is
Michael
Levan
I
do
pretty
much
everything
and
anything
in
the
kubernetes
space
as
an
independent
consultant,
and
this
is
my
first
time
on
the
release
team,
so
I'm
on
the
docs
release
team.
So
this
is
my
official
first
meeting.
C
A
Thanks
Jim
always
helpful
all
right
with
that,
we'll
jump
into
our
sub
project
updates
and
first
up
we'll
have
release
engineering
Marco.
Do
you
want
to
go.
D
I
added
some
notes,
so
the
first
one
is
that
bachelor's
has
went
out
last
week,
thanks
to
Veronica
dream
and
chair
before
taking
care
of
those
leases.
The
only
minor
hiccup
that
we
had
while
cutting
those
releases
is
that
sending
announcement
failed
because,
for
some
reasons
sent
great
the
provided
that
we
use
for
emails,
blocked
dream
and
because
we
are
using
the
free
tier,
we
didn't
have
any
support.
D
We
handled
that
actually
charity
had
led
by
taking
care
of
announcements
the
next
day
and
also
said
they
got
lighter
to
apologize
to
the
community
for
not
providing
the
update
on
time.
But
so
far
everything
went
very
well.
The
releases
are
pretty
stable,
no
problems
with
promotion
process,
which
is
very
nice
and
once
again,
thanks
to
everyone
who
worked
on
improvements
to
actually
make
the
process
more
stable.
Do
you
have
anything
maybe
to
add
regarding
bachelor's,
German,
gym.
A
I
think
they
went.
They
went
pretty
well
thanks
to
grant
for
jumping
in
to
help
us
out
with
the
the
publishing
of
the
packages
that
was
helpful,
I've
updated
the
calendar,
so
we
should
have
all
of
we
should
have
captured
all
of
the
the
relevant
information
about
those
patch
releases
and
the
tentative
next
ones,
and
the
calendar
has
been
updated
for
July
and
August
as
tentative
dates
as
well.
So,
if
anybody's
interested
in
when
those
might
be,
you
have
tentative
dates.
Posted.
D
Thank
you
for
taking
care
of
that
and
yeah.
If
there's
not
any
question,
I
will
go
to
the
next
topic
and
this
is
the
OBS
implementation.
It
is
going
very
well
so
far
I
applied
to
do
a
presentation
later
today.
So
I
think
we
can
do
it.
I
don't
see
a
lot
of
faults
here,
but
it
is
recorded
and
I
have
pretty
detailed,
slides,
so
I
think
it
is
going
to
be
useful
and
also
something
that
I
don't
have
detailed.
D
A
lot
of
details
about,
but
I
have
said,
Carlos
working
on
migrating
to
corks
IV
to
I
think
there
is
some
changes
merged
to
Crowley
today
and
also
to
release
libraries
that
we
have.
So
this
is
in
progress.
Let's
hope
that
we
will
have
call
sign
video
support
soon
and
if
there
are
no
question
handling
over
to
your
listing.
A
Oh
I,
don't
know
if
we
have
anybody
representing
the
release
team
in
an
authoritative
capacity,
but
Grace
left
a
couple
of
notes
in
the
meeting
agenda,
so
we
can
just
read
those
off
for
the
record
too
start
at
the
bottom.
All
the
Shadows
are
confirmed
and
onboarded.
So
welcome
to
everybody
that
is
joining
the
release
team.
This
cycle,
it's
exciting
to
have
everybody,
join
us
and
then
last
meeting
Grace
proposed
potential
release,
timeline
changes,
but
those
aren't
going
to
happen
because
enhancements
and
implementation
periods
are
already
similar
in
length
and
I.
A
A
If
you
have
any
questions,
I
think
the
best
thing
to
do
is
probably
to
Ping
Grace.
You
can
just
reach
out
on
the
Sig
release,
slack,
Channel
and
or
or
the
email
list
and
ask
questions
there.
We
can
now
async
discussions
on
anything
there.
A
B
D
And
let's
actually
make
sure
I
have
everything
prepared,
I
hope
you
should
be
able
to
see
my
presentation
right
now.
We
can
so
thank
you,
so
I'm
going
to
get
started
with
some
updates
for
open,
build
Service.
As
some
of
you
might
know,
we
are
working
on
migrating
from
Google
infra
for
publishing
and
holistic
packages.
Speaking
of
Debian
and
RPM
packages
to
open
build
service
which
is
sponsored
by
Suzy,
and
it
is
working
progress.
D
We
are
trying
to
try
forward
the
implementation
so
that
we
integrate
our
release
Pipeline
with
OBS
and
with
everything
that
comes
with
it.
This
is
a
bit
new
because
we
never
handle
publishing
packages
on
our
own.
It
was
always
Google
folks
who
did
it
for
us.
So
there's
some
significant
changes
that
we
have
to
introduce
to
make
sure
that
we
actually
support
this
and
it
works
very
well.
D
I
will
try
to
recap
today.
What
are
we
going
to
do,
starting
with
what
we
already
did,
and
then
we
are
going
to
see
maybe
some
ideas
about
how
it
is
in
how
it
is
going
to
look
like
the
first
thing
that
I
want
to
answer
for
today
is
like.
Where
are
we
today
like
what
we
did
so
far?
What
is
done?
What
is
working
and
what
is
something
that
we
can
eventually
already
integrate.
D
The
probably
the
biggest
thing
out
of
those
that
we
did
is
that
package
bags
are
completely
tested
and
I
would
like
to
take
over
the
day
again
to
text
to
now
for
refactoring
those
specs
to
be
compatible
with
that
build
with
sourcing
platform
that,
for
example,
we
are
using
for
building
s309x
packages
and
with
OBS
overall
the
way
it
is
working
right
now
we
are
chemical
RPM
packages
which
we
are
taking
to
also
generate
how
to
generate
wbl
packages,
so
that
parties
works
very
well
thanks
for
the
their
build
at
the
General
Building
packages
is
working
very
well
when
you
try
to
install
them
to
provision
Care
by
the
discuss,
the
ucube
ATM
and
to
run
conference
tested
parties
working.
D
The
next
thing
that
we
have
is
that
structure
for
OBS
projects
and
repos
is
done,
and
we
will
take
a
look
at
next
few
slides
how
it
is
going
to
look
like
there's
some
problematic
aspects
that
we
decided
that
there's
no
device
solution,
but
we
decided
to
take
some
trade-offs
to
make
it
work.
Well,
so
we
will
see
about
that
and
we
also
have
a
command
to
generate
specs
and
archives
for
OBS.
This
is
crowd.
D
D
So
the
the
first
thing
that
I
wanted
to
mention
is
the
organization
of
repos.
Speaking
of
what
Debian
and
RPM
repos,
and
the
most
important
thing
before
proceeding
is
to
understand
that
OBS
projects
and
reports
are
mapped
one
to
one.
So
that
means
that
everybody
say
OBS
project.
That
is
also
a
report
where
they
say
repo.
That
is
also
has
its
own
OBS
project
so
that
if
I
use
water,
I
love
the
world
of
Pentagon
cortex.
It
is
basically
the
same.
So
in
the
quotas
of
this
presentation.
D
There's
no
big
difference
and
the
cortex
of
water
headquarters
said:
edius
is
going
to
see,
there's
no
difference
the
sub
differences
like
access,
control
and
stuff
like
that.
That
is
going
to
be
more
relevant
later
and
what
is
also
possible
is
that
our
pirate
project
at
OBS
is
icv
kubernetes,
so
I'm
going
to
quickly
open
it
up.
It
is
basically
empty,
but
it
has
a
bunch
of
sub
projects
which
are
like
icv
kubernetes
score,
their
core,
stable
and
core
stable.
What
26
and
then
what
36
bill?
D
There's
also
going
to
be
for
about
27
and
all
other
versions
that,
depending
on
where
we
had
support
for
OBS
and
how
we
handle
that.
But
what
is
important
to
understand
is
basically
this.
This
structure
we
are
also
going
to
have
like
a
core
pre-release
for
pre-releases
like
alphabet
and
Darcy,
and
we
are
eventually
going
to
have
nightly
for
daily
builds,
but
this
is
not
planned,
kinda
out
of
scope
enough.
D
What
is
also
important
there
is
that
we
have
two
different
Records
or
OBS
projects
per
version.
The
first
word
is
icv
kubernetes
scores
table
that
micro
version,
for
example.
What
26
that
we
had
a
chance
to
see
before-
and
this
is
a
user
facing
report
project
like
this-
is
something
that
users
are
going
to
add
their
systems
like,
depending
on
the
instructions
that
we
provide
to
them
and
they're
going
to
pull
a
digital
packages
from
that
one,
however,
building
is
not
happening,
is
a
terrible.
D
Actually,
we
have
another
project
that
is
only
dedicated
to
building,
and
this
is
has
build
it
as
a
suffix,
and
this
is
where
we
push
specs
archives,
that
we
figure
build
campus,
that
we
do
a
release
command,
and
then
this
is
making
the
those
artifacts
that
you
build
packages
to
be
available
in
the
user-facing
project,
and
there
is
actually
a
technical
reason
for
that.
It
is
because
OBS,
but
speaking
of
Darker
projects
and
those
purchases,
can
only
keep
one
package
version
at
a
time.
D
For
example,
we
built
about
26.5
and
next
month
we
build
136.6
when
we
do
so.
126.5
is
not
available
anymore,
and
this
is
something
that
we
don't
want.
This
is
quite
a
huge
issue,
so
there's
a
dedicated
project
type,
it's
called
maintenance
project
where
we
can't
do
building,
but
it
can.
It
can
keep
multiple
package
versions,
for
example
both
126.5
and
well
26
6..
D
However,
as
I
mentioned
earlier,
there
are
two
problematic
packages
and
the
first
one
is
cry
tools
and
the
second
one
is
kubernetes
cni.
Why?
Because
those
packages
are
not
virtually
in
the
same
base,
kubernetes
so
cry
tools,
for
example,
follows
to
some
degree
kubernetes
notation
of
functioning,
so
there's
like
cry
tools
for
36
0
about
27
0,
but
it
doesn't
really
follow
the
petroly
schedule
at
all.
At
kubernetes,
cni
doesn't
follow
the
kubernetes,
especially
at
all,
like
you
have
kubernetes
CLI
1.2.0
and
the
probability
you're
going
to
have.
D
There
is
when
we
create
a
new
project
for
a
new
minor
release,
which
also
be
a
repo.
We
have
to
publish
cry
tools
at
kubernetes
cni
again
in
that
field
project,
so
we
create
a
project
for
about
27
that
will
be
an
empty
project.
We
have
to
create
cry
tools,
we
have
to
create
kubernetes,
see
a
die
again
and
we
have
to
push
again
trigger
again
the
build
and
then
do
the
publishing
process
for
to
those
packages,
and
this
there
is
an
example
given
hero
slices
as
well
similar
to
that.
D
It
is
important
to
know
that
those
two
packages
same
verses
of
those
packages
might
exist
in
all
the
projects.
For
example,
136,
there's
also
a
question
of
that.
If
we
decide
to
backfill
like
to
publish
again
like
how
many
versions
should
we
publish
it
and
after
discussing
it
with
Sasha,
who
also
is
a
maintainer
for
cry
tools,
we
decided
only
on
the
latest
version
of
this
time
and
we'll
see
if
you
need
to
extend
it
and
the
alternative
that
we
consider
it
there
is
that
we
publish
cni
at
creators
in
dedicated
refers.
D
So
if
you
get
back
here
where
it
is
not
ICB
kubernetes
core
but,
for
example,
icv
kubernetes
cry
tools
or
ICB
kubernetes
cni
and
then
publish
to
those
dedicated
projects
and
that
the
projects
could
be
used
for
all
kubernetes
versions.
However,
this
is
that
is
that
users
would
have
to
add
three
different
weapons
to
their
system,
not
only
one
that
is
not
ideal.
So
we
decided
to
try
this
approach
and
see
if
it
is
going
to
give
us
problems,
but
if
there's
any
feedback,
it
is
very
welcome.
D
D
So
we
are
going
to
wait
for
a
responsive
see,
but
this
is
the
plan
that
you
have
for
now
regarding
those
two
packages
and
now
I
would
take
a
moment
to
see
what
is
to
tell
us
like
what
is
the
mission
mission
statement
that
at
least
I
have
in
mind,
but
that
would
be
nice
that
we
all
agree
about
that,
and
this
is
that
we
want
to
make
managing
with
publishing
packages
possible
for
all
Community
sub
projects
the
same
way
as
for
core
packages
and
when
I
say
core
packages,
I
mean
qblade,
cubeadm
qctl
cry
tools,
kubernetes
cni.
D
We
want
to
have
a
universal
platform
and
Universal
tooling.
That
can
work
for
any
kind
of
project,
that
is
the
kubernetes
ecosystem
and
that
will
publish
under
icv
kubernetes.
Even
if
we
are
going
to
see
how
that
exactly
going
to
work,
but
we
want
to
make
this
possible.
So,
for
example,
if
let's
say
minicube
comes
Sunday
and
say
we
want
to
published
in
icv
kubernetes,
we
already
have
a
tooling
to
provide,
or
if,
let's
say
cry,
tools,
decide
someday.
We
don't
want
to
publish
along
with
kubernetes.
We
want
to
publish
standard
one
on
our
own.
D
We
have
to
learn
them
to
provide,
so
they
can
do
that
at
least.
Ideally,
this
is
going
to
work
like
promotion
process
that
we
will
have
a
manifest
and
that
you
would
add
your
entry
for
a
package
and
add
some
pre-side.
My
job
is
going
to
be
triggerated
to
the
publishing
process,
but
this
is
a
bit
of
long
term.
It
is
going
to
work
a
little
bit
different
for
now,
but
we
will
Implement
some
idea
of
publishing
process
even
right
now,
and
we
are
going
to
see
that
in
upcoming
slides.
D
So
the
question
is
very
volatile:
let's
talk
a
little
bit
about,
we
have
recommended.
As
mentioned
it,
this
is
Krell
OBS
to
manage
specs
and
packages
said:
there's
going
to
be
free
commands
for
that
there's
going
to
be
creative,
OBS
facts.
This
one
already
exists,
but
it
is
going
to
be
refactorate.
That's
going
to
generate
specs
and
archives
with
assets
and
with
specs
and
retographic.
It
is
important
to
understand
what
things
is.
We
have
I
hope
we
have
some
time.
D
So
OBS
is
a
little
bit
different
than
what
we
have
right
now
builds
are
actually
Erica,
so
there's
no
connection
to
internet.
We
can
trigger
a
build
and
then
start,
let's
say
downloading
from
the
GC
bucket
or
from
I,
don't
know
HD
by
https
from
DLK
test
IO.
We
actually
have
to
prepare
everything
beforehand.
Push
that
to
obs
in
they're
having
some
simplified
version
of
git,
like
you
have
a
virtual
control
system
and
basically,
when
you
push
it,
it's
automatically
going
to
trigger
building
that
new.
D
Then
we
have
Krell
OBS
stage,
which
is
going
to
write
crowd
OBS,
so
Crown
will
be
a
Specs
that
command
only
works
on
specs.
In
our
case
I
will
see.
Does
it
interact
with
OBS,
but
crayon
OBS
stage
is
going
to
take
that
command
at
osc,
which
is
OBS,
CLI,
wrap
everything
together.
So
we
are
going
to
see
what
is
the
workflow
going
to
look
like,
and
we
are
also
going
to
have
crown
OBS
release
which
releases
packages
for
Builder
project
to
use
a
patient
project
which
we
talked
about
earlier.
D
D
You
have
for
each
package
templates
and
cry
to
spec
file,
for
example,
for
Kratos,
lysis
and
readme,
and
it
basically
defines
RPM
spec
for
that
package.
What
is
happening
with
Debian
packages?
We
measured
that
build
and
automatic
conversion.
This
is
happening
in
OBS
itself.
Obs
is
going
to
trigger
that
build
to
generate
the
Debian
files
and
then
basically
to
based
on
that
files
to
build
packages,
and
this
is
basically
how
it
looks
like
we
provide
the
facts
to
this
tier.
D
It
is
eventually
going
to
be
versioned
so
for
each
minor
kubernetes,
at
least
so
that
we
can
easily
change
spec
files,
but
we
will
see
also
about
that.
How
exactly
is
that
going
to
look
like
and
you'll
also
provide
stuff
like
output
package?
What
you
want
to
build
version
package
Source?
It
can
be
from
https,
for
example,
if
you
want
to
download
from
the
Internet
or
if
you
want
to
take
it
from
the
Google
GCS
packet.
That's
now
possible
as
well,
and
this
is
basically
how
it
looks
like
I
can
go
quickly.
D
So
I'll
try
to
make
the
screen
a
bit
bigger
so
how
it
works
like
we
do
crowd
OBS
specs
what
you
can
do,
the
first
thing
we
can
provide
a
package
make
it
Cube
CTL,
let's
provide
version,
and
this
is
136.5
and
we
can
provide.
There
are
templates
temporary.
This
is
temporary.
D
D
And
now
what
is
actually
happening?
It
created
the
package
definition
to
cube
CTL.
Now
he
decided
to
use
like
release
a
channel
like
this
table
channel
to
take
1286
Pi.
It
is
copying
from
GCS
and
when
it
is
done,
it
is
going
to
Archive
everything,
guitar
GS,
that
we
are
going
to
push
and
we
are
going
to
get
a
message
that
it
is
successful
and
if
I
go
here,
I
am
actually
going
to
see
that-
and
this
is
like
the
templated
cube
City
aspect.
D
A
Don't
have
any
other
topics
that
I
saw
last
time,
I
checked,
so
I
would
just
keep
going,
and
if
anybody
added
anything
we
can
either
punch
it
till
next
time
or
get
it
at
the
end.
If
we
have
time
this.
D
Okay,
thank
you
and
what
is
important
about
this
specs
command
that
we
just
saw
is
that
it
is
simplified
version
of
what
qpg
was
doing
before,
but
now
it
is
only
supporting
RPM
packages
which
can
be
extended
if
needed.
We
can
also
add
support
for
Debian
packages.
It
supports
gcis
as
a
source
for
binaries.
It
has
a
simplified
code
base,
but
it
is
also
Universal.
So,
as
we
said
in
the
visual
state
with
earlier,
we
want
to
make
it
possible
to
use
this
command
for
any
sub
project
in
our
community.
D
So
stuff
like
dependencies
and
package
sources,
are
defined
in
a
yaml
menu,
so
it
is
not
defined
in
a
code
base.
That
was
the
case
before
there
is
actually
yaml
manifest
that
has
this
defined
it
actually.
Inspiration
for
this
yaml
manifest
was
how
the
promotion
process
for
images
and
files
work
right
now,
and
this
is
actually
the
example
of
this
channel
manifest
I
can
show
it
here
in
vs
code.
So
here
is
the
way
how
it
looks
like.
Basically,
you
provide
a
package,
for
example,
cry
tools.
Then
you
can
provide
a
version
constraint.
D
This
is
like
to
what
version
of
cry
tools.
Is
this
going
to
apply
this
Rule,
and
then
we
help
Source
URL
template
like
what
from
what
place
it
is
going
to
double
the
binary,
for
example,
and
I,
provided
it
a
GCS
packet
for
cry
tools
like
you
can
provide
some.
You
have
some
template
options
to
provide
like
package
version
architecture
Channel,
whatever
you
might
need
and
like
you
build
such
Source
URL
template
Krell
will
be
aspects
is
going
to
run
this
template.
It
is
going
like
to
prepare
the
URL
and
then
download
from
it.
D
You
can
also
mention
if
it
is
star
GS
or
not,
and
then
we
have
Cuban.
For
example,
it
is
a
little
bit
different
for
Source
URL.
We
have
a
dedicated
one
URL
that
is
building
similar
URL
to
this,
but
for
kubernetes
buckets.
It
also
supports
stuff
like
pulling
from
CI
artifacts
for
night.
We
builds
eventually.
So
that's
the
reason
why
we
have
dedicated
faction,
but
it
is
also
an
example
of
what
happens
when
you
have
dependencies.
You
can,
for
example,
provide.
This
is
actually
what
we
had
before.
D
You
can
provide
some
vertical
state
that
you
require
a
cubelet
1.30.0,
at
least
on
yoga
or,
and
you
require
equator
cni
one
to
zero
and
cry
tools.
136,
and
this
is
actually
going
to
be
installed
in
RPM
spec.
When
you
run
it,
there
is,
for
example,
a
cuboid
spec
carries
like
we
iterate
to
all
dependencies.
I've
actually
put
everything
here
as
a
query
and
maybe
I
have
it
handy
to
show
it
like
cubelet
tests.
D
You
can
see,
for
example,
kubernetes
cni
in
case
for
cubelet
and
yeah.
It
is
defined
it
like
this.
So
with
this,
any
project
could
create
like
data
yaml,
prepare
everything
here
and
just
use
our
tooling.
So
this
is
a
step
forward.
We're
going
to
do
eventual
promotional
process
that
I've
discussed
before.
D
And
now
that's
it
regarding
fellow
via
specs,
for
now
we
are
going
to
talk
a
little
bit
about
OBS
stage.
That's
another
sub
comment
that
we
mentioned
before,
and
this
supplement
should
invoke
real
OBS
specs,
the
command
that
is
seen
just
now
and
wrap
it
around
the
USC
CLI.
Now
this
wrapping
is
not
like.
It
is
going
to
be
shell
out
to
run
the
osc
in
a
shell.
That's
not
the
best
experience,
but
there
are
no
core
libraries
that
we
can
use
in
the
future.
D
We
might
try
to
interact
with
OBS
apis
directly,
for
example,
create
such
a
library,
but
this
is
not
the
scope
for
Alpha,
maybe
for
better
or
even
of
your
once
we
reach
table.
We
will
see
about
that
exactly,
but
the
idea
is
that
we
will
have
the
normal
stage
done
so,
like
you
run
trail
stage
as
we
do
just
now,
it
is
going
to
finish
everything
to
publish
to
the
stage
GCS
packet
from
there.
Parallel
stage
is
going
to
take
the
stage
it
is
going
to
run
osc
checkout.
D
It
is
like
it
is
going
to
pull
the
project
to
pull
all
the
packages.
Then,
in
each
package
we
are
going
to
run
trail,
OBS
specs
to
generate
specs
and
archives.
Then
there's
a
command,
that's
called
osc,
add
remove.
That
is,
like
alternative
of
git,
add
thought.
It
is
basically
going
to
make
sure
that
everything
is
staged
and
there
is
like
osc
commit
that's
actually
going
to
push
everything
to
obs
and
that's
basically
where
the
stage
is
going
to
be
done
like
real
stage
it's
going
to
be
completed
after
those
steps.
D
It's
mostly
like
going
to
be
even
a
complete
different
stage,
something
like
we
have
for
signing
so
right
now
we
have
a
dedicated
stage
in
Google
Cloud
build
that's
the
way
most
selected
cradle
OBS
take
just
going
to
work.
This
is
the
way
the
time
looking
forward
while
researching
now
we
will
see
if
it
is
going
to
work
and
the
idea
how
this
command
is
going
to
look
like.
D
So
this
doesn't
exist
yet
is
that
we
are
going
to
provide
like
real
OBS
stage,
we
are
going
to
provide
project
which
is
like
icv
kubernetes
course
table
v126.
We
are
going
to
provide
a
list
of
packages
version
for
that
packages,
package
Source.
Maybe
this
is
going
to
be
replaced
with
not
package
Source,
but
the
build
version,
so
we
just
provide
this
part
here.
This
is
going
to
be.
I
will
go
to
see
about
that
and
there's
going
to
be
like
a
published
flag.
That
is,
we
will
see
about
that
a
little
bit
later.
D
So
let's
go
more
slowly
and
crowd
OBS
release.
It
is
just
it
is
going
to
be
a
very
simple
command.
It's
just
going
to
make
sure
the
builds
are
successful
to
run
osc
release.
It
is
again
going
to
do
osc
checkout,
to
check
out
everything
and
then
do
osc
release
of
those
packages,
and
that's
basically
it
like
this
is
going
to
trigger
the
publishing
process
on
OBS
side.
It
is
very
quick
takes,
like
maybe
less
than
a
minute
and
packages
are
going
to
be
available.
It's
going
to
happen
like
in
normal
release
like
incredible
release.
D
We
are
going
to
wait
for
the
normal
part
to
be
done.
The
part.
What
we
have
already,
then
crowd
OBS
a
little
bit
run
and
then
credit
release
will
be
done
and
that's
basically,
it
idea
for
that
command
is
that
it
is
going
to
be
pretty
simple,
like
you're,
going
to
provide
the
project
you're
going
to
provide
packages
and
then
again,
this
published
flag
that
we
are
going
to
see
on
next
slide.
Okay.
D
So
what
are
the
operational
models
that
I'm
planning
for
this
to
work?
There's
going
to
be
similar
to
crowd
stages
release,
so
there's
going
to
be
integrated
mode
like
as
part
of
crowd
stage,
so
you
run
Cloud
stage
to
Stage
letter
release
or
release.
It's
going
like
ABN
to
make
sure
that
we
also
run
OBS
date
and
OBS
series
and.
C
D
Nothing
too
complicated,
but
this
is
not
going
to
work
for
sub
projects
because
they
don't
use
Krell
to
release
their
releases
and
there's
going
to
be
a
standalone
mode
which
is
going
to
run
a
cloud
build
job,
that's
going
to
build
and
publisher
packages.
That's
what
was
the
published
flag.
It
should
actually
be
submit
flag,
but
I
realized
that
too
late,
it's
going
to
work
in
a
way
that
you're,
for
example,
going
to
run
that
in
prowl
that
has
access
to
run
Cloud
build
job.
D
It
is
going
to
run
the
cloud
build
job
to
do
the
publishing
and
that's
basically
it
that's
similar
to
how
we
build
images
right
now.
For
example,
you
can
release
the,
for
example,
for
cube
cross,
similar
images,
we
run
gcp,
Google
Cloud,
build
job
and
there's
where
build
happens.
So
this
is
the
idea
for
this
as
well,
so
that
you
can
do
something
like
that
and
that's
going
to
build
a
step
for
you.
D
So
what
is
the
output
for
Alpha
speaking
of
going
to
graduate
to
Alpha,
and
we
want
to
finish
Krell
OBS
specs
completely?
Let's
hope
this
is
going
to
be
upcoming
days.
There's
not
a
lot
of
work
left,
at
least
not
in
my
opinion.
We
are
going
then
to
implement
Krell
OBS
stage
at
Krell
OBS
release,
then
unit
integration
and
end-to-end
test.
D
So
one
thing
that
I'm
going
to
do
at
least
initially
is
that
I
will
probably
drop
the
test
that
they
have
and
then
get
back
to
test
later,
because
I'm
still
experimenting
to
try
to
figure
out
how
it
is
going
to
look
like
spending
a
lot
of
time
on
test
and
that
eventually
scratching
everything
is
starting
over.
Let's
hope
it's
not
going
to
happen,
but
there
are
a
lot
of
changes
between
what
we
planned
and
what
is
actually
happening.
D
So
testing
is
going
to
happen
later,
but
before
we
actually
integrate
credible,
obsc
credit
stage,
Cloud
release,
and
then
we
also
have
to
update
cap
7031,
because
there
are
some
changes
and
it
will
be
nice
to
clarify
everything
that
we
had
this
presentation
and
that
is
actually
going
to
happen.
Regarding
implementation
over
the
upcoming
days
and
weeks,
and
then
we
have
radiation
to
better
when
we
actually
have
everything
integrated,
we
can
declare
better.
Let's
hope
this
is
Alpha
is
going
to
happen
for
about
28.
D
Let's
hope
that
is
going
to
follow
shortly
after
and
then
what
is
going
to
happen
between
Alpha
and
beta
communication
is
the
most
important
part.
We
are
going
to
figure
that
out.
We
will
look
into
replacing
shelling
out
to
osc,
with
some
go
library
that
interacts
with
obs.
Such
Library
doesn't
exist
as
eventually
before
so
we'll
probably
have
to
make
it
ourselves.
D
Let's
see
about
that,
and
then
we
will
be
if
we
do
something
like
that,
we
could
also
come
up
with
a
tool
to
manage
users,
permissions
and
projects,
because
right
now
release
money
just
needs
to
do
that
on
their
own,
and
this
is
like
Pro
to
errors.
We
don't
like
that.
We
want
githubs,
so
we
are
going
to
look
if
such
tool
is
viable
and
finally,
tests
for
published
packages
like
are
those
packages
going
to
install
to
if
cluster
is
going
to
pass
conformance
testing
if
backless
compatibility
is
satisfied.
D
Stuff
like
that,
and
then
we
need
to
clearly
Define
the
duration
at
the
stable,
like
what
is
the
important
part
here
is
how
we
want
to
face
out
Google
infra
like
when
do
we
want
to
stop
publishing?
Are
you
about
to
freeze
the
Google
weapons
to
say
please,
starting
from
let's
say
130,
you
have
to
pull
packages
from
OBS
and
yeah,
that's
biscuit
and
that's.
Basically,
it's
for
presentation
as
well
and
I
want
to
thank
you
for
listening
and
coming
today.
D
A
A
Once
the
recording
is
available
on
YouTube
after
the
magic
that
happens,
I'll
try
to
find
it
and
drop
a
link
into
the
channel,
so
we
can
signal
boost
it.
A
little
bit
more.
D
A
Cool,
does
anybody
have
any
questions
about
the
OBS
work?
I
think
Marco
happy
to
answer
some
questions
for
the
next
few
minutes.
Otherwise
we
can
call
it
a
day
give
folks
a
little
bit
of
time
back.
A
As
Marco
said,
if
you're
interested,
please
follow
up
on
slack
I
think
there's
a
lot
of
good
stuff.
That'll
come
out
of
this
and
it'll
be
a
nice
Improvement
for
the
way
things
work
today.
When
we
get
it
all
done,.