►
From YouTube: Jenkins UX SIG Meeting 21 Jun 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
Jenkins
user
experience
special
interest
group.
It's
the
21st
of
June
2023.,
thanks
for
being
here,
I'll
update
the
attendee
list
a
little
later
here,
topics
that
I've
got
on
the
on
the
list
for
today.
What's
happened
recently
in
UI
improvements
as
one
topic
and
then
a
reminder
for
the
next
LTS
Baseline,
a
temporary
expansion
of
the
Securities
audits.
This
one
will
lead
the
discussion
on
and
then
we've
got.
A
A
A
We
continue
to
ship
it
so
that
we
retain
compatibility,
but
the
usages
in
core
are
gone
so
that
we
can
find
it,
and
there
is
now
a
an
experimental
feature
that
you
can
disable
the
use
of
prototype
to
see
what
happens
thanks
to
Basel,
for
keeping
this
plugins
tracking
sheet
up
to
date.
We're
seeing
good
progress
there
as
as
we
get
releases
of
plugins.
There
are
some.
You
can
see.
The
the
sort
of
orange
colored
bars
have
a
pull
request
and
need
to
be
released,
needs
to
be
merged
and
released.
A
A
Okay,
so
next
topic
on
my
list,
then
was
we've
got
a
new
UI
new
feature
coming
in
the
UI
from
Marcus
winter
of
sap,
he's
proposed
to
use
a
modal
dialogue
inside
the
web
pages
for
the
delete,
dialog
nice.
Modernization
really
good,
feel
it's
been
through
the
security
review.
It's
been
through
various
use
reviews,
so
it
should
be
arriving
pretty
soon
any
questions
or
concerns
there.
A
Okay,
next
topic,
then,
was
UI
Improvement
pull
request
for
me
on
firechik,
and
here
there
are
several
in
flight
that
need
that
are
either
ready
to
merge
or
need
review
and
further
discussion.
I'm,
not
sure
that
there's
any
of
these
that
I
feel
like
I
need
to
highlight,
specifically
over
the
other,
just
that
we've
got
these
ongoing,
pull
requests
that
that
are
looking
for
comments,
reviews
and
getting
ready
to
merge.
A
Then
there
are
some
that
I'd
say
have
more
more
discussion
going
on
where
it's
proposed
to
change,
manage
Jenkins
to
be
settings
and
there's
discussion
there.
It's
recent
discussion
happening
in
the
last
few
days,
good
discussion,
but
it
needs
to
continue
likewise.
This
change
of
the
structure
of
the
the
jelly
files
to
better
represent
things
has
good
discussion
happening
between
yawn
and
and
and
Jesse
Glick
and
others
any
questions
or
concerns
on
any
of
those.
B
Yeah
I
did
some
experiments
with
the
CSS
compilation
and
I
found
I
found
that
I
was
able
to
use,
has
able
to
use
some
transpiler
to
compile
newer,
newer,
CSS
syntax
into
a
forum
that
could
still
be
understood
by
HTML
unit
and
I.
Think
that
could
be
a
viable
approach
for
us
to
continue
to
modernize
the
CSS
that
we
use
without
breaking
our
existing
unit
tests
that
rely
on
HTML
unit,
which
can't
parse
a
lot
of
the
newer
syntax.
B
A
B
A
B
Like
yeah
I
have
two
pull
requests.
I
think
one
of
them
has
one
approval
so
far.
B
The
other
one
is
for
so
I
tried
to
use
this
transpilation
option,
for
that
has
pseudo
notation
and
it
did
not
work
for
that,
because
has
is
more
complicated
and
cannot
be
transpiled
into
older
CSS
without
some
JavaScript
as
well.
So
the
the
polyfill
for
the
has
feature
is
more
complicated
it.
B
It
requires
both
CSS
and
JavaScript
to
run
in
browsers
that
don't
support
has
and
the
JavaScript
part
of
this
poly
field
didn't
work
in
HTML
unit
either,
which
is
just
really
it's
really
depressing,
because
you're
trying
to
you're
trying
to
use
a
poly
fill
which
is
ostensibly
designed
to
support
older
browsers.
The
older
browser
doesn't
even
support
the
polyfill
so
but
I
think
this
is
more
of
an
exception.
B
B
So
so,
just
because
I
wasn't
able
to
use
the
trans
file
approach
in
the
case
of
has
doesn't
mean
that
we
can't
use
it
in
general,
but
getting
rid
of
the
has
pseudo
notation
at
least
makes
our
logs
clean,
because
our
logs
are
full
of
HTML
unit,
not
understanding
this
has
notation,
which
is
just
distracting
when
you're
running
other
tests.
So
so,
basically,
my
first
pull
requests
gets
simplifies
the
has
that
has
notation
and
my
my
second
one
introduces
the
transpiler.
C
C
B
This
is
this
is
already
using
scss.
B
The
fact
that
the
technology
that
I'm
using
is
is
it's
a
preset
environment
for
or
for
our
CSS
a
building
tool.
I
forget
what
it's
called
now
post
CSS,
but
yeah.
So
we
we're
already
using
scss
and
the
way
that
this
technology
works.
B
I
thought
that
I
thought
that
we
would
be
directly
compiling
a
CSS
into
CSS,
but
that's
not
how
it
works
it.
It
compiles
scss
into
some
intermediary
representation,
that's
unique
to
post
CSS
and
then
post
CSS
has
a
generic
a
generic
mechanism
for
compiling
its
intermediary
representation
into
CSS,
so
essentially,
scss
and
less
and
many
others
are
just
front
ends
to
this
post
CSS
subsystem,
which
was
surprising
to
me,
but
that's
how
it
works.
A
Thank
you
all
right.
Next
next
topic,
then,
was
that
just
a
reminder
from
me
that,
as
a
reminder,
our
next
LTS
Baseline
will
be
chosen
in
three
weeks:
July,
the
12th,
so
the
the
weekly
releases.
We
we
always
care
about
weekly
release
stability,
but
be
mindful
that
we're
up
upcoming
on
the
next
LTS
Baseline
selection.
So
let's
do
a
good
job.
A
C
So
it's
a
pretty
long
topic
if
you
want
to
move
to
another
one
before
no
voice
for
my
side
well
up
to
you
I
think
I
need
at
least
perhaps
a
10
to
20
minutes,
depending
on
the
discussion
around
that.
A
Yeah
and
I
I
was
thinking.
Well,
we
could
we
could
Christina
if
you're,
not
especially
interested
in
the
security
audit.
We
could
bring
Securities
Christina's
earlier
if,
if
that
would
be
easier
for
you,
Christine
or
if
you
intend
to
be
with
us
the
whole
time,
we'll
just
put
you
where,
where
you
are
on
the
agenda
now.
A
D
C
To
provide
you
some
context
related
to
the
topic
there,
you
can
open
the
reference
that
you
have
like
three
or
four
lines
after
it's
just
another
way
that
we
published
some
days
ago
related
to
an
issue
that
was
in
Jenkins
for
props
seven
years
or
eight
years,
or
something
like
this,
so
that
vulnerability
was
detected
recently
by
the
security
team.
I
think
it
was
one
month
ago
or
something
like
this,
and
what
was
interesting
to
see
with
that
one.
C
A
C
C
I
mean
like
less
than
one
year
ago,
because
we
have
some
vulnerability
that
we
are
still
finding
in
the
code
that
are
coming
from
10
years
ago,
and
this
kind
of
thing
it's
just
a
matter
of
finding
them
at
some
point
and
with
the
audit
that
we
are
doing
it.
B
C
To
the
previous
or
tap
this
match,
thank
you.
So
what
is
interesting
there
is
that
that
pull
request
was
not
UI
available.
It
was
in
JavaScript
with
some
jelly
aspect.
I,
don't
remember
exactly,
but
it's
your
JavaScript
and
jelly,
but
these
things
were
not
covered
by
the
initial
scope
of
the
the
requirement
for
the
audit
in
the
past,
because
they
are
not
touching
the
UI
meaning
it's
not
visible
for
the
user.
That
was
really
the
goal
of
the
first
policy
or
incense
there.
So
at
this
point,
that's
just
for
the
context.
C
I
want
to
just
raise
a
bit
of
awareness
about
the
cost
of
the
security
release,
because
that's
something
that
could
be
oversized
by
people
that
are
not
directly
working
within
the
process,
so
I
try
to
keep
it
simple.
There
I
discussed
with
a
basil
about
the
extended
list
of
things
we
are
doing.
You
can
feel
you
can
see.
That
list
is
already
reduced
by
at
least
a
factor
of
tube
I
think
so
we
have
a
lot
of
costs
in
term
of
time
in
terms
of
time
frame
as
well
in
term
of
cost
Trends.
C
If
we
correct
something
within
a
pull
request,
it's
fairly
easy.
It's
a
matter
of
perhaps
one
day
maximum
the
time
to
do
some
ping
pong
discussion
and
this
kind
of
thing,
but
if
we
wait
for
it
to
be
released
and
part
of
a
version
of
Jenkins,
it's
at
least
20
20
times
the
cost
just
for
the
security
team.
No,
it's
also
something
to
consider
it's.
C
In
addition,
the
release
lead
for
the
next
LTS
version
will
provide
some
backwards,
so
this
report
have
to
be
integrated
with
our
fix,
ensuring
that
the
fix
is
still
fixing
the
vulnerability
and
also
the
weekly
is
sometimes
something
that
is
changing
quickly
depending
of
the
time.
So
we
have
to
integrate
that
as
well
inside
our
fix
and
still
ensuring
it's
fixing
the
vulnerability.
C
So,
due
to
that,
we
have
to
prepare
some
additional
data,
so
the
advisory
process.
So
the
content,
the
description
that
you
are
seeing
at
the
end,
but
also
the
upgrade
guide,
the
change
log
and
all
the
merge
information
that
we
are
using
to
do
the
different
merge
of
the
pull
request
correctly
in
the
good
order,
while
ensuring
everything
is
compiling
correctly.
C
That's
for
the
security
aspect
or
the
security.
What
is
also
invisible
most
of
the
time
for
the
contributor
is
the
impact
for
the
user
of
Jenkins.
If
you
are
running
a
version
of
Jenkins
that
has
an
open
vulnerability,
meaning
that
we
have
published
an
advisory,
your
version
become
vulnerable,
openly
vulnerable.
It
was
already,
but
no
everybody
knows
about
that
and
with
the
information,
some
companies
asked
to
provide
a
quick
update,
so
urgent
update
and
this
kind
of
thing,
which
is
disturbing
the
regular
day-to-day
work
innocence.
C
They
are
very
close
friends
in
a
sense
that
they
are
reporting
a
lot
of
cves
every
time
that
are
not
always
very
interesting,
but
it's
just
to
know
is
that
we
are
adding
to
the
top
of
all
these
kind
of
things.
So
all
the
information
there
is
not
to
say
that
we
have
to
split
the
bill
or
this
kind
of
thing
it's
something
that
we
are
paying
in.
The
security
team
is
used
to
make
other
people
aware
about
the
incurred
cost
of
that.
That
is
not
just.
Oh,
you
have
to
correct
the
thing.
C
A
C
We
can
expand
the
people
working
Within
These
fix
it's
more
matter
of
time
and
will
from
people
the
security
team
is
open
if
you
want
to
contribute
to
participate
in
this
kind
of
thing.
What
which
we,
what
we
usually
require
is
that
the
people
inside
the
team
are
active
in
the
team
because
they
have
access
to
a
lot
of
confidential
information.
If
they
are
part
of
the
team
once
per
year,
it
could
be
problematic
in
terms
of
security,
confidentiality
and
so
on.
C
Providing
the
fix
could
be
a
way
to
participate
in
the
effort,
but,
as
I
mentioned,
it's
five
percent
of
the
cost
right.
It's
a
participation
for
sure.
Typically,
the
release
lead
and
anything
in
that
meeting
already
some
previous
release
leader.
They
are
participating
by
the
coordination
and
this
kind
of
thing
so.
B
C
Thank
you
for
the
Discord
there.
So
what
I'm
proposing
at
this
point
is
that
we
are
expanding
the
scope
of
the
pull
request
that
require
a
Security
review.
What.
B
C
Be
related
to
same
kind
of
exercise
and
other
vulnerability.
I
would
like
to
have
that
expansion
to
be
done
for
two
months
and
not
just
indefinite.
Even
the
previous
policy
is
not
indefinite
in
terms
of
timing,
it's
just
until
we
are
not
single
any
vulnerability,
frequently.
Also
that
one,
it's
more
like
a
time
box
effort
to
see
if
there
is
an
interest
if
we
are
finding
something,
because
if
tax
are
two
more,
we
are
fine,
we
are
found
nothing.
C
C
So
usually
the
people
in
the
team
are
looking
at
that
proactively.
But
we
have
one
reminder
for
team
per
week.
Sorry
and
the
idea
is
to
move
to
at
least
three
times
per
week,
mainly
Monday
Wednesday
Friday,
this
kind
of
thing.
So
if
nobody
was
looking
at
something
on
Tuesday
on
Wednesday,
the
team
will
look
at
the
think.
Okay,
we
have
to
split
a
bit
the
different
things
so
that
we
provide
an
audit
as
soon
as
possible.
That
could
be
a
way
to
move
forward,
something
to
keep
in
mind.
C
Most
of
the
pull
requests
that
are
not
UI
are
related
are
very
simple.
In
terms
of
audits,
meaning
that
we
have
seen
a
lot
of
search,
pull
requests
in
the
past,
reviewing
them
could
take
us
between
5
and
10
minutes.
Something
like
that.
So
mainly
if
there
is
something
that
is
blocked
because
of
us,
a
single
ping,
it
will
solve
this
situation
in
Parts,
20
minutes
or
half
an
hour.
C
C
Also
another
point
about
the
scope:
why
are
we
doing
that?
Only
for
JavaScript
and
jelly
and
not
for
the
rest
of
the
pull
requests
like
dependency,
update,
back-end
collection,
modification
and
so
on?
It's
usually
something
we
have
seen
the
back
end
in
general
in
Jenkins
is
more
secure
in
core
and
popular
credits
in
low
popularity
plugins.
C
C
The
JavaScript
jelly
is
more
easy
to
put
some
exercise
inside.
So
that's
a
bit
why
I
would
like
to
focus
on
that
aspect
and
not
on
everything
we
have
to
consider
the
Practical
aspect.
The
team,
the
the
the
security
team
time
is
limited.
We
are
not
infinite
number
of
people
there,
so
we
have
to
focus
on
the
things
that
matter
the
most.
That
would
be
the
idea
and.
C
Just
a
quick
reminder:
the
team
is
very
happy
to
be
pinned
on
any
pull
requests,
even
if
it's
not
GS
or
jelly.
If
you
think
there
is
something
that
could
be
problematic,
if
you
have
a
doubt
fingers
it's
a
lot
easier
for
us
to
to
spend
five
minutes.
Oh
no!
No!
Don't
worry
it's
a
false
positive.
Instead
of
having
to
correct
something
so
typically
I
know,
Alex
was
thinking
us
on
some
of
the
things
and
it
was
like.
C
C
So
I'm
done
with
my
all
the
layers
and
this
kind
of
thing.
So
please
any
question
any
concern.
Any
feedback
about
that.
C
A
E
No
I
don't
have
any
concerns.
One
could
possibly
argue
that
it
would
or
could
slow
down
the
overall
time
to
get
APR
delivered,
but
I
don't
think
the
impact
is
huge
on
that.
Given
like
what
I
said,
the
team
would
refill
them
more
than
one
time
a
week
and
we
don't
have
that
many
open
pull
requests
needing
attention
from
the
security
team,
targeting
jelly
or
JS
components,
so
I
think
the
impact
would
be
rather
marginal
and
we
would
be
still
able
to
deliver
front-end
pull
requests
in
a
timely
manner.
C
There
any
others
keep
in
mind
that
if
you
are
seeing
something
tell
me,
because
that's
typically
something
I
don't
want
to
slow
down
the
process
of
others.
If
we
are
slowing
down
by
one
percent,
that's
fine,
but
if
it
become
really
relevant,
we
have
to
discuss.
We
have
to
register
the
process
and
this
kind
of.
A
All
right
so
then
I'm
going
to
go
ahead
and
agreed
proceed
as
as
proposed
and
Note
and
given
I've
seen
no
objections.
I
think
we
we
say
yes,
the
ux
Sig
says:
let's
go
ahead
with
this.
Thank
you
very
much
for
the
the
Jenkins
security
team
being
willing
to
do
it
and
thanks
to
core
reviewers
for
helping
helping
make
it
successful.
A
D
Yeah
so
where
it
was
left,
the
the
big
three
blockers
had
been
cleared,
the
top
now
sidebar
the
breadcrumbs.
D
So
in
last
month's
meeting,
the
ask
was
that
I
kind
of
humanized
the
breakdown,
the
audit
that
had
been
done,
the
German
language
one.
So
what
I've
done
is
created
it's
about
7
10.
Let
me
see.
D
Yeah,
please
yeah,
there's
seven
tasks,
a
figure
rather
than
bombard
the
board,
with
a
bunch
of
them
group
them
by
the
so
right
now
we're
going
to
Target
2.1
keyboard,
operation
and
navigation
and
the
results
therein.
D
So
some
are
straightforward.
Some
are
broken
down
a
bit
more,
so
it's
got
clear
acceptance,
criteria
and
suggested
fixes,
but
it's
a
good
starting
batch.
A
D
No,
hopefully,
not
and
I
assume
since
I
created
them.
If
they
get
comments,
I'll
I'll
get
those
I'll
get
notified,
so
I
can
jump
in
and
provide
further
clarification
if
needed.
So.
A
In
terms
of
is
this:
is
this
one
we've?
Sometimes
we
get
questions
in
the
getter
channels,
I'm
a
new
contributor
I'd
like
to
help.
This
feels
like
it's
still
a
little
more
specialized
than
a
new
contributor
might
be
particularly
ready
to
embrace.
What's
your
sense,
is
this
friendly
to
a
university
student
or
somebody
who's.
A
D
D
A
Now
I
guess
this
is
one
these
will
probably
Touch
Jelly
files
right
because
that's
commonly
where,
where
navigation
is
set,
so
vadex
team
will
then
be
flagged,
but
they
should.
We
hope,
also
be
relatively
simple
reviews
because
they're
not
Christina
the
way
you
describe
it,
they're
not
huge
changes.
They.
A
Okay,
next
topic,
then,
was
notifying
users
of
operating
system
end
of
life,
and
this
is
just
to
share
that.
We've
accelerated
the
visibility
of
this
notification.
We
added
an
admin
monitor
in
2.407
to
tell
people
if
they
were
running
an
operating
system.
We
knew
would
be
end
of
life
in
the
next
six
months
and
we
hope
that
will
help
at
least
some
subset
of
them
to
get
off
those
those
old
operating
systems.
A
We
have
an
approved
exception
to
the
usual
LTS
policy,
so
that
next
week,
when
released
2.401.2,
this
warning
will
also
appear
to
LTS
users.
So
that's
about
eight
weeks
earlier
than
we
expected
it's
not
harmful
to
them.
I
think
it's
a
reasonable
thing
to
try
to
warn
them
earlier
that
their
their
operating
system
is
reaching
end
of
life.
Any
concerns
or
comments
there,
I
guess
I
should
note.
A
One
thing
is
that
I'm
dreaming
of
a
future
extension
where
we
will
warn
people
about
container
end
of
life
and
container
end
of
life
is
a
very
different
thing,
because
it's
not
the
operating
system.
It's
the
fact
that
we're
no
longer
going
to
maintain
that
container
image.
That's
not
there!
Yet
it
needs
extensions
to
the
base
thing,
but
we
think
it's
a
good
thing
to
tell
people
you're
running
a
container
image,
we're
not
going
to
support
after
such
and
such
a
date
all
right.