►
From YouTube: Jenkins Governance Meeting August 21, 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
Welcome
everyone:
this
is
the
21st
of
August
2023.
It's
the
Jenkins
governance
meeting,
thanks
for
being
here,
so
don't
have
Uli
or
Oleg.
Yet
we'll
put
those
down
that
don't
have
Kevin
so
put
that
separate
for
now.
Oh
that
didn't
work.
Okay,
so
upcoming
calendar
items,
we've
got
the
next
weekly
scheduled
for
tomorrow
and
the
next
LTS
the
day
after
so
Wednesday
we
will
have
2.414.1
Alex
anything.
You
need
to
share
with
us
on
the
preparations
for
that
since
you're,
acting
as
release
lead.
A
A
Great
well
listed
is
not
applicable
and
let's
go
on
to
action
items
then
so
Alex
you
want
to
share
with
us.
The
progress
you've
already
made
I
can
open
up
the
num
the
instructions
you've
given
here
on
the
voting
tell
us
how
the
voting
board
and
officer
election
prep
is
going.
B
Yeah
this
is
based
on
the
the
timeline
is
based
on
the
timeline
Olivier
used
in
2021.
Given
we
hadn't
have
elections
the
past
year,
there
have
been
no
documentation
and
the
documentation
basically
helped
me
to
get
into
it.
How
the
sifts
work?
How
this
course
group
creation
works,
because
it
was
kind
of
new
to
that,
at
least
from
a
runner
perspective,
so
yeah
I
think
the
timeline
is
rather
oops.
Oh,
go
ahead
thanks,
yeah
I
think
the
timeline
fits.
B
A
A
Likewise,
I've
got
an
open
action
item
on
working
groups
and
that
one
I
will
not
make
progress
in
two
weeks.
It's
just
going
to
sit
there.
It's
not
high
enough
priority
for
me
to
do
it
right
now.
I've
got
other
things
that
are
more
valuable.
D
I
think
that
redirects
should
be,
hopefully
a
small
amount
of
work
to
add
so
I
think
it
would
be
good
to
put
a
cap
on
or
to
tie
up
this,
this
project
that
we've
been
working
on
for
a
while.
A
A
A
D
Either
either
in
this
group
or
in
the
in
the
documentation
special
interest
group,
but
the
the
translation
assistance
is
not
going
to
survive
the
Prototype
migration,
so
I've
deprecated
it
and
I.
Think
most
of
the
functionality
is
now
available
through
crowded,
but
I
still
think
the
user
experience
of
the
original
translation
assistance
plugin
was
hard
to
replicate,
or
it
was
really
nice
just
being
able
to
click
within
the
Jenkins
UI
and
submit
translations.
D
That
barrier
to
entry
was
really
low.
So
I
thought
that
was
a
nice
feature
of
the
original
infrastructure
and
I'm
not
sure
that
the
the
new
infrastructure
has
quite
gotten
to
that
level
of
Polish
yet,
but
it
would
be
nice
if
it
eventually
did.
A
Okay,
then,
let's
go
on
to
governance
topics,
so
here
we've
got.
We've
got
an
open
question
from
the
Jenkins
developer
mailing
list
with
regard
to
the
Json
library
and
it's
using
a
license
that
is
not
OSI
approved
as
an
OSI
open
source
license.
It
declares
itself
to
be
open
source
or
to
be
to
be
oh
dear.
What
is
the
unencumbered
or
public
domain?
It
declares
itself
public
domain,
but
that's
not
OSI
approved
and
our
statement
on
the
document
on
the
governance
page
says
we
accept
OSI
approved
licenses.
A
B
A
B
The
license
of
the
Java
Library
just
adapted
what
appsume
already
had
since
2002,
so
we
have
already
used
it
passively
through
yeah.
Well,
just
Json
packet
as
Java
Library,
and
this
class
I
don't
have
the
exact
wording
in
mind,
be
public
domain
or
something
like
that
is
already
part
of
the
Upstream
license
for
almost
two
decades.
A
A
This
is
one
I
think
may
need
more
discussion.
I
brought
it
as
a
topic
here,
because
it'd
been
raised,
but
I'm
prone
to
think
I'd
like
to
do
or
have
someone
else
if
others
are
interested
propose.
A
How
should
we
handle
these
kind
of
questions,
because
we've
got
a
similar
question
from
Daniel
Beck
in
a
message
to
the
Jenkins
board
about
other
libraries,
which
are
are
different
licenses
that
may
not
be
OSI
approved
or
yeah?
Oh
yeah,
OS
OSI
recognize
open
source
licenses,
any
objections
from
others.
If
I
just
put
an
action
item
that
says,
let's
start
a
discussion
about
how
to
handle
licenses
based
on
these
two
messages,
this
Json
license
message
and
a
message
from
Daniel
Beck
to
the
board.
A
Some
other
other
approach
right.
That's
the.
D
D
Should
it
be
the
license
of
the
library
that's
being
wrapped,
or
should
it
be
the
MIT
license,
as
is
the
standard
license
for
all
Jenkins
plugins
and
looking
at
existing
examples?
There
have
been
both
choices
made
in
the
past
without
seemingly
any
clear
guidance
there.
So
if
we're,
if
we're
going
to
be
diving
into
this
rather
difficult
topic,
then
this
might
be
another
question.
We
try
to
answer.
A
Good,
very
good,
well
and
since
since
I
had
a
conversation
in
the
CDF
technical
oversight
committee
meeting
about
these
kinds
of
topics
and
they've
offered
to
give
us
some
help
from
or
did
I
seek,
some
help
from
the
Linux
foundation.
For
these
kinds
of
questions,
I
think
it's
a
good
idea.
Great
I'll,
I'll,
I'll
post
address
I'll,
create
a
draft
and
we'll
start
some
discussions
about
it.
Any
other
license
related
topics.
We
need
to
bring
well.
D
The
ones
that
I've
created
but
there's
other
cases
where
the
Library
plugin
not
only
bundles
a
library
but
also
provides
an
abstraction
layer
around
it,
for
example
in
the
HTTP,
the
Apache,
HTTP,
client
library
or
the
OK,
HTTP,
client,
library
or
I,
can't
remember
which
one
now,
but
one
of
those
two.
We
have
our
own
Java
code
that
acts
as
an
abstraction
layer
for
that
Library.
A
C
A
B
Yeah
I
think,
oh,
that
GitHub
sent
the
email
out
on
the
July.
The
third,
the
13th
I.
Think
if
I
read
that
correctly
and
I
thought
what
it
is
the
same
day
that
they
will
roll
out
2fa
for
a
majority
of
users
within
the
dinky
eye
organization,
I
think
yeah.
The
message
we
have
opened
there
is
actually
pretty
accurate.
I
was
checking
it
a
couple
of
minutes
ago.
Currently
we
have
around
750
people
without
with
a
out
of
2500
in
total.
A
B
A
Next
topic,
then,
was
a
question
raised
by
let's
read
the
ticket.
This
is
an
objection
from
this
user,
Kosh
dim,
saying
hey
as
a
Ukrainian.
He
would
like
us
to
change
the
link
that
we
have
today
on
the
top
level
page
from
the
International
Red
Cross
to
some
other
organization
based
on
these
other
organizations.
Now
I
don't
have
a
strong
opinion
about
which
of
these
organizations
are
yes
to
do
or
no
and
but
Oleg
ninashev
said
hey.
A
E
A
A
What
you'll
see
is,
let's
make
it
big
enough
to
read
this
paragraph
right
here:
okay
and
this
image
stopped
the
war
we
put,
those
up
when
Russia
invaded,
Ukraine
and
and
I
think
we
absolutely
want
to
continue
stating
that
we
stand
with
the
people
of
Ukraine
and
we
want
to
encourage
humanitarian
aid.
But
what
what
the
user
was
saying
about,
Oleg
was
reinforcing.
Is
that
the
international
Committee
of
the
Red
Cross
may
not
be
the
best
choice
that
there
might
be
others.
That
would
be
better
choices
to
recommend
in
this
hyperlink.
E
C
A
B
I
have
no
concerns
about
that.
If
I,
like
I,
think
he
provided
a
clear
yeah
justification
about
that
and
I
think
if
he
makes
a
call
about
that,
we
can
truly
agree
with
them.
There
can't
be.
C
A
A
A
Okay,
so
on
the
community
activity
topic
top
of
my
list
was
Java,
11,
17
and
21,
and
this
is
mostly
for
your
information
just
to
note
that
I've
sent
out
about
three
or
four
weeks
ago,
maybe
a
month
ago,
now
a
proposal
for
some
transition
dates
on
Java
support
in
Jenkins.
Those
dates
are
highlighted
here:
October
23
of
2023
is
proposed
when
we
enable
the
Java
11
end
of
life,
monitor
foreign
and
October
2024.
A
So
the
next
steps
for
me
on
this
one
is
to
have
a
continue.
The
discussion
in
the
developers
list
in
the
user's
mailing
list
and
then
I
think
the
most
effective
way
is
a
Jenkins
enhancement
proposal
to
say:
hey
here
are
the
dates.
We
propose
give
it
a
week
or
two
and
get
started
any
concerns
or
objections
there.
Things
where
you're
you're
worried.
D
I,
don't
have
any
objections.
This
sounds
good.
We're
a
little
ahead
of
schedule
with
Java
21
support,
I
think
in
the
sense
that
the
ath
and
PCT
are
now
running
on
Java
21
already.
So
we
could.
D
We
could
honestly
claim
that
the
top
100
or
200
plugins
that
are
in
that
suite,
are
supported
by
java21
or
or
that
those
plugins
have
have
been
tested
with
Java
21.,
but
there's
still
more
work
left
to
adopt
their
Jenkins
files
to
run
Java
21
on
on
their
own
pull
requests
rather
than
on
the
build
materials
test.
Suite.
D
A
C
A
Good
yeah
so
and
I
had
intentionally
left
this
date
sort
of
nebulous
on
Java
21,
because
for
me
that's
a
as
soon
as
it's
available
as
soon
as
we're
ready
to
declare
it
that's
great.
We
know
we've
got
to
do
container
updates,
we've
got
to
do
documentation,
updates,
we've
got
lots
of
other
places,
but
I
I
think
October
will
be
ready.
A
A
A
A
D
That
last
Point,
yes,
I,
think
the
requiring
Java
21
sounds
good
overall,
but
the
risk,
the
the
risk
about
it.
That
I
haven't
thought
about.
Very
much
is
the
old
version
of
groovy
that
we
use
and
I
don't
know
offhand
how
well
it's
going
to
work
with
Java
21
I've,
already
I've,
seen
I've
seen
some
small
issues,
for
example
in
job
DSL,
trying
to
use
the
our
old
version
of
groovy
with
Java
21.
D
So
far
those
issues
have
been
limited
to
test
only
issues
and
not
production
issues,
but
I
I
wouldn't
be
surprised
if
there
were
others.
So
that's
just
something
to
keep
in
mind
is
you
know
as
we
as
we
start
to
require
Java,
21
or
higher?
You
know
how
does
how
is
that
going
to
also
interact
with
with
group
with
the
old
version
of
groovy
that
we
use
in
the
case
of
the
job
DSL
plugin,
there's
a
test
Suite
that
is
running
groovy
based
tests
and
yeah
that
that
test
framework.
D
So
what
can
support
Java
21,
but
it
also
drops
support
for
groovy
2.4,
so
you
so
you're
kind
of
stuck
you're
kind
of
stuck,
because
you
know
you,
you
need
to
upgrade
this
library
for
Java
21
support,
but
you
also
can't
upgrade
it
because
you're
also
dropping
groovy
2.4
support
at
the
same
time.
So
this
is,
you
know,
going
to
become
now.
Luckily,
for
us,
that's
just
the
test
Library,
so
so
I
don't
know
we
could.
D
We
could
just
disable
those
tests
if
we
you
know
and-
and
that
would
that
would
also
be
a
problem.
I
guess,
because
we
lose
test
coverage,
but
at
least
it
wouldn't
be
a
production
problem,
but
I
could
imagine
similar
cases
to
this
in
in
production,
so
yeah
I'm
I'm,
just
not
too
sure
what
the
impact
of
that
would
be
just
yet.
But
it's
something
to
think
about
thanks.
A
D
Yeah
because
I
think
groovy
Shades
its
own
version
of
ASM
and
it
does
not
support
the
Java
21
byte
code,
which
it
does
support
the
Java
17
bytecode.
But
fortunately
we
don't.
We
don't
call
into
any
of
these
code
paths
anywhere.
So
it's
it's
like
it's
bad,
but
it's
not
it's
not
any
code
that
we
call
anywhere.
So
it
doesn't.
D
We
don't
have
any
errors,
but
it's
still
something
that's
very,
very,
very
tough
to
think
about
from
a
sustainability
point
of
view,
because
you
don't
know,
what's
going
to
call
into
that
code
path
like
that
testing,
library,
right
and
job
DSL
happens
to
call
into
that
code
path.
So
it's
definitely
something
that
makes
me
a
little
nervous.
A
Here
we've
been
discussing
with
the
infra
team
and
with
jfrog
the
host
of
our
artifact
repository
ways
that
we
can
reduce
from
what
was
a
sort
of
breathtaking
50
plus
terabytes
a
month
that
we
were
using
nine
months
ago
to
get
down
to
a
much
more
reasonable
amount.
We've
blocked
one
abuser
and
have
successfully
reduced
others
and
have
were
delighted
to
say
that
the
most
recent
changes
that
we
prototyped
showed
positive
results
and
jfrog
has
said.
A
We
don't
have
to
do
this,
adjust
of
parent
Palms
and
that's
a
very
positive
thing
to
to
not
have
to
do
we
don't.
That
means
no
requirement
for
a
new
release.
That
means
no
touching
the
2000
repositories
that
have
references
to
our
palms.
So
so
we
like
those
kind
of
changes,
any
questions
on
the
bandwidth
reduction
project.
D
A
Not
I'm
not
sure,
if
we're
going
to
use
the
mirror
or
not
at
this
point,
because
my
my
sense
is
that
what
we've
got
is:
we've
got
the
artifact
caching
proxy
right
now
that
sits
between
our
CI
agents
and
the
the
public
internet
anyway,
and
we
may
just
continue
using
the
artifact
caching
proxy
without
worrying
about
mirroring,
because
then
we
don't
have
to
answer
a
an
authentication
prompt
in
CI
and
make
the
CI
build
process
somehow
different
from
users.
Build
processes.
D
A
All
right
next
topic,
then,
was
Prototype
Js
here,
so
we
just
had
a
proposal
a
week
or
two
ago
from
Tim
Jacob,
proposing
that
let's
make
October
3rd
2023
the
date
when
we
implement
the
prototype.js
removal
in
Jenkins
core
for
our
weekly
release.
That's
a
nice
date
for
me
because
it
fits
with
when
we'll
also
enable
the
Java
11
end
of
life.
Admin
monitor
to
announce
the
next
year's
Java
11
end
of
life,
so
for
me,
October
3rd
felt
like
a
reasonable
date.
A
His
comments
in
the
in
the
pull
request
are
good
to
read.
Let's
look
at
those
here
where
he
notes.
Jfrog
has
said:
they'll
start
on
it
in
September
to
be
ready.
Cloud
bees
has
theirs
in
progress
and
fortify
is
said
there
should
be
ready
within
September
or
October,
and
the
three
two
or
three
or
four
others
no
response,
but
they
are
down
in
the
less
than
2
000
installations
each
range.
A
D
Yeah
I,
don't
have
any
issues
with
that
date
and
if
we
can,
if
we
can
agree
that
that
date
sense
means
that
below
I'll
reply
to
the
thread
and
and
say
that
I
approve
of
that
or
that
I'm
in
favor
of
that
date,
I
think
once
we
once
we
have
settled
that
day,
I
think
Tim
was
planning
on
emailing
these
other
companies
to
inform
them
of
the
date
great.
A
A
Great
all
right
last
item
then,
was
HTML
unit
three
upgrades,
and
here
the
tracking
sheet
shows
how
things
are
progressing.
The
the
most
heavily
used
plug-ins
are
are
making
their
way
through
it.
We've
we've
got
a
number
that
still
needs
need
the
transition,
since
this
is
test
I'm
less
worried
about
this
than
the
Prototype
JS
transition,
but
it
it
is
progressing
any
concerns
or
things
we
need
to
flag
on
HTML
unit,
3
upgrades.
A
E
I,
don't
know
if
it's
the
right
meeting
to
address
that,
but
I've
got
somebody
contacted
me
from
adoption
asking
if
we
wanted
to
be
part
of
their
it's,
not
a
Hall
of
Fame.
It's
something
that
say
this
project
uses
Tamarin,
you
know,
I
would
give
you
the
address.
Where
is
it
and
it
was
asking?
His
name
is
George
Adams
and
he
was
asking
if
we
would
be
interested
into
appearing
on
this
page
from
Tamarind
I
think
we
are
advertising
as
Tamarin
being
our
GDK
implementation
choice
right.
A
E
Okay,
so
as
it
was
during
my
PTO
I
didn't
contact
you
before
that,
but
I
already
have
raised
an
issue
as
they
asked
me
to
in
their
GitHub
repo,
so
they
wanted
to
have
a
logo.
If
we
were
okay
with
that
and
that's
yeah,
that's
what
I
said:
okay,
it's
the
issue.
I
was
referring
to
and
the
logo
I
proposed.
They
did
not
like
it,
so
they
found
another
one.
They'd
like
to
use
and
I,
don't
know
if
it's
an
official
logo
of
Jenkins
and
if
it's
one
we
can
reference
to.