►
From YouTube: Che Community Meeting - January 10, 2022
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
B
B
B
So
the
like,
as
the
schedule
goes,
we
usually
do
like
one
major
release
at
the
end
of
the
sprint,
which
is
like
one
week
and
then
every
the
rest
of
the
two
weeks.
We
do
like
one
bug
fix
release
as
planned,
so
like
next
week
is
point
one
release
the
week
after
that
is
point
two.
B
B
I
I
personally
have
come
to
an
opinion
that
it's
probably
not
needed
to
keep
doing
these
scheduled
bug
fix
releases
and
only
do
them
on
demand.
So
if,
if
any,
like
particular
team,
says
that
this
particular
box
bug
must
be
fixed
for
this
particular
major
version,
then
they
will
create
a
bug,
fix
issue
and
provide
all
the
necessary
fixes,
and
only
then
I
will
start
the
bug
fix
flow
and
we
will
perform
a
bug
fix
release.
B
B
That's
for
the
downstream
crw
stuff.
We
only
use
big
branches
for
now
that
they,
the
reliability.
B
B
So
my
guess
is
the
only
time
we
will
need
to
do.
A
bug
fix
release
is
some
kind
of
a
security
or
like
breaking
changes
for
upstream,
let's
say
kubernetes
deployments
or
stuff
like
that
that
are
not
really
related
to
downstream
stuff.
So
what
do
you
guys
think?
Should
I
stop
doing
the
bug
fix
releases
every
week.
A
I
thought
the
mainly
purpose
of
perfect
religious
is
downstairs
force
for
dharma
streaming
right.
B
Well
now
it
turns
it
turns
out
that
we
don't
need
it
like
just
that,
let's
say:
there's
the
content
in
chess
server
or
chateau
like
we
only
need
to
commit
the
changes
to
bugfix
branch,
but
we
don't
need
to
publish
a
release.
We
don't
need
to
build
images
with
the
tag
we
don't
need
to
like
create
even
really
create
tags.
For
that
reason,
because
the
in
dance
in
crw,
the
changes
are
taken
directly
from
the
bug,
fixed
branch.
C
D
E
E
Bugfix
releases
schedule
was
implemented
just
because
we
wanted
to
to
master
the
release
process
right
so
now
the
release
process
is
much
on
the
track
and
I
think
yeah.
It
makes
sense
not
to
do
the
bug
fix
releases
and
do
it
on
demand
only
so
plus
one
for
that.
D
D
C
B
Well
fully,
automated
is
a
good
word,
but
it's
really
isn't
like.
I
guess
the
biggest
time
loss
comes
when
we
create
operator
pull
requests
and
we
run
a
number
of
checks.
Sometimes,
though,
checks
are
flaky,
so
we
keep
respining
them
and
trying
to
figure
out
whether
it's
the
flakiness
of
the
test
or
is
something
actually
broke.
A
So
would
you
ask
your
personal
other
director
go
ahead,
plus
one
not
to
do
but
fixed
release
and
doing
on
demand,
because
I
say
remember:
basically
I
don't
remember
when
we
need
when
we
actually
do
some
bug
fixing
and
that
back
fixing
was
downstream.
G
Can
we
so
I
see
I
see
some
benefit
anyway,
on
releasing
more
often
that
was
not
exactly
more
often
releases,
because
we
were
just
releasing
the
x
branch
and
that
that
didn't
actually
match
to
that.
But
so
the
I'm
just
wondering
wouldn't
be
like
the
opportunity
to
start
like
trying
to
do
releases
every
week.
So,
instead
of
stopping
doing
the
the
fixed
releases,
could
we
just
switch
and
instead
of
doing
fixed
releases,
doing
the
stable
releases
every
every
week.
G
G
No,
no,
basically,
no,
no,
no
issues
that
are
that
go
in
those
fixed
releases,
but
if
we
instead
started
deploying
from
main
branch,
we'll
actually
get
more
things
and
yeah
just
just
thinking
out
loud
here,
if
you,
if
you
think
that,
because
anyway,
nobody
should
merge
anything
on
master
on
main
branch,
sorry
on
main
branch,
if
it's
not
ready,
if
it
has
bugs.
If
so,
the
quality
is
not
good
enough,
and
if
we
think
that
it
it
will,
it
can
become
a
problem.
G
We
should
not
just
not
merge
it
in
in
main
branch
because
or
any
other
contributor,
if
it's
in
main
branch
can
just
check
out
the
the
main
branch
try
to
to
use
j
or
try
to
contribute
to
j
and
will
fail,
because
somebody
has
has
pushed
something
that
is
not
good
enough
for
being
tested
and
by
some
some
users.
So
any
requests
that
emerge
in
main
branch
should
be
good
for
for
for
for
release.
Actually,
so
that
that
being
said,
I'm
I'm
thinking.
Why
should
we
transform
something
that
is
not
so
useful?
G
Our
our
weekly
fix
releases
in
something
more
useful,
that
is,
that
would
be
releasing
more
often
eclipse
j.
So
in
a
weekly
cadence.
B
Well,
I
guess
I'll
just
say:
outlawed
the
downsides
to
more
often
releases
one
is
potential.
2E
overload
well
just
just
in
general.
First
of
all,
the
really
major
release
is
slightly
more
taxing,
so
to
speak
than
a
minor
release.
It's
creating
new
x
branches.
It's
usually
contains
some
breaking
changes
to
which
he
also
has
to
adapt
like
rewrite
happy
past
tests
and
and
potentially
any
other
test
processes
that
they
have
so
but.
G
G
That
means
that
that's
all
and
if,
if
for
some
reason,
something
break
one
week,
not
the
end
of
the
world,
so
it's
not
just
that
you
you
have
so
it
doesn't
change
much
I
mean
but
anyway,
so,
let's,
let's
can
you
continue
going
so
moving
forward
for
that,
like
the
the
the
downside
I'm
interested
about
bringing
but
like
the
qe
having
too
much
things
to
do
is
like
yeah?
That's
they
need
to
work.
Do
some
work
every
week,
but
they
need
they
are.
They
have
less
work
every
week.
B
E
Yeah
for
me
just
it
sounds
like
a
good
idea
to
release
more
often.
I
just
think
that
we
need
to
align
it
with
the
product
releases,
then
somehow,
because
currently
we
have
sort
of
metrics
for
releases
and
with
the
new
approach,
I
think
we'll
need
something
different.
E
A
E
Yeah,
but
the
current
trend
is
released
with
every
commit
right
and
if
we
we
are
continuing,
you
know
releasing
three
weeks:
it's
just
not
not
something
that
that
is
trending
at
this
point
right.
I
know
that
operator
hub
is
not
very
good
with
releasing
with
every
commit,
for
example,
so
it's
just
not
meant
to
to
to
deliver
deliver
it
in
in
this
fashion,
but
I
mean
like
releasing
every
week,
sounds
like
relevant,
so
it
could,
even
if
we'll
continue
like
releasing
releases
of
eclipse
on
operator
hub.
G
G
We
can
still
continue
doing
the
release
on
operator
up
with
the
same
frequency
or
less
frequency
once
a
month.
Instead
of
so
it
depends.
So
if
we
can
do
that
every
every
week,
that's
perfect,
but
if
we
have
any
problem
doing
that
every
week,
I
would
not
stop
doing
the
release
weekly
because
of
operator
up
minutes.
We
we
plan
to
to
stop
releasing
on
operator
hub
anyway,.
D
So
I'm
just
curious,
given
that
we
already
have
the
next
builds,
what
would
having
more
frequent
releases
actually
solve,
because
if
you
can
already
install
today's
commit
without
having
to
wait
for
next
week,
wait,
why
do
you
need
an
officially
released
version
when
you
can
just
grab
the
current
like?
Doesn't
jctl
already
allow
you
to
go
from
next
to
next
to
next.
G
Yeah,
but
that's
not
the
fault
right,
so,
if
you're
a
user,
you
actually
get
like
three
weeks
old
things,
and
you
don't.
If
you
ask
for
a
fix,
you
don't
get
it
until
we
have
the
next.
The
next
stable
reason,
unless
you
want
to
go
on
the
nightly,
but
no,
not
everyone,
especially
if
you
have,
if
you
have
something
as
run
on
production,
want
to
go
on
the
on
the
nightly
one.
G
So
what
you're
proposing
is,
let's
go
even
further
and
let's
transform
the
the
stable
and
next,
the
next
steps
are
like
having
just
next
and
yeah
that
that
maybe
not
maybe
like
a
study
that
is
too
big
to
do
today.
So
we
can
just
do
something
in
the
middle
and
transform
stable
and
weekly
and
then
yeah
see
how
it
goes,
but
yeah
it
depends
on
how
orders?
B
Think
yeah
like
I
guess
it
would
be
important
to
ask
developers
pe
project
leads
or
managers
on
their
opinion
and
like
well.
What
are
the
products
of
cons,
of
making
more
releases
or
making
red
less
releases
so
that
we
understand
each
other.
A
Yeah,
that
would
be
nice,
so
could
you
start?
Could
you
write
to
jdf
a
mailing
list
called
call?
Thank
you
any
other
opinions
regarding
this
topic.
A
So
we
can
proceed
to
the
next
one.
There
was
space
article
publishing
planning
update,
but
by
elia
could
you
start
please
yeah.
E
So
folks,
we
we
are
having
the
issue
for
new
eclipse,
chat
blog,
and
I
told
you,
maybe
you
can
open
open
sure.
E
So
I
just
wanted
to
provide
an
update
that
originally
the
contributing
for
the
first
time
to
a
project.
A
blog
article
was
planned
for
the
3rd
of
january,
but
only
today
I
have
addressed
all
the
comments
after
the
video,
so
it's
planned
to
be
published
tomorrow.
If
there
are
no
objections,
so
it's
already
approved
and
the
rest
shed
you'll
probably
need
to
be
updated
accordingly,
because
it
might
slip
a
bit
and
for
our
team
we
are
having
also
yet
another
blog
post
planned.
E
It's
about
the
review
and
pull
requests,
and
I
just
wanted
to
double
check
with
valerie
about
the
status
of
the
pull
request.
Plugin
because,
as
I
understand,
pluginsteam
is
planning
to
get
rid
of
the
just
server
based
api.
That
is
involved
in
the
github
pull
request
plugin.
But
we
checked
with
debit
today
and
it
seems
that
the
plugin
sota
works.
E
So
I
just
wanted
to
figure
out
what
it.
What
is
the
plan
with
overall
github
pull
request
plugin
for
dev
workspace
engine,
because
it's
kind
of
works
at
this
point?
But
maybe
there
are
some.
You
know,
updates
planned,
because
this
plugin
is
basically
a
show
stopper
for
for
the
block
article
unless
it
works
as
expected.
I
think
it
doesn't
make
a
lot
of
sense
to
have
this
article
published.
F
Well
about
github
plugin
in
cathedra,
we
are
going
to
adopt
this
plugin
to
avoid
requesting
just
server
api,
which
is
used
by
for
generating
and
storing
tokens
for
github
operations.
So
I'm
I
haven't
just
I
haven't
tested
it
pull
request
plugin,
but
I
think
that
it
it.
It
may
have
some
problems
with
double
space.
E
Okay,
thank
you
so
david.
Maybe
you
you
can
shut
some
light
because
I
mean
david
just
checked
it
before
before
the
call.
So
I
was
wondering
I
mean
I
understand
that
we
need
to
remove
just
server
api
dependencies,
but
if
it
will
work
for
some
time,
then
it's
not
that
big
problem,
so
it
will
work,
for
example,
in
742,
and
then
once
you
will
be
ready
to
get
rid
of
this
api.
It
will
just
use
something
different,
but
will
continue
to
work
right.
H
Well,
well,
sorry,
I
should
clarify
that
I
I
haven't
meticulously
tested
it.
I
was
able
to
install
it
and
look
at
the
settings
open
the
preferences
and
verify
that
you
get
a
pull
request
plug-in
settings
over
there
but
yeah.
At
this
point
I
didn't
meticulously
test
it
for
approving
pull
requests
so
yeah.
Maybe
there
still
are
problems
with
the
dev
workspaces,
but
yeah
just
wanted
to
clarify.
H
I
I
need
to
look
into
it
and
make
sure
that
it's
it'll
be
working
for
the
roofing
pro
requests,
blog
posts
and
yeah
just
need
to
look
into
it
a
bit
more.
G
D
G
G
G
I
think
that
so
it
should
so
for
clarification
for
for
e
as
well
for
and
orders
for
any
any
plugins
that
require
access
to
the
chase
server.
Even
if
the
chat
server
api
is
still
there.
G
The
problem
is
that
there
is
no
the
the
plugin
should
not
have
any
notion
of
the
chase
server
url,
so
you
should
not
have
access,
so
it
doesn't
know
how
it
could
actually
contact
the
chase
server
api.
That's
that's
my
understanding
and
that's
why
it
should
not
work
is
that
there
is
no
environment
variable
that
where
we
set
the
offspring
of
the
chase
server.
E
G
No,
it's
for
that
particular
extension
the
each.
So
we
think
that
this
should
be
fairly.
G
We
should
there
should
be
not
a
lot
of
work
to
do
it's
just
that
when
you
are
you
log
in
so
you
so
today,
if
you
configure
your
che
instance
to
use
github
for
the
os
flow
at
that
point
and
you
try
to
access
to
a
private
github
repository,
we
create
a
secret
with
the
guitar,
your
github
token,
and
so,
if
that
github
token,
that's,
if
that
secret
is
there,
then
every
time
you
create
a
workspace,
you
actually
have
you
you
are.
G
You
are
able
to
use
the
github
request
plugin,
so
that
has
been
isotherate,
at
least
that
that
is
how
we
would
like
to
to
implement
that
so
through
through
just
the
secret,
that
is
in
the
namespace
of
the
of
the
users
that
is
created
server
side,
so
that
there
is
no
reason
to
call
the
server
api,
because
the
chase
server
creates
the
secret
with
the
token
and
the
extension
get
the
token
from
the
secret,
so
that
also
to
say
that
it
may
be
in
the
blog
post,
if
that's
not
already
comple.
G
If
the
the
feature
is
not
already
there,
maybe
we
could
just
mention
that
you
could
manually
create
the
secret
today
if
you
want
to,
but
that
can
be
also
automatically
create
and
will
be
automatically
created
by
che,
even
if
we
don't
have
that
that
feature
yet.
G
So
that's
just
an
idea
to
discuss,
maybe
to
be
to
discuss,
even
in
the
in
the
issue
that
valerie
has
provided.
C
E
Yeah,
because
the
the
one
that
I
think
that
the
the
one
that
is
interesting
is
the
issue
that
floran
posted
authentication
manual
flow.
So
my
understanding
that
for
blog
post,
we
can,
you
know,
use
a
few
short
cards
and
you
know
document
the
current
state
and
have
the
you
know,
manual
manual,
setup
documented
as
part
of
the
blog
post
and
link
it
with
the
issue
for
automation.
This.
E
So
my
point
is
that
we
don't
want
to
postpone
the
blog
post
till
this
flow
will
work
like
out
of
the
box
right,
but
to
more
or
less
be
on
on
the
schedule
and
document.
The
current
state,
for
you
know
january,
like
mid
january
right
with
this
pull
request.
Plugin.
E
G
Yeah
I
mean
for
this
second
issue
that
that
is
open
here
honestly,
I
I'm
not
sure
we
need
that.
E
E
G
F
So
he
can
started
this
issue
in
the
current
sprint.
Unfortunately,
so
we're
going
to
work
on
on
this.
G
Okay,
cool
so
an
eager
as
well
your
your
your
soul
may
be
so
it's
so
it's
it's.
Is
it
clear
so
for
wrong
comment
and
the
discussion
that
we
had
is
it?
Is
it
clear
what
what
you
need
to
do.
I
I
Or
we
just
need
to
provide
some
authentication
which
will
tell
user
what
to
do
to
create
that
secret
or
what.
G
Today,
so
I
I
mean,
the
idea
is
in
the
long
term
in
the
future
is
to
make
sure
that
we
always
have
so
at
least
in
che,
if
you're
using
che
chase
should
always
create
that
the
the
secret.
I
G
Yeah,
but
maybe
somebody
just
deploy,
create
a
dev
workspace
without
without
che,
so
maybe
this
this
token
is
is
so
the
secret
is
not
there,
so
you
need
to
be
prepared
of
it,
and-
and
if
you
find
so,
the
only
thing
I
would
do
is
provide
a
warning
message
to
the
user
saying
this:
the
we
are
expecting
a
secret,
it's
not
there,
so
it
won't
work
and
we
have
a
link
to
the
documentation
how
to
create
a
secret.
I
think
that
would
be
great.
G
That
would
be
really
great
because
then,
if
somebody
is
using
che,
it
will
actually
will
work
out
of
the
box.
If
it's
not
using
che.
Okay,
yes
decided
to
go
like
the
the
more
low
level
thing
and
yeah.
He
got
a
warning,
but
he
at
least
we.
We
helped
him
doing
some
manual
steps
that
will
allow
him
to
use
to
use
workspaces
with
both
chetia
and
with
the
github
request.
H
G
G
I
F
G
Yes,
we
okay,
so
we
show
warning
if
it's
not
with
some
instructions
and
the
instructions
will
should
all.
So
that
means
that,
if
the
token
is
the
secret
is
not
there,
I
follow
the
instruction
I
create
the
secret.
I
put
the
token
inside
the
secret.
At
that
point,
my
workspace
should
work,
so
I
should.
I
expect
the
github
request
extension
to
work
right
so.
G
Or
if
you
need
another
manual
step
like
the
user
need
to
restart
the
workspace,
I
hope
not.
I
hope
that
the
the
the
user
would
should
not
need
to
restart
the
workspace,
but
if
it
needed,
we
need
to
provide
that
in
the
in
the
in
the
instruction
in
the
documentation.
You
need
also
to
restart
the
workspace
but
yeah
I
don't.
I
don't
want
to
have
like
another
old
flow
from
within
tia,
because
that
that
is
so.
We
we
had
one
and
honestly,
it
was
really
hard
to
make
it
work.
We
had.
G
We
have
a
few
issues
with
that,
so
I
don't
think
it's
really
worth
to
continue
iterating
with
with
the
soul,
fixing
that
I
would
like
to
just
for
now
have
the
mechanism
of
the
secret.
So
no
oauth
flaw
from
tia.
I
Sorry,
mario
one
one
thing
just
to
clarify
this:
this
secret
gets
talking
from
the
oauth
floor
with
help
of
the
hs
server.
If
I'm
not
mistaken,.
I
A
Okay,
thank
you.
Thank
you.
Thank
you.
Everyone,
I
think,
do
we
have
anything
to
discuss
today.
Maybe
some
questions.
G
I
wanted
I
wanted
just
to
mentioned
that
we,
so
I
think
that
there
is
nobody
else,
but
only
people
from
red
hat
here.
So
I
think
it's
worth
mentioning
that
we
had
a
discussion
earlier
today
about
kotori
works
phases,
2.
G
There
is
a
request
to
actually
postpone
the
switch
to
2.16
so
to
continue
to
continue,
having
like
two
two
different
channels
into
that
incorrect
series:
2.15
with
one
of
the
that
is
using
the
chess
server
and
other
channel
using
the
experimental
channel
still
using
the
network
space.
G
This
is
due
to
some
problems
with
the
support
of
the
311,
because
once
we
switch
to
the
network
space,
we
won't
be
able
to
support
311.
So
we
want
to
support
311
for
a
few
months
still
and
that
allows
us
to
continue
supporting
it.
So
I
think
that's
that's
the
main
reason,
and
then
there
are
other
concerns
about
being
able
to
migrate
automatically
the
the
workspaces.
G
So
once
we
definitely
do
the
switch,
so
I
and
yeah,
I
think
that
qe
and
documentation
also
were
happy
to
postpone
it
because
the
they
were
not
able
to
actually
test
and
document
a
lot,
the
2.15
yet
so
that
workspace
enable
so
they
if
they
had
a
few
more
with
six
weeks
more.
I
think
that
they
were
happy
about
it.
So,
taking
into
account
all
those
things,
the
result
is
that
yeah
quaternary
workspace
2.15
will
still
have
chase
server
workspaces
by
default.