►
From YouTube: Jenkins Governance Meeting September 18, 2023
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
Oh
welcome
everyone.
This
is
Jenkins
governance
meeting,
it's
the
18th
of
September
2023..
We've
got
several
topics
on
the
agenda,
including
upcoming
calendar
news,
action
items,
governance
topics,
Julia
on
governance,
topics,
I
put
board
and
officer
elections
there.
To
give
you
a
moment
just
to
describe
where
we're
at.
Are
you?
Okay
with
that?
As
a
topic?
Yes,.
A
A
Okay,
then,
let's
go
ahead
so
in
terms
of
upcoming
calendar
Wednesday
will
be
the
next
long-term
support
release
2.414.2.
It
will
also
be
a
security
advisory.
The
security
team
has
announced
that
414.2
will
include
a
changes
to
core
to
improve
security.
By
way
of
note,
that
means
there
won't
be
a
weekly
release.
Tomorrow,
the
weekly
release
will
be
delayed
and
delivered
the
same
day
as
2.414.2.
It
will
be
2.424
424
and
will
be
a
security
increment
on
top
of
2.423.
A
Okay!
Next
major
event
is
the
ongoing
Jenkins
officer
and
Board
elections.
Nominations
open
today
and
close
at
the
near
the
end
of
October.
Voter
registration
also
opens
today
and
closes
November
5.
and
voting
will
happen.
November
6th
through
December
1..
Any
questions
on
the
officer
and
Board
elections.
A
A
We've
got
a
fips
140,
Jenkins
enhancement
proposal.
That's
been
proposed
by
James
Nord
phipps-140
is
a
U.S
federal
government
standard
for
cryptography
use
and
software,
and
it's
commonly
required
by
by
large
government
and
contractors,
U.S
government
and
contractors
associated
with
it.
So
James
has
described
it
there.
Java
21
release
is
coming
this
week.
We
are
one
day
away
from
their
scheduled
release
date
thanks
to
Basel
and
to
others
for
the
work
there
for
the
to
the
infra
team.
C
Do
we
want
to
do
any
communication
about
this
because
I'd
be
willing
to
write
some
kind
of
external
communication
such
as
a
blog
post,
but
the
one
thing
that
I
fear
is
that
we
might
be
overloading
people
with
too
much
communication.
C
So
maybe,
if
we're
planning
to
announce
some
other
Java
related
changes
such
as
deprecating
support
for
Java
11
in
later
in
October
or
or
something
like
that,
maybe
it
would
be
better
to
combine
all
of
those
those
version
related
announcements
into
one
blog
post
or
one
piece
of
communication
rather
than
making
people
read.
You
know
multiple
things
every
couple
of
of
weeks
that
are
saying
something
very
similar.
A
Good
question:
I'm
I'm
open
to
guidance
from
others
on
that
one
because
for
me
it's
a
a
larger
announcement
is
there's
some
power
to
a
larger
announcement,
but
the
larger
announcement
would
then
be
delayed
right,
whereas
they
could
start
potentially
sooner
Uli.
You
have
any
any
insights
there
that
you
would
like
to
offer
in
terms
of
should
we
should
we
talk
about
it
sooner
or
later.
B
A
So
consider
a
summary
blog
post
with
the
Java
11
end
of
life,
Java
21
support
and
Java
17,
Etc,
so
dot,
dot,
I
think
that's
what
you
were
saying
really
is
that
would
be
okay
for
you
and
I
think
that's
what
Basel
was
proposing.
Yes,.
A
A
The
next
item
of
news
is
that
the
Google
summer
of
code
projects
for
2023
are
going
well.
Two
of
them
have
already
completed
successfully.
The
work
is
the
work
is
not
Final
in
terms
of
getting
it
all
the
way
to
end
users,
but
the
project
itself
was
it
was
concluded
successfully
and
ready
for
more
work
to
be
done.
That's
git
lab
plugin,
modernization
and
Docker
compose
for
tutorials,
two
additional
plug-in
two
additional
projects
were
chosen
to
be
extended
and
the
extensions
are
have
been
ongoing.
A
One
of
them
will
complete
within
the
next
week
or
so,
and
the
other
one
I
believe
has
two
or
three
more
weeks.
They're,
all
looking
good
to
pass
and
looking
forward
to
their
results.
Presentations
were
shared
last
Thursday
thanks
very
much
to
those
presenters
and
to
everyone.
Who's
acted
as
mentors.
A
A
This
next
action
item
I
had
actually
completed
it
and
the
other
action
items
retrospective
submit
the
Jenkins
iopole
request
for
Sub
sub
projects
retire
the
Chinese
those
two
I've
not
completed
so,
and
it
will
be
several
weeks
before
I
make
any
progress.
Sorry,
Kevin
anything
you
want
to
report
on
the
retiring,
the
Jenkins,
the
Chinese,
Jenkins,
documentation,
site.
A
Okay,
so
we'll
we'll
do
some
more
work
separately
on
that
and
I've
still
got
the
open
task
to
draft
a
licensed
license
policy
change
to
the
board.
It's
we've
got
some
licenses
that
are
currently
used
in
the
Jenkins
project,
like
the
Json
license
that
are
not
OSI
approved,
but
our
documentation
says
we
only
use
OSI
approved
licenses,
so
we
need
to.
We
need
to
come
to
a
conclusion
on
that
all
draft,
a
proposal
and
send
it
around
any
questions
on
the
action
items.
A
It
my
my
Approach
is
leaning
strongly
towards
just
allow
the
license
and-
and
there
are
several
like
it
right-
where
I
think
the
risk,
the
legal
risk
and
the
project
risk
is
very
low
of
accepting
that
specific
license.
And
so,
but
it's
got
to
be
discussed
with
the
board
and
thankfully,
the
Linux
Foundation
provides
access
to
attorneys
that
can
help
with
identifying
the
real
threats
in
the
legal
sense.
So
we'll
use
useless.
A
C
A
C
There's
any
precedent
from
like
others,
other
projects
that
have
a
distribution
mechanism,
like
maybe
the
python
package
index,
or
something
like
that
where,
where
they
I
wonder,
if
they
have
a
similar
I,
just
wonder
if
there's
any
precedent
in
other
open
source
communities
or
if
we're
making
this
decision
for
the
first
time.
Let's.
A
A
C
Yeah
I
wasn't
I,
wasn't
I,
wasn't
saying
that
anyone
needs
to
go.
Do
any
work
here.
I
was
just
curious.
I
was
just
thinking
out
loud
and
I'm
happy
to
go.
Look
into
this.
A
B
Yes,
I
can
do
it,
so
my
part
was
very,
very
small,
because
I
was
in
politics
for
a
couple
of
weeks,
so
everything
is
has
been
set
up
by
Alexander,
so
he
started
a
lot
of
blog
posts.
The
community
post.
He
created
a
document
where
the
process
is
maybe
I
can
posted
in
the
chat.
The
link
where
the
most
recent
blog
post
is
so
we
can
put
it
in
the
document
here
as
well.
So
basically,
we
start
now
with
the
registration
of
the
candidates
and
the
voters.
So
we
start
in
parallel.
B
B
I'll
have
a
meeting
with
Alexander
tomorrow
on
how
we
can
split
the
work,
so
we
will
see
who
is
making
which
thing
so
the
good
thing
is.
We
have
a
good
document
where
the
process
is
documentated
documented,
so
I
can
have
a
look
and
see
what
steps
are
to
do.
A
Yeah,
thank
you
very
much.
So
we've
the
announcements
are
out
and
we've
already
got
some
people
who
have
joined
the
the
voter
group.
We
just
need
to
now
be
sure
we
promote
it
actively,
encourage
people
to
register.
We've
got
hundreds
of
Jenkins
developers
that
are
contributing.
It
would
be
great
to
have
them
also
be
voters.
A
A
Yeah,
okay,
so
so
the
notion
with
the
diagram
is
that
each
of
the
horizontal
bars
on
this
picture
is
a
period
of
life
for
a
Java
release.
So
first
bar
is
first
row
is
Java
11..
The
second
row
is
Java
17,
then
Java
21,
and
what
we're
trying
to
do
is
reach
a
point
where
we
have
a
2
plus
2
plus
2
support
model
where,
for
the
first
two
years
of
a
new
Java
release,
Jenkins
supports
it
but
does
not
require
it
as
the
minimum
version
for
the
second
two
years.
A
Jenkins
requires
it
as
the
minimum
version,
and
then
it
supports
the
next
version,
and
for
the
last
two
years
we
actually
drop
support
for
that
oldest
Java
version,
so
that
with
a
six
year,
life
cycle
for
a
Java
release
the
first
four
years.
We
support
it
either
as
allowed
or
as
required
minimum
version,
and
then
for
the
last
two
years
we
drop
it
off
the
list
so
that
we're
only
supporting
two
Java
versions
at
a
time.
A
In
most
cases
now
I
like
basel's
point
he
and
I
were
discussing
this,
and
he
noted
this
is
somewhat
of
a
platonic
ideal.
In
that
it
is
a
hoped,
but
not
a
guarantee,
that
there
will
never
be
times
when
we
don't
support
three
Java
versions.
There
will
be
transition
periods.
There
will
be
Cycles
like
that.
A
A
Super
so
I
will
plan
to
send
within
the
next
few
days
a
mail
message
to
the
developer
list
and
to
the
user
list
discussing
this
we
know
there's
a
transition
period
and
that
transition
period
will
put
us
into
some
sort
of
bumps
along
the
way
right,
instead
of
supporting
Java
17
as
minimum
version
for
two
years,
we'll
only
support
it
for
a
year,
Java
21
will
be
the
required
minimum
version
only
for
18
months
and
then
by
Java
25,
we're.
Finally,
on
the
real
two
plus
two
plus
two
model.
A
B
A
Yeah
and
and
I
think
I
think
that's
a
good
reason
why
the
Java
21
announcement
blog
that
that
Basel
referenced
earlier.
It
would
be
good
for
us
to
to
combine
that
with
others.
Do
it
in
early
October
after
we've
had
a
chance
to
be
sure
that
things
are
aligned
with
this,
and
we
can
even
consider
including
this
in
that
larger
picture,
blog
post.
C
So
I've
seen
I've
seen
a
bunch
of
versions
of
this,
but
one
of
them
that
one
version
of
this
chart
that
I've
seen
had
the
administrative
monitor
with
a
different
color
and
that
that
kind
of
goes
along
with
your
point
that
you
just
made
now
about
how
we
won't
be
ready
to
ship
a
new
Java
version
as
the
default
container
version
for
all
users.
C
You
know
right
at
the
beginning
of
this,
of
One
of
These
Bars,
there's
like
a
there's,
basically
a
period
of
early
adopters
and
then
a
period
of
you
know,
mainstream
adoption
and
then
finally,
a
period
of
getting
the
stragglers
on
board
before
we
finally
drop
support
for
it
completely
and
I.
C
Guess
in
in
this
in
this
chart
that
all
three
of
those
periods
are
covered
by
the
yellow
portion,
but
but
within
that
yellow
portion,
there's
there's
a
number
of
different
phases
of
adoption
and,
and
part
of
that
includes
becoming
the
default
in
a
new
container
image,
which
we
would
want
that
to
happen
rather
early
in
order
to
accelerate
the
adoption
process.
But
we
wouldn't
want
it
to
happen.
C
You
know,
on
the
very
first
day
until
the
early
adopters
have
had
a
chance
to
kick
the
tires,
and
similarly
we,
you
know,
we
want
to
put
the
administrative
monitor
in
place
toward
the
end
of
the
yellow
bar
to
warn
people
that
that
they're
coming
close
to
the
deadline
of
of
having
to
migrate.
A
I
I
do
good
point
and
I
had
I
had
pulled
the
administrative
monitor
out,
because
I
got
some
feedback
that
people
were
not
clear
when
I
put
a
new
color
in
there.
What
does
what's
the
meaning
of
that
color
Mark?
What
were
you
so
so
you're
right
and
in
fact
you
can
see
the
sneaky
thing
here-
is
here's
the
color
that
I
had
I
hit
it
because
it
was,
it
was
causing
confusion
for
some
of
the
readers
with
with
the
the
but
you're
right
there
is.
A
There
is
a
there
is
there
is
more
subtlety
than
is
covered,
and
maybe
it's
that
one
of
these
bars
needs
to
be
expanded
in
a
separate
visual
which
is-
and
this
is
how
it
will
look
for
this
transition,
because
you're
right,
it's
not
immediately
clear
that
there's
a
there's
a
whole
range
of
actions
in
this
first
two
year
period,
And
even
before
it
that
are
happening.
Yeah
yeah.
C
You
could
express
that
by
zooming
in
to
the
yellow
portion
in
a
different
in
the
different
Visual
and
then
saying
like
yeah,
but
before
before
the
beginning
of
that
there's
the
prep
Preparatory
work
like
what
we've
been
doing
in
the
last
month
and
then
once
Upstream
has
released
the
new
Java
version,
then
there's
a
whole
range
of
activities,
ranging
from
an
announcement
that
is
supported
all
the
way
to
making
it
the
default
in
the
container
image
and
the
default
in
the
new
setup
instructions
all
the
way
to
eventually
removing
it
through
an
administrative
Monitor
and
then
ultimately,
a
compilation
error.
C
Once
we
require
the
next
version
afterwards,
but
yeah,
that's
that's
a
very
wide
range
of
activities
within
that
yellow,
bar
and
I.
You
know
I
think
we
want
to
roughly
distribute
them
proportionally.
I
mean
you
know
within
there's
no
hard
and
fast
rules,
but
we
usually
in
the
past
we've
given
early
adopters,
seven
amount
of
time.
C
You
know
I
think
with
Java
17
we've,
maybe
given
them
too
much
time.
Just
because
we
haven't
been
paying
attention
but
but
yeah
I
mean
at
the
very
beginning.
We
don't
want
to
be
too
aggressive
about
forcing
something
onto
all
users
before
the
early
adopters
have
had
a
chance
to
kick
the
tires
that
we
have
gotten
a
lot
better
with
automated
testing.
C
So
we
should
be
more
and
more
confident
about
when
I
started
working
on
this
there
was
more
or
less
no
automated
testing
for
new
Java
versions,
and
now
we
could
say
with
a
lot
more
confidence
that
we're
running
ath
and
PCT,
and
all
these
things
so
but
yeah
I
still
think
we
should
have
some
amount
of
time
for
the
early
adopters.
We
don't
want
to
lose,
lose
the
confidence
of
our
users
by
forcing
something
that
was
literally
just
released.
You
know
on
Tuesday
this
week
as
the
default
in
every
container
image
right.
A
C
Yeah
and
the
comment
might
be
that
that's
a
lot
of
work
and
it
is
but
the
more
the
more
formal
we
get
at
or
the
more
we
formally
describe
that
and
and
institutionalize
it
as
a
process,
the
better
we'll
get
at
it
and
the
more
automation
that
we'll
develop
so
that
eventually
this
can
happen
like
clockwork
right,
good.
A
All
right,
so,
let's
continue
then
next
topic
was
oh
I
guess
there
are
some
key
dates
upcoming
that
really
just
be
aware
that
Java
11
end
of
life
for
the
Java
projects
themselves
is
October
of
2024.,
so
Jenkins
will
not
support
it,
Beyond
its
end
of
life
in
from
open
jdk
so
and
from
Tamarind.
So
it's
it's
really
we
see
it
coming
next
is
that
the
artifactory
bandwidth
reduction,
prog
project
has
made
very
good
progress
and
is
implemented.
We've
still
got
some
remaining
tasks
that
we're
working.
A
We've
announced
the
the
change
in
a
blog
post
and
really
pleased
with
it,
but
we've
got
one
or
two
more
things
still
that
have
to
be
resolved
they're,
not
as
far
as
we
can
tell
affecting
plug-in
developers
and
they're,
certainly
not
affecting
users,
but
we'll
keep
working.
Those
any
questions
there.
A
Okay,
next
piece
is
prototype.js
and
this
one,
so
it
all
started
with
a
blog
post
back
in
May,
from
Basel
right
thanks
to
buzzle
and
to
Tim
Jacob
for
their
work
on
it.
We're
now
September
approaching
the
October
October
3
day
when
this
10
plus
year
old
JavaScript
will
be
removed
from
Jenkins
thanks
very
much
to
everybody,
who's
made
so
much
so
much
progress
on
it.
We've
got
some
lurking
plug-ins
that
still
would
benefit
by
having
the
change
made.
A
Part
of
jfrog
has
committed
that
they'll
work
on
theirs
in
September
fortify
from
microphos,
because
likewise
and
I
actually
had
contact
with
trisentis
at
devops
world.
So
three
of
the
five
there's
been
at
least
some
contact
and
some
hope
any
questions
on
the
removal
of
prototype.js.
A
That's
that's
a
that's
a
weekly
release
that
is
one
of
the
last
weeklies
before
we
choose
an
LTS
Baseline,
so
it's
intentionally
selected,
it's
malicious,
is
probably
the
wrong
way
to
say
it
is
intentionally
selected
to
allow
us
to
get
it
into
the
November
15
long-term
support
release,
that's
good
so
that
that
was
the
intent
in
choosing
October
3.
C
Yeah
I
haven't
I,
haven't
heard
any
anyone
saying
that
they
need
more
time
or
want
more
time.
So
this
still
feels
like
a
good
date
to
me.
Yeah.
A
All
right
next
topic
and
last
one
was
hacktoberfest
preparation,
so
beginning
October,
one
digitalocean
and
others
sponsor
a
month-long
event
called
Oktoberfest
Jenkins
has
participated
in
it
for
years.
John
Mark
Mason
has
sent
a
message
to
the
developer
list
and
we've
got
a
series
of
issues
identified
that
new
contributors
can
help
we're
we're
hopeful
for
this.
We,
it
will
be
a
different
event
this
year
than
last
year,
because
digitalocean
made
I
think
a
very
wise
choice.
A
A
Certainly
I
think
we
would
benefit
by
more
issues,
or
even
more
importantly,
maybe
Uli
to
you
specifically.
We've
got
a
list
of
good
first
issues
that
are
in
the
jira
system,
but
most
of
them
were
identified
12
months
or
more
ago,
and
therefore
they've.
Some
of
them
have
aged
and
they're
no
longer
a
useful
issue
and
we
need
to
either
close
them
or
get
them
out
of
the
list.
I
did
a
sweep
through
many
of
the
others,
but
I
didn't
touch
warnings,
NG
or
analysis
figured.
A
You
could
do
that
and
those
getting
those
lists
so
that
a
new
contributor,
when
they
pick
up
a
an
issue,
we
believe
it's
got
reasonable
chance
that
they
can
fix
it.
Some
of
the
ones
that
I
removed
were
I,
looked
at
it
and
realized,
there's
no
maintainer
for
this
plug-in.
There
is
no
way
if
you
pick
this
up,
you're
going
to
have
a
good
experience,
submitting
a
fix
for
it.
A
B
A
C
If
we're
done
with
hacktoberfest
I
just
wanted
to
share
that,
while
this
meeting
has
been
going
on,
I've
been
Googling,
the
python
package
Index
this
policy
on
licenses-
and
it
seems
like
they've,
mostly
focused
on
OSI
approved
licenses,
but
also
allow
non-osi
approved
licenses,
include
include
they
have
a
separate
category
for
public
domain
and
as
well
as
a
few
other
non-osi
licenses,
there's
a
there's,
a
number
of
them
that
that
they
support
officially,
even
though
none
of
them
have
a
very
large
number
of
packages,
you
know
they.
C
They
include
things
like
the
Netscape
public
license
and
the
Nokia
open
source
lice.
There's
a
number
of
these
non-osi
licenses
that
they
allow.
They
also
have
categories
for
freeware
and
they
have
they
have
a
category
for
public
domain
like
I
mentioned,
and
they
also
even
have
a
category
for
a
proprietary,
all
of
which
they
allow
so
I
think
there's
definitely
precedence
for
for
featuring
non-osi
licenses
in
other
projects.
It's
it's
more
a
matter
of
how
we
feel
Our,
Community
Values
are
best
served
and
yeah
I.
C
Don't
see
any
reason
why
we
couldn't
be
more
permissive
about
I
I,
don't
see
any
reason
why
we
couldn't
be
more
permissive
about
certain
things
like
public
domain
or
you
know
even
things
like
the
Netscape
public
license
or
other
non-um
nanosi
licenses.
C
The
only
the
only
thing
I
think
would
be
remotely
controversial
is
either
actual
proprietary
software
or
some
of
these
more
modern,
a
quote,
unquote
open
source
licenses
that
are
a
little
bit
more
controversial
I,
don't
remember
the
names
of
some
of
them,
but
you
know
I
know
that
there
are
like
new
efforts
to
write
new
types
of
licenses
that
that
might
be
more
controversial
than
some
of
these
traditional
things
like
the
Netscape
public
license,
but
I,
don't
think
anyone's
asking
first
to
approve
those.