►
From YouTube: 2022 01 14 Platform SIG
Description
Jenkins platform special interest group with discussions of Java 8 end of life alternatives and the proposed change to the exit lifecycle for Docker images.
A
Welcome
to
document
to
platform
special
interest
group,
it's
the
14th
of
january
2022.,
topics
on
the
agenda
for
today,
open
action,
items
java,
end
of
eight
end
of
life,
alternatives,
linux,
operating
system,
support
policy.
Other
topics
may
wait
for
another
time,
jim
anything
else.
You
want
to
add
nope,
okay,
so
action
items
I
have
opened
the
pr
for
to
describe
operating
systems.
We
test
the
jet
operating
the
jet
for
docker
operating
system.
A
A
B
It's
for
me,
it's
mostly
just
deciding
when
kind
of
seemed
to
just
be
doing
nothing
at
the
moment
and
not
a
lot
of
feedback
in
the
mailing
list.
Recently.
B
Right
we
can
get,
we
can
get
a
date
into
an
lts
line
and
set
different
set,
different
dates
for
lts
and
weekly,
but
we
just
need
to
decide
when.
A
Yeah
so,
and
for
me
the
challenge
right
now
is:
I'm
I'm
doing
some
discussions
at
my
employer
about
what
this
means
and
how
the
jenkins
and
transfer
proposal
needs
to
be
phrased,
etc.
So
I
expect
to
heat
this
thing
up
and
start
the
conversations
pretty
actively
again
within
the
next
five
to
seven
working
days,
because
I
think
we've
got
to
get
started
on
it.
I
agree
that
we
need
a.
We
need
a
date
and
we
need
a
plan
that
supports
that
date
and
justifies
it.
B
C
A
Exactly
so
so,
if,
if
we
need
to,
if
we
need
to,
I
like
that
point,
if
we
need
to
slip
the
date
or
adjust
the
date,
that's
safer
than
not
having
the
conversation.
B
B
A
B
B
It
will
be
kept
up
with
protocols
and
critical
issues
and
new,
possibly
minor
things
to
support
new
tooling.
But
it's
it's
support
is
secure,
like
security
fixes,
it's
not
support,
isn't
tls
1.3
or
whatever
right,
http,
3
or
or
a
modern,
http,
client
or.
A
Yes,
yeah
of
all
valid
points
or
or
in
many
cases,
some
that
matter
to
me
are
things
like
hey.
I
think
that
the
java
11
support
for
some
of
the
alternate
architectures
is
just
better
right.
As
the
specific
example
for
me,
assistant
390
doesn't
run
the
java
hotspot
at
all.
It
just
doesn't
for
java
8.,
you
got
to
go
to
java
11,
and
so
it
makes
sense
that,
or
or
the
arm
support,
I
think,
is
even
better
in
java
11
than
java
8
and
that's
important
to
a
lot
of
people.
A
So
so
a
wholehearted
agreement
that
we
need
this
thing
and
let's,
let's
accept
that
where
there
may
be
some
controversy
as
we
discuss
it
and
negotiate
back
and
forth
jep
jep
creation
process
is
a
bit
rigorous.
For
me,
it's
a
it's
it's
hard
to
do.
I
have
to
work
hard
to
write
it
well,
but
let's
set
a
goal
that
for
next
the
next
session
of
this
meeting,
which
would
be
in
two
weeks
we've
already
it's
already
in
a
proposal
available
for
next
sig
meeting
as
a
pull
request.
A
B
Yeah
I
mean
for
me
expect
the
main
thing
is
just
documentation
around
things
like
maven
builds
stuff,
that's
been
done
before,
like
realistically
for
90.
I
would
expect
90
plus
percent
of
people
java
11
shouldn't
affect
them
at
all,
if
not
in
the
high
90s,
all
the
core
plugins
work
on
it
and
then
it's
just
whether
you're
building
on
controllers
and
how
you're
building,
but
if
you're
doing
it
properly,
it
shouldn't
really
affect
you.
A
Right
and-
and
I
think,
you're
right
that
the
the
major
portion
of
people
are
not,
and
even
okay,
let's,
let's
take
the
the
example,
we
had
a
discussion
on
the
hpe
tandem
non-stop
stuff
and
the
answer.
There
is
sorry,
some
platforms
may
not
be
supported.
We
just
we
can't
hold
ourselves
back,
because
there
are
platform
vendors
that
don't
want
to
do
java
11.,
that's
that's
just
not
not
relevant
to
us.
We've
got
to
be
allowed
to
move
forward
onto
java
11.
java
17.
B
Yeah
like
realistically
at
this
point
java
17
is
really
the
target
right
and
it's
just
yeah
about
getting
getting
there,
but
java
11
as
well
battle
tested
like
yeah,
we're
moving
to
java
17
now
at
work.
A
A
A
It
has
to
be
approved
by
the
board,
needs
developer
list
discussion.
First,
the
idea
was
amd
64,
as
on
rpm
deb
and
and
for
specific
platforms.
A
A
A
A
A
B
A
Yeah,
the
the
whole
pair
programming
miracle
of
oh
wow-
you
did
that
that's
yeah
I've
learned
more
things
by
watching
over
people's
people's
shoulders
than
any
other
form
of
learning.
I
think
all
right,
so
operating
system
support
policy.
I
assume
that
there's
at
least
a
week
or
two
of
discussion
around
that
before
it'll
be
finalized,
finalization
will
require
going
to
a
governance
board
meeting
and
that's
at
least
two
weeks
away.
I.
A
A
All
right,
so
any
other
topics
you
want.
So
there's
this
system,
five
to
system
d
transition
thing.
That's
that's
started.
That
leaves
me
quite
nervous,
but
I
think
we
eventually
need
to
do
it.
Just
like
we're
transitioning
off
java
11,
I'm
just
nervous
because
of
the
compatibility
risks
that
are
hiding
in
that
thing.
A
B
A
B
A
B
A
C
A
Right
right,
right,
there's
there's
a
moral
in
that
story,
but
that's
a
different
problem
right.
It's
that,
oh,
oh!
Actually,
I
take
it
back.
I've
got
another
topic
for
you:
the
exit
life
cycle
that
that
exit
life
cycle
is
an
interesting
one.
I
assume
we'll
just
continue
the
discussions
in
the
pull
request,
because
I
think
I
think
basel
is
right
that
we
should
we
should
implement
the
exit
life
cycle
change
he
proposed,
but
we've
got
to
worry
about
compatibility.
A
B
Yeah,
if
you
want
to
write
one
welcome
to
yeah,
but
I
think
so
I
recreated
the
pr
and
I
think
it
just
needs
an
update
to
the
readme
really
to
change
to
add
the
on
restart
policies
to
all
the
docker
run.
Commands.
A
In
the
online
docs,
readme,
etc,
because
there
there
are
docker,
run
commands
and
some
tutorials
and
and
those
would
be
good
places
to
remind
people.
Look
at
this
argument.
You
need
it.
B
B
Only
if
you're
upgrading,
okay,
all
right
good,
I
wouldn't
expect
you
to
really
hit
it
so
much.
Okay.
The
other
annoying
thing
I
noticed
today
is
that
the
the
github
action
that
updates
the
plug-in
manager
cli
and
the
docker
repo
is
a
bit
liberal
on
one
of
the
updates
and
there
happens
to
be
a
subversion
plug-in
with
the
same
version
as
the
docker
plug-in,
cli
and
and
the
action
runs
every
15
minutes.
B
Kind
of
good,
because
you
don't
know
where
it's
going
to
appear
but
also
and
when
it
appears
somewhere
else.
So
if
I
remember,
I
will
probably
just
create
a
new
branch-
that's
not
great,
but
yeah.
That's
that
was
annoying
me
this
morning,
when
I
like
and
downgraded
it,
and
then
it
just
upgraded
itself
before
the
build
finished.
B
I
found
a
really
cool
feature
in
gradle
with
gradle
there's
a
thing
called
java
or
tool
chains
and
gradle.
B
So
what
we've?
What
I've
done
on
the
ci?
Is:
I've
installed,
java,
11
and
java
17
from
the
package
manager
and
set
the
default
to
java
11
and
then
in
the
gradle
file.
You
just
set
the
tool
chain
for
the
build
to
be
17
and
the
and
gradle
runs
with
11
but
actually
builds
with
17,
and
it
works
completely
out
of
the
box.
You
know
to
change
any
home
you
have
to
you,
don't
have
to
do
any
detecting
of
features
or
anything
it
just
just
works.
B
So
last
time
we
used
so
last
time
when
we
upgraded
8
to
11,
we
ran
a
version
to
pass
from
gradle
what
they,
what
people
have
declared
in
the
gradle
file
to
be
their
version,
and
then
we
set
up
the
path
based
on
the
output
of
that,
but
this
time
gradle
has
it
completely
built
in
then
it
just
works.
Fine,
nice
very.
A
B
Yeah
sorry
much
simpler,
also
last
time
when,
when,
if
like,
when
we
were
passing
the
version
out
via
gradle,
if
it
died
because
like
a
plugin,
couldn't
download
or
lose
a
network
issue
or
something
it
said
it
couldn't,
it
failed
with
an
error
saying,
couldn't
detect
java
version.
We've
got
weird
questions
about
it
and
then,
if
you
read
up,
it
turned
out
that
oh,
a
plugin
failed
to
download
it's
completely
unrelated,
so
very
happy
not
to
have
to
pause
to
do
that.
This
time.