►
From YouTube: Jenkins UX SIG Meeting 13 Apr 2022
Description
Topics
* 00:00 Introduction
* 00:13 Delaying LTS baseline selection by 2 weeks or 4 weeks
* 21:20 Script security UI improvements
* 24:57 Delay new feature merges short term in favor of resolving regressions
A
A
A
A
Oh
alex
good
is
already
very
good.
Thank
you.
So
I
had
started
this
this
discussion
and
I
see
alex
you
had
given
us
a
reply.
Maybe
we
we
take
the
time
right
here
to
have
some
discussion.
The
idea
was
that
we've
got
more
regressions
in
the
current
weekly
releases
than
our
typical
for
a
an
lts
baseline
selection.
A
So
my
thought
was:
we
should
intentionally
choose
to
delay
the
lts
baseline
selection.
While
we
work
to
resolve
those
regressions
and
as
we
resolve
them,
then
we
can.
We
can
choose
the
lts
baseline
based
on
a
weekly
that
has
has
confidence
for
us
alex.
I
hadn't
yet
read
your
reply,
so
maybe
you
can
take
us
through
what
what
your
observations
were.
There.
B
Oh
yeah,
this
is
just
what
I
quickly
wrote
on
a
few
minutes
ago.
I've!
Basically
you
rearranged.
Your
list
of
issues
into
blocker,
major
minor
and
swivel
is
used
with
a
short
explanation.
How
I
experience
them,
because
if
I
remember
correctly,
they
are
all
labeled
as
major
or
blocker,
currently
on
jira,
so
I
went
ahead
and
rearranged
them
here
and
the
email
threat.
A
Good,
okay,
so
well,
and-
and
I
think
it's
a
this-
is
a
this-
is
already
a
worthwhile
conversation
for
us
about
hey.
How
should
for
me
the
the
one
you
put
up
as
blocker
is
is
well
in
the
sense
that
it
makes
the
ui
ugly,
because
it
actually
doesn't
stop
me
from
using
the
product
it
just
renders
really
badly,
and
it's
a
very
early
page
that
I
see
this
bad
rendering
on.
So.
For
me,
that
was
the.
That
was
why
this
one
and
I'm
yeah
it
was.
A
A
B
A
Okay
and
and
then
then
your
idea
of
this,
the
tooltips,
when
the
reason
I
was
so
concerned
about
the
tooltips
one,
is
that
it's
a
that's
a
place
where
the
it's,
without
that
hint,
it's
really
hard
to
deal
with.
What
does
that
sell
mean
that
I'm
clicking
in
that
matrix
of
permissions
and
array
of
of
things?
So
so,
but
I
think
I
understand
your
point
here
that
you
you're
saying
hey:
maybe
we
don't
don't
delay
the
lts.
I
think
your
your
revisit
gives
us
a
good
indication.
B
Yeah,
I
think
the
metrics
one
is
currently
the
only
plugin
that
is
labeled
as
as
losing
tooltips.
I
didn't
find
something
else
on
jira
earlier,
but
on
the
other
end,
I
don't
have
such
an
older
jenkins
release
at
hand
at
the
moment
to
replicate
it.
But
if
I
remember
correctly,
if
you
hover
over
the
columns
of
the
matrix
earth
plugin,
you
have
tool
tips
what
it
does
as
well.
B
C
B
A
B
B
A
So
then,
in
this
case
it
would
be
a
situation
where
we
identify
things
that
have
the
issue
and
use
the
the
the
fact
that
they
have
the
issue
as
a
way
of
flagging
hey.
This
is
one
that,
if,
if
we
don't,
if
this
one,
this
plug-in
does
not
get
a
new
release
to
include
this
change,
then,
when
it's
when
this
release,
when
the
lts
comes
available,
that
does
this,
it
will
no
longer
display
those
icons.
B
Yeah
I
have
addressed
these
issues
in
a
few
other
plugins
as
well,
but
I
basically
went
the
way
to
go
through
the
repository
permission.
Updater
adopt
the
plugin,
perform
a
release
and
remove
myself
from
it
again
if
it's
a
plugin
from
2012
or
13,
or
something
that
is
definitely
not
no
longer
maintained.
A
Okay,
good
good
insight,
so
so
now,
basel
and
I
were
having
having
conversations
about
this
one
in
terms
of
are
there
other
alternatives?
For
us,
the
tables
to
divs
upgrade
went
through
a
similar
process
and
it's
been
a
rather
painful
experience
in
with
with
30
or
40
open
bug
reports
currently
on
tables
to
divs,
but
I
I
think,
you're
right.
We
don't
really
want
to
resurrect
an
eight-year-old
plug-in
just
to
make
this
change
when
we
we
aren't
confident
it
will
matter
to
users.
B
C
Yeah,
I
think
that's
a
good
idea,
but
the
risk
we
run
there
is
that
there
aren't
very
many
people
necessarily
running
the
weeklies,
and
I
think
many
people
will
not
discover
these
bugs
until
the
lts
is
shipped,
which
is
something
that
I've
noticed.
You
know
just
recently.
We
we
found
two
issues
that
have
been
in
weeklies
for
a
very
long
time
that
were
not
noticed
until
they
were
delivered
in
an
lts
release.
C
C
Is
this
something
that
we
care
about
or
not?
And
if
we
do
care
about
it,
then
I
opened
a
pull
quest
to
update
the
guava
usage
and
if
we
didn't
care
about
it,
then
you
know
that
went
into
a
separate
bucket,
where
we
explicitly
decided
that
we're
not
going
to
fix
this.
But
I
think
it
was
important
to
actually
go
through
them
one
by
one
and
make
that
decision
consciously,
rather
than
just
waiting
for
a
user
to
complain
about
it
months
or
weeks
later.
A
No
alex
you
had
noted
that
they
weren't
using
the
api.
So
is
this
a
searchable
detectable
condition
like
I've?
I've
seen
cases
where,
where
felix
did
reports
of
bugs
to
to
plug-ins
that
were
detected
to
be
using
tables
that
contained
ui?
Is
this
a
similar
kind
of
thing
where
it's
feasible
to
search,
or
does
this
require
a
human
being
to
actually
look
for
it.
A
Okay,
all
right,
so
it
is
so
it
is
a
detectable
thing,
good,
okay!
So
then,
as
you
had
suggested,
we
could
start
tracking
start
tracking
this
thing
in
in
jira
and
say
all
right.
Here's
this!
We
know
this
issue
exists.
We
know
this
one
exists
and
then
then
we've
got
the
risk.
Yes,
plugins
that
are
abandoned
may
not
get
a
fix
right
they,
but
we
at
least
we
know,
then
good.
Okay,.
A
B
Yeah
I
mean
this:
the
input
is
rather
simple.
You
can
either
use
the
github
search
or
if
you
are
in
the
technology
preview,
you
can
use
css.github
for
that
and
search
all
repositories
on
the
jenkins
ci
organization
and
yeah.
Then
you
can
take
a
look
for
the
last
sem
activity
and
if
it
was
in
2014,
you
can
likely
say
the
plugin
is
abandoned
and
rank
it
more
down.
The
list
on
jira.
A
Yeah,
okay,
thanks
all
right,
so
that
feels
like
a
a
very
reasonable
approach
to
me.
Let's,
let's
set
ourselves
the
objective
that
we're
going
to
do
a
a
a
detailed
review
this
I
I
think
this
is
a
lot
healthier
than
one
of
my
thoughts
was
oh,
should
we
just
put
all
the
pictures
back,
but
then
the
problem
with
putting
all
the
pictures
back
is
now
we
never
know
how
to
get
rid
of
them
right,
whereas
what
what
you've
done
this
way
starting
down
the
process?
B
Yeah
the
process
is
rather
simple.
Behind
the
ease
of
migration
is
the
jackets
io
blog
post.
I
linked
there
how
to
go
about
it,
to
do
it
in
jelly
and
in
groovy.
Didn't
have
a
java
example
at
hand
at
the
time.
Right
of
writing
this,
but,
like
you
can
see,
the
process
is
rather
simple
and
doesn't
require
much
work.
A
A
C
D
A
A
good
I
was
assuming
that
the
two
weeks
was
like
that's
a
good
point.
I
was
assuming
two
weeks
applied
across
all
releases
all
releases
this
this
year,
so
that
was
what
I
was
assuming,
but
that
made
if
we
go
beyond
two
weeks,
we
now
may
have
used
up
the
the
cushion
that
we
have
so
the
the
cadence
is
12
weeks,
so
we
use
48
weeks
of
the
year.
A
week
is
52
weeks.
A
D
The
number
of
things
that
we
are
doing
per
year,
it's
not
a
big
deal.
What
is
more,
concerning
is
what
we
want
to
do.
Do
we
want
to
postpone
the
lts
release
or
just
the
selection
of
lts
release,
because
between
the
lts
selection,
when
we
decide
which
weekly
we
are
taking,
it
will
influence
the
rc,
the
release
candidate
and
then
the
lts.
We
have
some
times
between
the
the
selection
date
and
first
rc,
it's
four
weeks.
D
A
Good
good
point,
so
my
assumption
was.
I
was
assuming
that
the
delay
applied
to
everything,
so
it
was
an
intentional
moving
of
the
whole
calendar
and
that's
a
good
point,
but
that
we
could
choose
something
different.
But
for
me
it
was
much
easier
to
think
about
not
attempting
to
take
time
out
of
other
things.
A
D
Information
there,
the
release
candidate
is
also
something
where
we
are
pushing
the
back
part.
So
for
security
really
is
the
back
part
of
security
release.
In
this
case
it
will
not
be
a
security
release,
but
if
you
find
some
regulation,
you
want
to
correct,
you
have
to
backport
them
to
the
release
candidate,
meaning
if
we
are
doing
that
the
same
day,
it
will
be
impossible.
There
will
be
no
time
to
review
the
thing
if
it's
only
two
weeks,
it
means
that
we
have
only
two
weeks
left
for
the
release
candidate
to
receive
the
back
part.
D
A
Good
and
and
my
bias
is,
do
the
calendar
update
without
attempting
to
compress
anything
else?
Are
there
others
who
have
a
different
opinion
there
who
would
lobby?
No,
we
need
to.
We
need
to
to
do
something
else,
other
than
just
move
everything
two
weeks
or
four
weeks
later
to
to
allow
us
time
to
get
a
more
stable,
weekly
release.
A
A
D
So
perhaps,
if
you
want
to
have
close
to
zero
impact
in
the
long
term,
we
can
propose
to
do
a
dot
four
release
the
next
time
and
to
have
the
next
lts
being
just
dot
one
plus
the
two.
So
a
long
time
support
of
two
months
instead
of
trim
off
that
could
be
another
approach
so
that
in
six
months
there
will
be
no
impact
at
all.
A
A
A
Okay,
then,
the
other
topics
we
had
were
really
relative
to
proposed:
pull
requests
for
a
script
security
improvement.
I'm
not
sure
anybody
on
this
call
has
comments
to
make.
Are
there?
I
guess
vatic?
Are
there
things
with
this?
One,
specifically
that
you
would
like
to
discuss
here,
perhaps
just
add.
A
D
The
pro
request:
it's
a
pretty
old
one,
so
just
for
the
information
there,
I
don't
know
why
the
topic
is
coming
there
in
the
meeting,
but
anyway,
that
pull
request
is
to
improve
a
bit
the
user
experience
in
skip
security,
especially
about
the
approval
tab.
The
approval
tab
currently
is
mainly
that
you
have
to
upload
it
once
and
the
hash
of
the
aproscript
will
be
stored.
Nothing
else
no
metadata,
so
you
don't
know
where,
when
it
was
approved,
why
it
was
approved
by
wu
and
so
on.
D
Currently,
you
have
to
remove
everything.
The
other
option
is
to
go
to
the
xml
file
and
to
remove
the
thing
manually,
which
is
not
really
a
great
experience.
That's
a
bit
the
idea
with
that
full
request,
and
the
main
issue
is
that
we
discover
the
book
in
the
the
pipeline
approval
logic.
It's
about
the
re-approval
of
things.
You
can
see
the
detail
with
the
ticket
we
opened
after
that
pull
request.
D
A
A
Okay,
because
because
this,
this
truly
does
open
some
risk
that
now
you're
allowing
certain
certain
forms
of
execution
that
may
not
be
safe
inside
your
jenkins
controller.
Okay,
all
right,
so
I
think
that
just
stays
as
it
is,
then,
I'm
not
sure
we
need
any
make
any
further
progress
there.
Any
other
topics
for
today,
I'm
hesitant
to
talk
anything
about
upcoming
ui
improvements
without
yan
and
tim
here.
A
A
D
Okay
thanks
everybody,
just
one
point:
I
forgot
due
to
the
situation
we
have
nowadays.
What
I
would
propose
is
that
we
are
stopping
merging
new
feature
in
jenkins
core
until
we
have
a
more
stable
solution,
stable
weekly,
so
that
we
do
not
have
a
new
introduction
of
bugs
regression
while
we
are
correcting
the
existing
one.
D
If
we
are
not
doing
that
and
continue
merging
things,
we
are
just
in
a
situation
where
we
cannot
really
stabilize
the
stuff.
So
just
an
idea,
there
probably
be
very
careful
if
you
merge
something
it
could
add
new
regression
that
we
have
to
correct
and
due
to
the
fact
that
we
know
that
it's
currently
unstable,
we
have
to
correct
a
lot
of
regression.
D
D
D
That
was
a
bit
I
would
say
implicit
in
the
past
when
we
had
the
selection
coming
close,
it
was
mainly
we
want
to
have
at
least
that
feature
so
stop
introducing
new
feature
for
the
next
weekly.
To
be
sure,
it
was
a
bit
stable.
So
your
point
is
just
not
too
explicit
in
the
doc.
I
think,
but
yeah,
it's
just
a
matter
of
good
habits.
I
will
say
in
general,.
A
A
Likewise,
with
the
the
ui
changes
that
came
in
2.332
and
the
ui
changes
that
are
now,
they
each
arrived
just
a
week
after
lps
baseline
was
selected,
so
we
had
maximum
exposure
so
yeah,
I
think
that's
good
and
let's,
we
can
certainly
describe
it
in
more
clear,
clear,
clear
terms
if
it's
not
already
described
there
very
good
thanks
any
other
observations
or
points.
We
need
to
include
in
the
notes.