►
From YouTube: 2023 03 02 Docs Office Hours 2
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
And
we
there
are
other
Awards
and
nominations
that
continuous
delivery.
Foundation
has,
you
can
see
them
on
their
award
site
and
it
gives
a
nice
overview
of
the
awards,
what
they
look
like
the
different
projects
and
how
this
is
all
going
to
look
and
the
winners
are
announced
that
CD
con.
So
this
year
that
will
be
announced
and
people
will
be
presented
with
their
awards
at
cdcon
itself.
A
Voting
is
going
to
open
up
on
Wednesday
March
8th
so
same
day
as
our
LTS
release,
and
then
voting
will
be
open
until
the
end
of
March
when
it
closes
on
Tuesday,
March,
28th
and
then
from
there.
The
results
will
be
right
at
cdcon,
so
by
all
means.
If
you
have
a
chance
to
to
have
some
time
think
of
someone
in
between
now
and
tomorrow
that
you
want
to
throw
a
nomination
for
that's
amazing.
Please
do
so.
Everyone
appreciates
it
next
up.
This
is
something
that
we've
been
discussing.
A
Lately
is
the
documentation
transition
to
Java
17.,
so
with
the
April
May
2023
release
of
Debian
12,
it
is
not
going
to
come
with
Java
11.
It
will
be
released
with
Java
17..
So
when
this
happens,
we're
going
to
transition
the
Jenkins
documentation
to
reflect
that
and
utilize
Java
17
for
installation
and
other
documentation
purposes.
A
This
does
not
mean
Java.
11
support
is
ended
or
dropped
in
any
way
to
be
performed.
That
will
continue,
but
job
17
is
available
fully
functional
as
and
supported
since
Jenkins
2.361.1.
So
we
want
to
encourage
people
to
transition
sooner
than
later
and
get
ahead
of
the
timeline
that
we
will.
We
will
eventually
be
in.
A
This
will
also
provide
a
consistent
Java
version
and
again
more
functionality
to
users
as
they
move
to
Java
17..
So
it's
a
benefit
for
everyone
involved.
Ultimately,
and
I
have
emailed
Tim
Jacob
as
the
release
officer
to
let
him
know
about
the
transition.
He
responded
already
saying
that
everything
sounds
good
to
go,
so
no
surprises
to
be
had
and
just
an
easy
win
for
us
there
and
then.
The
next
note
is
about
improving
the
end
of
life
notifications.
A
Now
Mark
I
wasn't
at
the
platform
Sig
meeting.
Would
you
be
able
to
share
more
about
this
yeah.
B
B
So
so
his
suggestion
was
maybe
what
we
do
is
a
directory
that
we
look
at
every
file
in
that
directory
and
treat
each
file
as
a
data
file
and
that
data
file
could
contain
the
thing
that
we're
telling
about
its
end
of
life
and
the
end
of
life
date
and
what
message
we
should
say
after
end
of
life.
What
message
we
should
say
before
end
of
life
I
mean
there's
a
lot
that
we
could
do
with
this
concept
of
trying
to
hey.
I
want
to
actively
tell
people.
B
This
thing
is
going
to
be
end
of
life.
If
you
have
it
and
it
our
the
presence
of
this
file
on
the
file
system
would
say
you
have
it
so
so
when
we
create
the
Alpine,
when
we
create
the
blue
ocean
container,
the
terminal
blue
ocean
container
as
an
example,
we
write
this
file
a
file
to
this.
To
this
directory
that
says,
this
container
is
ended.
B
It's
time
when
we
do
that
with
centos7,
we
write
another
file
which
is
centos7
end
of
life,
for
the
Jenkins
project.
Is
this
date
Etc
and
and
for
me
the
idea
of
oh,
you
know
what
a
general
purpose
admin
monitor
for
those
kinds
of
things
that
can
be
informed
by
the
presence
of
a
file
on
the
file
system.
B
B
B
The
day
will
happen
when
it
is
end
of
life,
and
we
might
use
this
mechanism
to
put
that
in
there
so
that
the
end
of
life
message
has
a
little
bit
more
intelligence
of
being
hey
you're
before
the
end
of
life
date
will
show
you
this
message
where,
after
the
end
of
life,
Dave
we'll
show
you
this
message
and
bati's
point
was.
This
is
probably
a
good
con
good
idea
for
a
a
small,
relatively
lightweight,
Jenkins
enhancement
proposal.
B
That
brings
the
idea
for
discussion
and,
and
then
we
we
use
this
Jenkins
enhancement
proposal
to
discuss
the
idea
get
get
people's
insights.
Then
we
do
a
pull
request
to
to
Jenkins
core
saying
here's
here
we
did
this
plan,
so
I
I
think
I'm
going
to
go
ahead
with
it.
It'll
be
it'll
be
a
while
because
it
takes
me
a
while,
but
it's
a
good
fit
matched
with
the
Centos
7
accelerated
end
of
life
idea
that
I've
got
so.
A
Yeah,
that
brings
me
up
to
speed
completely
frankly
so
I'm.
That's
all
very,
very
clear
for
me
mark.
Thank
you
now.
A
And
so
just
something
that
I
had
in
mind
as
we
were,
as
you
were
talking
Mark,
so
maybe,
including
just
like
a
partials
directory
of
the
messages
that
we
could
share,
or
just
a
couple
of
different
messages
that
we
could
kind
of
use
as
a
template
for
the
different
pieces
or.
B
Yeah
and
it's
it's
I
think
you've
got
the
right
concept
and
I'm
certain
that
the
idea
is
not
fully
vetted
yet
right.
I
know
that
there's
more
thought
that
has
to
go
into
this,
you
know:
should
the
data
files
be
XML,
because
everything
Jenkins
does
as
an
XML.
Should
they
be
yaml,
because
people
are
more
comfortable,
writing
yaml.
Should
they?
What
which
field
should
they
have?
What
should
we
do
with
those
fields?
B
C
B
No,
no,
no,
no
you
really
don't
get.
We
want
to
get
me
started
on
the
hypocrisy
of
space,
sensitive
data
files
when
people
harangued
me
gave
me
a
note
terrible
hard
time
about
my
love
of
the
Python
language,
with
its
space.
Sensitive
syntax
I
do
not
want
to
yeah
absolutely
yaml
it.
It
is
what
it
is.
Space
sensitive
data
files
are
are
just
as
interesting
as
space
sensitive
languages.
A
Thank
you
very
much.
Mark
appreciate
the
explanation
and
clarification
and
before
I
move
on
to
the
next
thing
on
the
agenda,
I
just
wanted
to
welcome
in
Monica
I
saw
that
she
had
joined
while
we
were
in
the
middle
of
that
discussion,
so
welcome
Monica,
hi,
I,
hope
you're
having
a
good
day
today
and
yeah.
If
you
have
any
questions,
we'll
absolutely,
please
feel
free
to
share
and
we
can
answer
as
best
we
can
hello.
A
Okay.
The
next
thing
on
the
on
the
agenda
was
the
end
of
life
checklist
that
we
have
started
to
discuss.
A
So
in
line
with
what
we
were
just
discussing
about
the
end
of
life
notifications,
we
do
have
several
items
that
are
coming
up
for
end
of
life
relatively
soon,
with
Ubuntu
being
first
and
at
the
end
of
April,
Ubuntu
18,
specifically
sorry,
and
so
the
checklist
that
we're
thinking
of
is
to
make
sure
that
we're
looking
in
the
right
repositories,
packaging
sites,
any
sort
of
container
in
images,
jenkins.io
and
updates.jenkins.io,
just
anything
that
we
could
potentially
find
this
information
in
or
search
for.
A
A
So
this
is
something
that
we're
just
continually
working
on
at
this
point
in
time
we
haven't,
it
hasn't
manifested
into
anything
super
constructed
just
yet,
but
as
we're
going
through
as
we
get
to
the
point
of
looking
at
the
end
of
life
for
Centos
7
specifically,
and
these
other
products
where
this
is
going
to
become
more
real
and
more
literal
in
the
sense
of
having
a
template
or
a
checklist
to
work
through.
C
Kevin
sorito
interrupt
yeah,
just
I'm,
just
wondering
for
your
checklist
content
ideas.
Do
you
think
of
automating?
Why
you
know
when
we
spot
a
place
in
the
documentation
where
we
are
referring
to
a
version
that
will
go
end
of
life
soon?
Should
we
modify
the
documentation
so
that
we
put
just
a
little
bit
of
automation
so
that
whenever
we'll
change
the
version,
then
we
won't
have
to
come
back
to
that
same
piece
of
documentation
and
putting
it
up
to
date
once
again,.
A
C
B
And
so,
for
instance,
the
choosing
the
right
Jenkins
version
to
build
against
so
choosing
the
right
minimum
Jenkins
version
is
data
driven
is
data
generated,
but
it
requires
custom
work
to
do
that
and
for
me
the
challenge
is,
is
the
is
the
custom
work?
Is
the
well
the
update,
often
enough
to
justify
inserting
automation,
to
replace
the
human
effort
and
these
operating
system
end
of
life
are
so
infrequent
that
well.
The
same
question
applies
to
the
Jenkins
release
checklist
that
we
use
right.
A
I've
had
worse,
don't
worry
about
that
also,
and
this
is
just
what
I
was
thinking
of
in
my
head-
there's
contextual
text
around
what
references
we
need
to
update
potentially
and
if
we
automate
those
just
like
that
version
update,
we
would
still
have
to
I'd,
like
someone
would
still
have
to
go
back
in
and
update
the
text
around
it
if
it
needs
to
be
changed
in
that
regard,
so
the
automation
would
definitely
be
possible
and,
like
Mark
said
we
have
it
elsewhere.
A
I
know
I've
seen
Alex
Brandis
do
a
lot
of
Automation
and
changing
of
things
recently
with
links
for
an
instance,
but
I
mean
if
we
can
take
one
thing
out
of
it.
Maybe
it's
maybe
something
worth
looking
into
I
I
feel
like
I.
Would
just
do
it
manually
myself
anyway,
because
I'm
a
stickler
for
that
sort
of
thing,
but
if
it
makes
life
easier,
I'm,
not
opposed
so
yeah
and
and
as
Mark
had
said,
there
is
a
release
checklist
for
the
Jenkins
LTS
releases
that
we
use.
A
C
We're
giving
that
I
have
another
question
and
a
remark
maybe
do
we
know
the
definitive
list
of
all
the
OS
and
tools
packages
we
depend
on
or
is
it
written
somewhere?
You
know,
for
example,
Ubuntu
something
alt
points
on
things.
If
there
are
a
text
file
or
a
data
fi
somewhere,
which
lists
all
our
dependencies.
C
Globally,
for
all
students,
core
yeah,
Jenkins
score
and
documentation,
in
fact,
I
was
just
wondering
you
know
the
other
day
Mark,
you
told
us
about
to
create
open
source
website
which
leads
the
end
of
life
of
products
and
operating
systems,
and
so
on.
Distributions
and
I
was
wondering
if
we
could
generate
some
kind
of
bomb
I
don't
know
if
the
term
is
right,
but
you
know
all
the
distribution
version
and
so
on
that
we
are
referring
to
in
the
documentation.
So
that's
when
we
make
a
request
to
the
API
of
the
website.
C
We
could
then
know
that
something
has
changed
and
that
maybe
a
human
being
should
modify
the
existing
documentation.
With
that,
you
know
just
by
looking
at
the
file
which
has
changed
because
of
the
API
changes.
I,
don't
know
if
I'm,
making
myself
clear,
I'm,
not
so
sure,
but
yeah
I
can
see
a
face.
Mark,
maybe
I've
made
a
point:
no,
no
I.
B
It
could
be
that
well,
although
I
didn't
know
how
the
yeah
I
mean
I
think
what
you're
saying
is,
is
there
a
way
that
we
could
have
our
own
reminders
that
something
we
are
mentioning
is
in
fact
approaching
end
of
life
because
they
will
reach
end
of
life
right
every
one
of
them
will
reach
end
of
life,
and
if
we
reference
something
by
version
number,
should
we
then
have
a
way
of
knowing
when
that
end
of
life
date
is
approaching.
C
B
Yeah
and
unfortunately,
I
don't
know
how
to
do
it,
but
I
think
it's
an
interesting
idea,
I
think
it's
worthwhile
to
say.
Okay,
could
we
find
a
way
to
annotate
documentation?
That
says
this
is
a
reference
to
and
then
maybe
it's
a
reference
to
a
page
on
the
end
of
life
date
site
for
now,
for
instance,
whatever
and
then
okay
check
that
site
are
we
are
we
about
to
end
life,
that
kind
of
thing
yeah,
good
question.
Thank
you.
A
Yeah
and
I
know
that
last
time
we
took
a
look
at
the
end
of
life
end
of
life
date
site
here
there
is
a
they
do,
have
their
API
guide,
so
it
is
connectable
at
that
point,
and
so,
like
I,
like
Marx
I,
think
I
think
there's
a
real
possibility
there
and
it
would
be
neat
to
have
that
sort
of
automation
there
as
well
I,
don't
know
how
to
do
it,
but
it's
yeah.
That
sounds
really
neat
I
like
it.
A
Thank
you
any
other
questions
for
you
or
anything
comments.
C
A
You
don't
have
no
apologies
necessary,
okay,
now
next
up
on
the
list,
so
again,
pre
so
prepping
for
the
Cento
7
end
of
life
as
Mark
mentioned.
This
is
something
that
we're
trying
to
encourage
a
lot.
Sooner
than
later.
There
are
lots
of
reasons
to
do
this.
Most
of
them
have
to
do
with
just
the
older
older
configuration
settings
that
out.
A
Cento7
is
looking
for,
such
as
the
command
line
and
SSH
versions
that
they're
using
and
the
docker
container
has
been
deprecated
since
September
2022
the
engine.
It's
entered,
maintenance
back
in
2020
and
its
official
end
of
life
is
in
June
2024
from
Centos,
so
it
does
make
sense
to
start
moving
towards
this
bat.
Now,
as
opposed
to
later
the
some
of
the
replacements
that
we
have
listed
here,
Alma
Linux,
Rocky
Linux.
A
Some
of
these
have
been
added
to
the
documentation
already
by
Mark,
so
there
already
is
presence
there
and
it's
just
a
matter
of
going
through
and
taking
care
of
the
rest
of
them
and
Mark's
going
to
submit
a
Jenkins
enhancement
proposal
to
get
the
everything
kind
of
focused
and
connected,
and
so
we
can
submit
our
feedback
potentially
get
a
blog
post
written
as
that
is
going
to
be
necessary
before
everything
kind
of
just
moved
away,
but
I
think
oh,
no
wait
I
just
I
anyway,
so
the
Jeff
will
have
things
like
blog
post
ideas,
the
timeline
that
we're
going
to
be
looking
at
what
kind
of
warnings
we're
going
to
have
to
provide
to
users
in
the
this
explicit
end
of
life
date
Mark?
A
B
Just
that
it,
it
I
think
it
makes
sense
and
I'm
gonna
I'll
go
ahead.
I
don't
yet
have
an
idea
of
when
I'll
start
this,
but
it
feels
like
it's
a
good
given
the
platform
Sig
questions
from
the
security
team
about
hey.
Can
we
get
rid
of
some
of
these
old
container
images,
and
this
is
one
of
those
examples.
There's
there's
plenty
of
motivation
for
this
idea
right.
B
There's
plenty
of
motivation
to
say:
look,
let's
admit
that
we
have
neither
the
interest
nor
the
capacity
to
maintain
Centos
7
amongst
Jenkins
contributors,
and
we
get
to
decide
what
we're
willing
to
support
and
I.
Don't
I,
don't
know
of
anybody
of
any
of
the
Jenkins
contributors,
Jenkins
active
maintainers,
who
are
interested
in
maintaining
support
for
Centos,
7.
B
A
Well,
that's
good.
At
least
we
have
buy-in
on
that
then
great.
So
thank
you
very
much
Mark
for
the
additional
contacts
and
information
back
background.
So
that's
something
that
will
be
coming
up
soon
later.
Hopefully,.
A
Joining
take
care
and
yeah,
so
we're
coming
up
on
against
time.
I'll
wrap
things
up
here.
We
just
have
a
couple
more
updates.
The
first
thing
here
is
the
Google
summer
of
code
preparation.
So
the
Google
summer
code
status
page
has
been
updated
to
share
our
2023
participation
announcement.
A
We
are
hosting
the
weekly
Google
summer
of
Code
office
hours.
I
have
linked
here
of
the
jenkins.iowa
events
calendar,
since
it
does
have
the
sessions
on
here,
and
you
can
add
it
to
your
calendar
right
from
here.
So
right,
there
copy
to
my
calendar,
the
zoom
meeting
links
available
and
the
Google
Doc
for
the
notes.
A
So
if
you
have
questions
or
or
anything
that
you'd
like
to
check
in
with
about
Google
summer
of
code,
you
can
see
all
those
sessions
that
we
have
in
the
jenkins.io
events
calendar,
and
this
is
scheduled
out
for
several
weeks.
So
you
can
see
just
where
everything
is.
The
specific
projects
may
start
scheduling
their
own
sessions,
but
that
will
happen
once
things
get
started
and
the
project
leaders
will
let
you
know.
A
And
then
for
the
site
generation
for
jenkins.io
project
Rajiv,
who
joined
the
doc's
office
hours
a
couple
weeks
ago
and
said,
he's
willing
to
Mentor
the
site
generation
project
and
we're
we're
going
to
be
using
in
Torah
to
build
jenkins.io
and
allow
doc
pages
to
be
version
specific
and
that's
the
biggest
thing
there
is
the
version
specific
documentation
potential
right
now.
We
just
have
either
just
kind
of
a
general
statement,
or
it's
making
sure
that
it's
something
that
makes
sure
that
both
the
weekly
and
LTS
are
going
to
work.
A
A
A
So
this
is
something
that
I
want
to
actually
add
to
the
contributing
guide
and
set
some
guidelines
up,
for
this
also
would
include
stuff
like
image
guidelines
and
how
to
best
use
images,
compression
quality
size,
all
sorts
of
stuff
like
that,
and
then
things
like
making
sure
that
it's
a
summary
of
the
book
and
not
necessarily
the
the
the
blurb
that
is
given
out
to
websites
to
that
are
potentially
selling
the
book.
We're
not
trying
to
sell
it.
A
Just
providing
this
information
and
resources
to
anyone
that
wants
to
that
is
interested
and
they
have
been
being
submitted
as
yaml
files,
which
does
not
accept
formatting,
like
a
lot
of
them,
are
being
generated
with,
for
instance,
on
some
of
the
Amazon
book
reviews
that
I've
seen
they
have
bolded
lists
that
doesn't
translate
properly
in
the
yaml
file.
A
Unfortunately,
so
there
does
have
to
be
some
updating
and
changing
and
review
there,
but
the
formatting
definitely
has
to
be
a
little
bit
simpler
or
more
standardized
and
that
might
include
changing
to
the
using
ASCII
doc
partials
as
opposed
to
yaml
files.
At
a
later
point,
I'm
not
going
to
worry
about
that
for
right.
Now,
though,
we
there
are
way
too
many
good
contributions
to
start
upending
things
like
that,
and
then
the
last
note
here
is
for
book
cover
images.
A
A
There's
compressor.io,
there's
a
bunch
of
different
sites
and
applications
out
there
and
available
to
use
where
you
can
compress
the
image,
retain
the
quality
and
make
sure
that
it's
a
lot
less
heavy
lifting
for
Jenkins
page
again,
I'm
going
through
a
lot
of
the
book
submissions
right
now
and
reviewing
and
submitting
feedback
and
doing
what
I
can
to
make
them
a
little
bit
more
aligned
and
unified
in
terms
of
their
presentation.
Outside
of
that,
though,
I
truly
appreciate
all
the
work
everyone's
been
contributing
and
submitting.
A
There's
a
lot
to
go
through
and
we're
trying
to
invest
to
get
through
everything,
but
it
there's
just
it's
so
much.
Quality
content
to
work
through
and
sift
through,
that
I
want
to
make
sure
that
we're
doing
really
they're
doing
right
by
the
user
in
terms
of
the
reviews
and
the
suggestions
and
feedback
we're
providing
everything
should
be
constructive
and
it
should
be
able
to
look
at
as
a
learning
moment
or
filling
a
knowledge
Gap,
something
like
that.
There
should
not
ever
be
any
feelings
of
Confrontation
or
inadequacy,
or
anything
like
that.
A
This
is
a
learning
environment.
This
is
an
open
environment.
Open
source
is
the
name
of
the
game,
so
outside
of
that
Bruno
did
you
have
any
other
questions
or
any
items
here.
A
Kevin.
Sorry,
sorry.
A
A
Thank
you
again
to
everyone
for
joining
and
I,
appreciate
it
and
have
a
great
rest
of
your
day.
Thanks
a
lot.