►
From YouTube: 2023 04 21 Docs Office Hours
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
Work,
hello
and
welcome
to
the
Jenkins
documentation
office
hours
today
is
April
27
2023
and
it
is
the
EU
EU
US
edition.
Today
we
have
myself
Mark,
Waite
and
Bruno
Brockton
and
for
and
if
anyone
else
comes
in
we'll
welcome
them,
as
we
always
do
on
the
agenda
today,
I
have
an
update
for
Google
summer
of
code.
The
announcement
is
going
to
be
coming
next
week,
so
just
want
to
make
sure
everyone's
aware.
Recently,
Alex
brandes
has
submitted
a
request
to
potentially
revise
Community
feedback.
A
So
I
wanted
to
discuss
that
here.
Lts
2.387.3
is
going
to
be
coming
out
next
Wednesday,
the
next
LTS
Baseline
is
being
discussed.
There
were
some
Java
updates
recently
within
the
last
couple
weeks
for
the
various
Java
versions
that
we're
using
right
now
so
11
17,
20.
A
cdcon
is
coming
up.
So
just
quick
note
on
that
reminder
and
some
discussion
around
the
plan
to
transition
the
documentation
from
using
Java
11
to
17.
note
for
the
success
stories,
link
that
we
now
have
and
there
is
an
update
to
XML
handling
for
no
characters.
So
that's
something
that
we'll
talk
about
and
that's
going
to
be
coming
up
in
weeklies
and
LTS.
Eventually,
one
of
those
discussions
we've
been
having
is
alternate
ways
to
handle
stale
documentation,
pull
requests,
so
we've
been
making
some
Headway
and
got
some
actions
done
there.
A
So
update
from
that
Marksman
getting
a
lot
more
information
and
data
for
the
end
of
life.
Notifications
in
Jenkins
course
so
lots
of
great
great
conversations
and
feedback
happening.
So
we've
got
everything
listed
out
here
and
we'll
talk
more
about
that
and
then.
Finally,
as
we've
been
discussing
the
end
of
life
for
Centos
7
and
the
Jenkins
project,
anything
else
that
we
want
to
make
sure
is
on
the
agenda
today
or
anything
else
that
anyone
wants
to
know
no
matter.
A
What
thank
you
very
much
so
first
things,
first
Google
summer
code
is
vastly
approaching
they
are
going.
Google
is
going
to
be
announcing
the
accepted
contributors
on
May
4th,
so
next
Thursday
and
then
May
5th.
We're
gonna
have
the
Jenkins
project
we'll
have
office
hours
dedicated
to
welcome
those
accepted
applicants,
so
keep
an
eye
out
for
that
announcement
and
we'll
also
have
follow-up
posts.
A
Tweets
LinkedIn
posts
about
this,
so
even
if
you
don't
see
it
in
one
place,
you're
sure
to
see
it
somewhere
and
just
nice
welcome
back
to
yuming
gong,
who
is
returning
after
being
a
contributor.
Last
year
this
year,
they're
returning
as
they're
coming
back
as
a
mentor
so
really
excited
to
have
that
return,
and
thanks
for
joining
me
that
project
and
the
all
the
yeah
thanks
for
joining
the
project.
A
A
So
right
now
there
is
a
straightforward
way
for
people
to
say
they're,
either
having
a
great
time
with
the
release
having
a
time
and
having
a
horrible
time
so
they're,
very
simple
measurements,
it's
just
numbers
and
kind
of
a
status.
They
do
give
the
option
to
provide
a
jira
ID
when
someone
clicks
on
it,
but
you
know
Alex
had
pointed
out
a
lot
of
things
like
that,
doesn't
necessarily
always
happen.
A
It's
hard
to
action
on
those
things,
if
there's
no
Trail
or
person
or
contact,
it's
not
necessarily
beneficial
to
the
developers
and
people
working
on
this
as
it's
harder
to
really
really
pin
down.
What's
going
on
and
what's
happening,
and
so
we've
been
discussing
this
a
little
bit
further
and
I.
Think
it's
worth
examining
this
and
taking
a
look
at
but
I.
Think
personally
that
there's
ways
we
can
use
these
to
our
advantage
as
opposed
to
potentially
just
having
them
be
a
counter.
A
Essentially
so
I've
questioned
whether
or
not
we
could
actually
use
these
as
a
means
to
get
someone
into
the
creating
a
ticket
window
or
if
they're,
if
they're
saying
they
have
to
roll
back,
I
was
thinking.
Maybe
we
could
have
it
redirect
to
the
jira
issue
tracker
where
they
could
create
the
ticket
instead
of
asking
them
to
provide
the
grid
number
recognizing
that
that
could
end
up
in
a
lot
of
unnecessary
tickets
and
I
don't
want
to
overload
anyone's
system
in
that
sort
of
regard.
A
But
that
might
having
more
information
in
this
case
might
be
okay,
because
if
it's
all
related
to
the
same
issue
or
if
multiple
people
are
reporting
the
same
thing,
they
can
all
be
linked
together
and
potentially
have
those
extra
ones
closed
out
in
favor
of
one.
But
again
that's
a
very
different
View
and
yeah
I'm,
not
sure
what
the
the
final
result
will
be,
but
just
wondering
if
there's
ways
to
use
these
to
our
advantage
as
opposed
to
just
removing
them
outright.
For
instance,.
B
Yeah
and
my
my
preference
is
not
to
remove
them.
There
have
been
a
number
of
discussions
about
ways
to
improve
them,
but
nobody
willing
to
do
the
implementation
work
to
implement
the
improvements
and
and
I'm
I'm
hesitant
to
lose
the
data
that
we're
Gathering
right
now
to
to
not
have
that
in
the
future.
We
don't
have
anyone
who's
committed
to
do
a
replacement
for
these
right.
The
rating
system,
if
you
scroll
down
a
little
bit
Kevin
you'll,
see,
for
instance,
sometimes
there's
jenkins-420,
that's
submitted
or
jenkins-1
and
the
bug
the
bug
IDs
are
here.
B
We
go
on
375.
when
you
see
jenkins-2
and
jenkins-3
and
299,
which
are,
in
fact
not
not
valid
or
useful
bug
reports.
The
the
complexity
there
is
that
we
just
don't
know
in
the
context
of
this
page.
If
what
they're
submitting
is
a
useful
reference
or
not
saying
oh,
it's
a
closed
bug
report
actually
doesn't
help
it
because,
if
it's
a
closed
bug
report,
but
it
really
caused
them
to
roll
back,
that's
a
valid
thing.
B
If
it's
an
a
a
non-existing
bug
report-
okay,
that
that
might
be-
but
it's
easy
to
choose
novel
numbers
that
are
existing
bug
reports
that
are
irrelevant
two
three,
those
are
probably
real
bugs,
but
they
didn't
actually
affect
2.375.1
in
any
way.
A
Right
and
more
than
likely
they've
been
closed
for
some
time.
If
it's
going
to
be
one
or
two
something
like
that,
absolutely
since
I
know
we're
up
to
70
something
thousand
but
yeah,
but
yeah
and
like
I
I.
Definitely
don't
want
to
take
that
stuff
away
as
a
matter
of
what
could
come
across
as
seeming
less
transparency
or
just
less
Insight.
It
I
think
it's
even
if
it's
not
the
most
valuable
thing
it's
nice
to
have
just
so.
People
can
take
a
cursory
look
while
they're
going
through
the
change
log
to
see.
A
C
I
don't
know,
I
think
they
are
quite
useful
as
they
are
and
you're
right,
giving
more
freedom
to
the
end
user
to
declare
a
new
Jenkins
jira
issues
or
referring
to
non-existing
bugs
it
doesn't
really
make
sense.
I,
don't
know
how
we
should,
or
maybe
you
write
that
but
I'll
keep
an
eye
on
your
discussion,
Kevin,
Mark,
Alexander
and
so
on,
because
maybe
something
good
will
come
from
that
discussion.
It's
good
as
it
is.
It
could
be
better,
but
I
have
no
idea
how
better
could
be
implemented.
Yeah.
B
Thanks
for
asking
yeah
so
Kevin,
if
you
open
the
weekly,
we
can
see
on
already
on
page
one
above
the
fold,
we
can
see
two
an
example
of
a
very
useful
use,
and
last
week,
so
you
see
under
2.402,
71156
is
actually
a
very
important.
Oh
we've
got
a
regression
there
and
that
that
one
really
matters
I
understand
why
they
rolled
back.
Given
this
description.
B
B
I
think
I
think
you
said
it
exactly.
We
can't
we
there
isn't.
There
is
other
than
the
human
screening
that
we
do
right
now
and
and
given
that
the
human
beings
who
look
at
this
are
looking
at
it
for
answers
to
the
question,
shall
we
consider
this
as
an
LTS,
Baseline
and
I
confess
I
use
that
in
my
prepping,
an
email
that
says
I
think
we
should
use
2.401
as
LTS
Baseline?
That
email
was
inspired
by
the
fact
that
hey
there
weren't
any
incredible
reported
rollbacks
for
2.401.
B
A
B
A
A
So
next
thing
up?
So
we
have
our
next
LTS
release
is
coming
on
May
3rd,
it
will
be
2.387.3,
so
the
RC,
the
RC
candidate,
everything's,
ready
to
go
testing
is
available,
changelog
and
upgrade
guide
or
in
added
and
submitted
all
we're
waiting
for
is
the
approval,
the
final
approval
and
merge
on
that
there
and
we'll
be
good
to
go
and
then,
as
Mark
had
shared.
We
have
also
started
the
discussion
for
the
next
LTS
Baseline
right
now.
The
highest
voted
suggestion
is
2.401.
A
As
Mark
said,
there
were
no
real,
credible
threats
of
rollback
or
anything
that
was
reported
so
seems
like
a
good
Baseline
to
work
from
and
yeah.
It
does
have
support
from
others
as
well.
So
if
you
have
any
strong
feelings,
one
way
or
the
other
please
check
in
on
the
mailing
list
and
share
next
up,
there
were
recently
some
updates
for
various
Java
versions
from
timarin
openjdk
and
Oracle.
A
We've
put
the
Tamarind
ones
here
as
they're
the
most
reliable
and
most
used
in
as
far
as
Jenkins
goes,
and
just
they
have
11.0.19.
This
is
that
latest
release
the
19th.
It's
got
notes
and
there
are
yeah
it's.
This
is
something
that
everyone
should
be
aware
of
and
make
sure
they're
doing.
Mark.
Is
there
anything
specific
for
the
update
or
why
people
need
to
be
aware
of
the
update.
B
C
C
Not
so
sure
yeah
I
think
I
saw
the
pr
for
the
11.0.18,
but
don't
know
about
the
19.
B
Yeah,
let
me
check
because
I
need
to
check
to
see
if
they've,
if
Cameron
has
updated
the
has
updated
their
image
for
us
good
question.
B
B
A
I've
got
that
thanks
very
much
Bruno
thanks
Mark
next
up
so
cvcon
is
approaching,
it's
gonna
be
May,
8th
and
9th.
That's
where
the
Jenkins
Awards
will
be
provided
to
the
winners
and
among
the
other
CDF
awards
that
will
be
presented
there.
So
if
you
haven't
already
signed
up
or
registered,
there's
I
think
there's
still
time
to
do
so
and
get
over
there.
So
if
you're
going
to
be
there
come
by
stop,
say:
hey
Mark's
going
to
be
there.
A
As
he
said,
Alex
Brandeis
will
be
there.
Gavin
Mogan
will
be
close
enough
that
he
might
show
up,
but
otherwise
we'll
people
will
be
there
to
represent
Jenkins
and
share
and
talk
so
by
all
means.
Come
on
over
there's
also
going
to
be
a
handful
of
sessions
regarding
cdci
and
Jenkins.
A
So
we
have
a
recent
blog
post
that
just
outlines
a
couple
of
those
providing
some
information,
so
one
from
Fidelity
one
from
one
regarding
Jenkins
and
other
releases,
so
there
and
Mark
getting
well
Mark's
going
to
be
participating
in
two
sessions,
so
really
exciting.
To
have
that.
So
thank
you.
Mark
for
representing.
A
Next
up
so
right
now,
we've
been
talking
and
discussing
the
transition
for
the
documentation
to
move
from
java
11
to
Java
17
for
things
like
installation
instructions
and
other
Hardware
software
requirements.
A
We're
not
dropping
Java
11
we're
just
transitioning
to
Java
17..
It's
got
a
longer
life
right
now.
It
has
more
functionality,
faster
testing
and
just
provides
overall,
better
development
resources
for
anyone
using
it.
So
I've
created
a
GitHub
issue.
That
is,
that
contains
the
various
pages
that
I
found
where
this
transition
should
be
looked
at
and
potentially
happen.
A
A
But
this
is
a
result
of
the
Debian
12
release.
That's
approaching
I'm,
not
sure
exactly
when
that
will
happen,
but
it
will
not
be
delivered
with
Java
jdk
11..
So
this
is
in
advance
of
having
to
worry
about
that
across
the
board.
We
can
get
ahead
of
it
and
we
can
start
using
17
as
a
recommended
option.
Hopefully,
get
people
to
migrate
over
sooner
than
later,
and
that
way
I
have
less
to
worry
about
when
it
does
come
time
for
end
of
life
for
Java
11.
A
we're
not
dropping
Java
11
support
at
all.
It's
Java
17
is
also
available
for
functionality,
and
we
want
to
get
people
on
that.
A
So
and
more
to
come
on
that,
once
we
once
I
start
getting
into
the
transition,
we'll
provide
more
updates
here.
A
One
of
the
other
things
that
I
wanted
to
note
is
that
we
recently
had
the
success
stories
and
the
stories
site
as
a
navigation
link
now
in
the
nav
in
the
top
nav
bar
here
on
jenkins.io.
So
thanks
to
Gavin,
Mogan
and
Alex
brandes
for
getting
that
set
up
and
working.
So
now
we
have
this
really
nice
success
stories,
Link
at
the
top
of
every
Jenkins
page,
so
that
the
stories
page
is
highlighted
and
available.
B
A
Yeah
and
I
think
I
think
if
anything,
it
just
needs
to
be
updated
to
have
like
a
maybe
a
link
to
the
correct
repository
to
submit
the
pull
request.
So
I
can
take
care
of
that
no
problem
well.
B
A
Cool
I'll
go
ahead
and
I'll
submit
a
pull
request
for
that
after
our
office
hours
is
over.
A
Great
next
thing
on
the
agenda
that
I
wanted
to
bring
to
everyone's
attention
is
that
there
was
a
recent
update
for
how
XML
is
handled
in
Jenkins,
specifically
with
the
use
of
the
junit
plugin.
So
as
it
was
before,
ASCII
no
characters
could
be
both
written
and
read
fully
without
any
issue.
The
recent
change
from
the
kxml2
driver
to
standard
sax
driver
has
made
it
so
that,
while
the
no
can
be
written,
it
cannot
be
read.
A
So
if
this
is
something
that
you
run
into
or
are
experiencing,
you
do
need
to
update
to
the
newest
version
of
the
j
in
it
plugin.
It
was
just
push
a
couple
days
ago
or
in
within
the
last
week
regardless.
So
this
is
a
very,
very
recent
change.
It's
going
to
be
part
of
weeklies
going
forward.
It
did
not
make
it
into
the
2.387.3
LTS,
so
it
will
not
be
part
of
that,
but
this
will
be
in
effect
going
forward.
So
it
is
best
to
update
everything
now
and
take
care
of
it.
B
So
there
are
just
so
everybody's
clear
null
is
illegal
in
XML
1.1
as
a
data
value,
it's
simply
illegal.
So
we
were
writing
illegal
data
and
reading
illegal
data,
and
now
we've
we've
switched
with
the
the
up
upgrade
of
this
reader
so
that
we
will
we
will.
We
now
have
the
ability
to
write
but
not
read,
and
now
it's
with
the
change
to
the
junit
plug-in,
which
was
the
one
thing
we
knew
of
that
was
writing
null
bytes.
It
no
longer
writes
nulls.
C
B
A
Thank
you
Mark
for
adding
the
context
there,
and
there
are
actually
both
a
GitHub
issue
and
jira
issue,
for
this
so
I'll
be
sure
to
add
those
into
the
document
agenda,
just
to
make
sure
that
those
are
available
for
for
contacts
and
historical
purposes.
A
Next
Step,
so
we
have
five
minutes
or
so
left.
I
want
to
be
conscious
of
everyone's
time,
so
we've
been
discussing
alternate
ways
to
handle
stale
documentation,
pull
requests
in
jenkins.io,
so
we've
been
discussing
if
it's
stale
and
not
valuable,
we
close
it.
If
it
is
valuable,
however,
we
want
to
make
sure
that
that
information
and
network
is
not
lost
so
alternative
ways
to
make
sure
that
that
gets
kept
as
it
is
and
can
get
additional
eyes
on
it,
for
anyone
that
might
want
to
work
on
it
or
continue.
A
Adding
and
fixing
and
updating
some
of
the
some
of
the
pull
requests
require
a
little
bit
more
knowledge
and
more
expertise
in
some
areas.
A
So
it
may
be
tough,
but
there's
a
great
base
to
work
from
in
all
of
these
and
Meg
white
zone
or
no
sorry,
I
can't
remember
Meg's
last
name
right
now
make
McRoberts
Nick
Roberts
yeah
has
done
an
excellent
job
and
there's
a
bunch
of
pull
requests
that
update
a
lot
of
the
documentation
that
just
have
got
installed
because
they
need
some
further
additions,
Corrections
updates
and
stuff.
A
So,
there's
a
lot
of
great
stuff
there
that
we
can
just
take
on
and
work
from,
so
we
do
have
a
stalled
label
that
have
been
that
has
been
applied
to
these
pull
requests
as
well.
So
for
anything
older,
it's
Mark
stalled.
We
have
that
we're
just
waiting
to
do
the
next
step
of
what
do
we
do
with
that?
A
Putting
it
installed
is
good
for
now,
but
ultimately
we're
going
to
need
to
make
sure
that
it's
available
for
other
people
and
if
it's
a
good
first
issue,
we
can
do
that
if
we
put
it
in
the
issue
tracker
that
at
least
opens
it
up
for
other
people
to
work
on.
There's
a
lot
of
ways
to
go
about
that.
A
Something
that
we
also
talked
about
with
Alex
brandes
is
that
the
Jenkins
core
repository
has
a
proposed
for
closed
label.
So
that's
used
for
public
Quest,
they
won't
accept
or
they
have
an
inactive
submitter
that
are
not
responding
or
updating.
So
again,
something
similar.
We
could
use
that.
We
could
Implement
and
use
that
in
jenkins.io
repository
no
problem,
and
it
would
give
us
something
else
to
at
least
signify
and
notice
on
the
pull
request.
Page
Bruno
Mark.
A
Are
there
any
other
ideas
or
suggestions
about
how
we
could
potentially
preserve
those
a
little
bit
and
make
them
more.
A
C
The
only
problem
I
see
with
that
is
that
if
ever
a
submitter
of
a
pull
request
remove
the
brand
from
his
Fork,
we
will
lose
the
information.
Nonetheless,
if
I'm
not
mistaken,
you
know,
if
you
create
a
PR,
then
you
remove
your
branch.
The
information
you
wanted
to
incorporate
into
the
main
branch
just
disappears.
B
I
thought
that
it
was,
it
was
retained
in
the
pull
request.
I
may
be
wrong.
I
I
thought
it
was
so,
but
nonetheless,
because
I,
if
I
re
recall
correctly,
even
if
I
believe
it
survives,
even
if
they
delete
their
fork.
Okay,.
A
Great
thanks
appreciate
that
and
thought
of
that
next
up
so
end
of
life
notifications
in
Jenkins
core.
This
is
something
that
we
had
been
discussing.
The
idea
is
that
it
can
be
delivered
via
the
administrative,
monitor
or
administrative
monitor
and
right
now,
it's
designed
as
a
general
solution
to
communicate
end
of
life
dates.
A
There
are
going
to
be
factors
attributes
that
we
want
to
account
for
and
look
at
to
use
for
when
this
message
can
be
sent
out,
who
it's
going
to
be
sent
out
to
what
that
end
of
life
version
is
et
cetera,
Etc.
So,
as
I
mentioned,
Marksman
getting
more
and
more
insight
and
feedback
on
this
and
various
things
that
we
can
use
as
criteria
the
most
recent
one
is
the
start
date
for
end-of-life
messages,
which
essentially
would
just
be.
A
When
do
we
want
to
start
sending
these
out
to
people
and
not
right
now,
but
you
know
in
a
specific,
like
a
given
time
frame
six
months
before
the
end
of
life,
so
that
there's
ample
time
to
see
that
notification
and
actually
act
on
it.
Instead
of
having
it
be
so
sudden
that,
if
there's
no
time
or
too
far
away
that
it
gets
lost.
A
And
this
also
will
allow
us
to
end-of-life
container
images.
So
in
not
only
just
the
platform
systems
versions
that
people
are
working
on,
but
full
container
images
as
well,
so
that
we
just
clean
things
up
to
keep
things.
Nice
and
streamlined.
And
people
are
using
the
the
up-to-date
versions
of
Jenkins
and
anything
else
that
we're
working
with.
A
A
It's
been
it's
approaching
sooner
than
later,
it's
no
longer
being
supported
by
the
developer
and
we
do
have
alternate
options
available
and
even
listed
in
the
documentation
such
as
Alma
Linux,
809,
Rocky,
Linux,
Rel,
Oracle
Linux,
and
there
are
others.
So
there
is,
is
the
more
I
come
on
that,
but
the
work
is
being
done
and
we're
getting
everything
ready
to
go
for
that
so,
okay,
so
that
brings
us
to
the
end
of
our
session.
Did
anyone
have
anything
else?
To
add
note
comment
share.
A
All
right,
in
that
case,
I'm
going
to
go
ahead
and
stop
the
recording.
In
just
a
moment,
recording
will
be
available
in
24
to
48
hours
and
thanks
again,
as
always
for
joining
here
today.
Take
care.