►
From YouTube: Fluent Community Meeting Oct 28th 2021
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
Awesome:
okay:
let's,
let's
start
with
the
release
process,
semantic
versioning
agenda
item
and
I
think
ashley
you
had
submitted
a
pr.
I
can
open
that
up.
If
that
works.
B
Yeah
an
issue
it's
42.35.
A
B
So
so
the
idea
is
basically
just
that
we
we
adopt
a
release,
process
and
versioning
process.
That's,
I
think,
is
more
standard
and
more
close
to
what
a
lot
of
other
projects
follow.
So
we
strictly
follow
semantic
versioning.
B
So
currently,
currently
we're
not
following
that,
because
in
the
final
version,
the
patch
version,
we
do
sometimes
launch
new
features,
and
so
then,
if
we
strictly
follow
semantic
versioning,
we
will
have
more
minor
versions.
So
then
the
proposal
is
that
we
have
a
monthly
cadence
for
minor
version
bumps,
because
that's
the
only
time
you
can
have
new
features
and
then
additionally,
since
currently
so
currently
like,
we
have
a
new
minor
version
series
like
once
a
quarter
and
then
we
do
patches
on
top
of
it
for
an
entire
three
months.
B
The
the
final
idea
is
that,
if
we're
doing
a
new
one,
every
one
month
that
we
should
have
patches
should
go
to
both
the
current
version
and
the
previous
version
so
like.
If
you
have
you
know,
1.9
in
november
and
1.10
in
december,
and
you
you
have
a
patch
on
comes
out
on
christmas.
B
Until
you
hit
january
and
then
you
actually,
then
you
you
deprecate
1.9,
because
then
it's
more
than
it's
more
than
two
months
old
and
yeah,
you
could
do
more
than
two
versions,
but
I
think
I
think
two
versions
would
be
pretty
reasonable.
I
think
folks
would
pretty
happy
with
that.
That's
what
I
was
thinking.
C
A
So
it'd
be
like
okay,
this
year,
we'll
probably
have
1.7
1.8
1.9
and
then
what
we
go
to
is
like.
We
have
1.10
11,
12
13
40.
like
every
month.
Essentially
we
have
a
new
feature
release
and
then
we
would
support
that.
The
latest
feature
release
with
any
patches
and
then
n
minus
one.
For
I
don't
know
the
the
length
of
one
or
two
months:
okay,.
A
Hey
so
hey,
he
said:
hey
eduardo
yeah,
we're
just
chatting
about
this.
This
new
versioning
proposal
for
semantic
versioning
for
fluid
bit
specifically
and
then
russell
just
went
over
a
bit
of
like
how
we'd
expect
it
to
work
where
we
basically
have
now
a
new
monthly
cadence,
which
are
features
only
or
sorry
not
features
only
but
we'll
allow
for
new
features.
A
But
if
we
do
patch
releases
say
at
the
weekly
or
bi-weekly
cadence,
those
are
only
for
fixes,
bug,
fixes
and
that
way,
if
your
user
gets
say
1.8.9
today,
they
might
get
new
features
in
the
current
current
way
we
do
releases,
but
in
the
future
they
would
only
get
patch
and
bug
fixes
in
the
patch
release.
E
E
E
E
E
B
Yeah,
I
was,
I
was
gonna,
say
that
so,
if,
if
you,
if
it's
too
much
work
to
actually
put
out
new
releases
for
everything,
but
the
like
current
most
active
series,
I
mean
that's,
that's
that's
not
the
end
of
the
world.
That's
fine!
As
long
as
we
could
just
like
get
the
get
the
tags
on
github,
yeah,
yeah,.
B
A
At
least
on
github,
so
maybe
I
I
think
we
we
have
a
a
good
set
of
decisions
here,
which
is
like
we
all
feel
that
stability
should
be
addressed
and
one
way
to
address
this
is
to
make
it
much
more
predictive
on
the
versioning.
What's
going
to
be
in
it,
I
think
we
can
all
agree
that
we're
we
can
look
at
like
this
monthly
feature
cadence
and
then
for
the
back
porting
of
the
the
patches
we
can
say
at
the
very
least
we
can
do
the
tag.
E
Yeah
cool
so
well,
we
need
to
agree.
I
think
that
we
should
work
in
just
one
series,
two
series:
I
think
that
is
more
complicated
right.
I
don't
agree
with
one
and
and
the
other.
The
other
thing
yeah
attack
should
be
fine
yeah.
I
have
serial
problem
with
that
yeah.
I
think
that
that
would
be
the
way
to
go
and
yeah.
How
often
we
make
the
major
release
mean.
E
B
Yeah
but
but
then
okay,
if
we
keep
the
the
new
series
only
starting
every
three
months,
then
you
have
to
wait
three
months
for
features
if
you're
strictly
following
semantic
versioning.
So
maybe
one
month
is
too
frequent,
maybe
two
months
better,
but
but
I
think
you
wouldn't.
I
don't
want
to
if
we're
going
to
follow
a
semantic
versioning
and
I
want
to
follow
semantic
versioning
strictly.
B
I
think
we
have
to
increase
the
speed
of
the
cadence
at
which
you
would
get
future
releases.
Otherwise,
right
now
you
get
features
very
very
occasionally
now
you're
saying
you
get
them
much
less
frequently.
Only
once
every
three
months.
E
Okay,
so
let's
take
a
look
at
this
from
a
different
way:
let's
use
semantic
version
as
an
inspiration
but
semantics.
If
we
followed
semantic
version,
it
will
not
work
for
our
users
right.
Our
primary
focus
should
be
the
users,
so
let's
use
semantic
version
as
an
inspiration.
This,
let's
take
what
works
for
us
from
there
from
them,
but
and
we
adapted
right
so
because
wesley,
I
think
that
actually
we
were
discussing
yesterday
with
other
folks
too.
It's
like
okay.
E
I
don't
know
if,
for
example,
we
as
caliph,
if
we
modify
our
calypto
plugin
yeah,
we
don't
want
to
wait
three
months
to
add
more
value
to
our
users
right.
So
what
we
said
if
we
said
inside
this,
the
plug-in
scope
for
that
is
maintained
by
the
vendor
or
by
a
company.
Specifically
I'm
talking
about
stackdriver,
s3
or
kalita
plugins.
E
B
Yes,
so
that
that
would
be
acceptable
to
me
as
a
trade-off
in
our
in
the
aedes
district.
We
do
follow
semantic
versioning
to
the
best
of
our
ability.
We
try
to
translate
what
we're
getting
from
upstream
into
a
strict
following
of
semantic
versioning.
The
reason
is
because
I
think
think
that
folks
understand
semantic
versioning,
because
it's
very
common,
at
least
for
my
users.
I
don't
want
to
introduce
a
new
versioning
scheme
because
that
they
have
to
like
learn
it's
best
if
it
just
follow
standard
practices.
B
So
that's
why
I'm
choosing
there.
I
would
prefer
to
do
the
same
in
the
the
upstream
project,
but
I
think
that
trade-off
of
core
is
guaranteed
to
only
have
real
non-bug
fixes
in
a
new
series,
but
plugins
might
have
features,
and
then
we
can
first
version
ourselves.
That's
acceptable.
E
Yeah,
because
if
we
make
a
monthly
guidance
of
my
versions-
sorry,
for
example,
minor
versions-
recall
right
now,
one
that
ate
at
eight
that
nine
that
is
out
today,
that
is
a
minor
version
right
that
one
can
be
out
anytime,
based
on
how
critical
are
the
issues
that
we're
fixing
right
and
that
happened
to
happen
to
aws
and
oil
companies.
Today
we
have
a
critical
issue.
This
customer
is
affecting
it's
a
bug,
fix
pretty
simple
yeah,
let's
ship,
a
new
version,
no
problem
with
that.
E
A
E
No,
the
thing
is
it's
like,
for
example,
with
minor
releases
like
one
that
dated
one
one,
that
data
two
that's
pretty
funny.
I
think
that
is
another
problem.
The
problem
is
that
we
say
we're
going
to
jump
between
one
that
they
want
the
time
1.10
every
month
it
will
be
a
mess
and
we
are
going
to
fragment
the
user.
Some
versions
right,
there's
a
downside
to
that.
That's
what
I'm
saying
if
we
follow
strictly
the
semantic
versioning
schema,
it
won't
work
for
our
own
development
phase
and
users.
Adoption!
E
That's
what
I'm
saying.
Let's
take
the
best
of
it
that
works
that
we
think
that
is
the
best
for
our
users,
because
maybe
in
other
projects
they
are
not
releasing
a
new
version.
Every
week.
Right
and
here
we
see
new
deployments
2-3
million
times
a
day,
and
people
needs
to
do
that
right
so
and
if
we
have
three
series
like
one
that
they
went
at
nine
and
one
to
ten
being
maintained
at
the
same
time,
it
would
just
lead
to
confusion
right,
maintain
different
release.
Note
the
backboarding
changes
will
be
get
more
complex.
E
A
D
Wow
so
the
model,
I
think,
an
enterprise,
is
it's
always
trying
to
use
the
stable
version.
It
goes
through
the
cycles.
If
you
only
give
the
image
and
they
want
to
use
the
official
stable
version,
then,
as
wesley
mentioned,
one
previous
minus
version,
minor
version
that
would
all
be
go
through
the
process
with
the
patches,
that
would
be
useful
right
and
they
won't
upgrade
right
away
or
take
moses
for
the
large
enterprises.
So
that's
why
we
say
we
conformal.
D
We
recommend
it
in
four
months,
previous
one,
for
example.
If
right
now,
it's
a
one,
six
one,
eight
minus
seven
point
x
with
the
major
fixes,
I'm
not
asking
you
to
fix
all
the
problems.
The
major
fixes,
selective
ones
like
when,
like
I'll
give
example,
if
there's
a
set
of
two
issues
or
some
three,
so
two
issues
or
some
one
issues
that
the
major
functionality
you
want
to
back
part
into
the
previous
version.
If
it's
a
minor
changes,
you
don't
need
to
backward.
A
D
B
D
D
That's
why
I
say
it's
just
a
process
in
place
to
review
it.
This
is
applied
to
previous
version.
How
big
is
the
impact
or
is
the
major
impact?
Is
the
shoe
stopper
merchant,
if
it's
just
minor,
just
leave
it
yeah
and
I'm
not
just
saying
it's
black
and
white.
You
have
to
do
everything,
it's
something
we
can
consider
to
us
practice
as
a
reviewer
right.
B
I
think
underdog,
though,
does
have
a
good
point
here.
This,
the
it
actually
might
not
always
be
easy,
because
if
you're
saying
you're
giving
patches
back
for
an
entire
six
months,
the
code
base
can
change
quite
a
lot.
It's
not
always
going
to
be
incredibly
simple,
like
oh,
this
feature
only
exists
in
one
series
like
you
could
get
weird
situations
where
the
code
is
kind
of.
B
E
E
One
that
eight
with
phones,
even
we
are
working
on
one
at
night,
so
we
are
developing,
it
has
not
been
released
and
we
push
a
fix
or
something.
Oh,
this
is
affecting
1.8
and
we
match
back.
Sometimes
it's
not
straightforward
change
right.
So
this
is
what
we're
going
to
differentiate,
because
we're
talking
from
upstream
development
here
right
for
a
company
who
wants
to
run
this
for
six
eight
bonds.
I
want
to
be
covered
and
be
secure.
E
What
you
need
is
a
long-term
support
version
right
and
at
least
that's
not
the
making
marketing
enough,
but
galitia
we're
going
to
do
that
for
our
customers
right,
and
that
is
a
bunch
of
work
right
so,
but
from
the
upstream
perspective,
I
think
if
that
company
is
really
curious,
running
just
every
six
eight
months
you
might
go
with
a
vendor
right
because
from
the
upstream
perspective,
that
is
a
very
tough
job.
You
have
to
do.
Validation
you
have
to
do
ci
test
integration.
E
E
For
the
answering
perspective,
we
cannot
do
six
months,
it's
really
hard,
because
our
development
cycle
is
really
fast
right,
but
I'm
okay,
that
we
should,
for
example,
I
would
like
to
once
we
release
1.9
right,
we're
not
going
to
speed
up
until
we
get
close
to
some
stuff.
When
we
sell
yeah,
we
can
maintain
one
to
eight
for
two
more
months
with
small
issues,
something
that
is
affecting
really
users
and
we
create
attack
for
it.
That's
fine,
but
going
beyond
that
is
going
into
the
lts
kind
of
scope
right.
E
So
I
think
that
that's
we're
not
discussing
here
right
we're
discussing
how
to
provide
more
stability
for
the
development
perspective
right
and
how
to
normalize
this
in
a
document,
and
my
tech
is
like
yeah.
If
you
speed
up
one
thing,
minor
version
we're
going
to
get
problems
with
the
major
versions
and
according
would
be
a
problem.
B
Okay,
I
am,
I
am,
I
think,
I'm
I'm
personally
happy
with
that.
So
if
you
you're
saying
that
upstream
will
do
not
not
for
the
full
six
months,
but
when,
like
1.9
starts
for
the
first
month
or
two
you'll
still
get
patches
on
1.8
and
then,
if
you
want
to
do
a
full,
true,
long-term
support,
that
has
to
be
a
vendor-owned
thing.
I
think
I'm
fine
with
that.
E
E
As
an
experience
we're
getting
that
with
talking
about
customers,
we
have
customers
that
are
asking
for
this
kind
of
thing
right
and
when
evaluating
this
kind
of
project,
it
means
engineering
team
means
more
than
upstream
resources
that
we
have
now.
So
that's
what
I'm
saying
so.
E
What's
the
I
think
that
we're
pretty
much,
I
would
say,
okay,
my
only
thing
would
be:
let's
make
this
kind
of
same
version,
a
strip
down
version
that
works
for
us
right,
because
five
comes
up
will
be
familiar,
but
let's
maintain
just
let's
one
one,
one
version
for
even
for
two
months.
I
think
it
should
be
fine
right,
but
we're
not
going
to
backboard
features
right.
Yeah.
A
Sorry,
as
a
as
a
time
check,
I
I
think
maybe
we
can
just
add
it
into
the
the
issue,
but
I
I
think
we
have
a
kind
of
go
forward
plan
and
then
we
can
just
add
to
the
issue
and
go
up.
I
think,
let's,
let's
go
bishol.
I
know
you
wanted
to
cover
the
fluency
tcp
settings
and
then
we
could
probably
do
if
folks
are
open
to
it.
Maybe
something
just
as
an
ad
hoc
november
for
improving
the
multi-line
filter
versus
duplicating
the
multi-line.
A
Too,
okay,
okay,
cool!
So
then
yeah
visually!
If
you
want
to
go
real
quick,
I
know
we
only
have
like
five
or
so
minutes.
Yeah
yeah.
C
Definitely
so
hey
guys,
thank
you
so
much
for
inviting
me.
So
basically
I
work
for
the
organization
autodesk
and
like
currently
I'm
working
on
the
fluency
solution.
We
are
using
it
heavily.
So
what
I
observe
we
have
multiple
fluency
machines
running
in
our
infrastructure
and
in
front
of
these
machines.
We
have
network
load,
balancer
and
in
front
of
network
load
balancer.
We
have
the
fluent
bit
so
what
I
observed
like
in
the
fluency
in
forward
plugin,
we
have
a
property
called
linger
timeout
and
the
default
value
of
that
property
is
zero.
C
But
the
problem
is:
if
we
set
it
zero
by
default,
then
it
claims
that
there
will
be
packet
drop,
because
the
general
scenario
of
finishing
the
tcp
connection
is
about.
It
will
basically
finish
it
properly
by
following
all
the
steps,
acknowledgement
finishing
this
kind
of
step,
but
in
this
case
it's
not
following
this.
Rather,
it's
resetting
the
connection,
and
for
that
whatever
the
packet
we
have
in
that
tcp
connection
will
be
dropped.
I
have
seen
it.
C
I
have
observed
it
and
like
we
have
some
packets,
which
are
basically
lost
by
keeping
this
value
zero
and
it
impacts
the
performance
also.
So
what
I
did
first,
I
modified
the
value
of
the
linger
timeout
just
make
it
some
higher
value,
rather
than
keeping
keeping
it
zero
it.
C
It
basically
minimize
the
reset
count,
but
still
we
have
then
I
went
through
some
documents
of
the
tcp
and
the
tcp
document
says
we
should
never
reset
the
connection
at
very
first
time,
rather
finish
it
first
and
then
whatever
we
have
apart
from
the
finishing,
we
should
reset
it.
C
So
for
that
I
created
a
document
on
medium
and
I
basically
presented
what
problem
I
faced
and
how
did
I
solve
that
problem
by
increasing
the
time
out
so
my
my
thing
is
like
we
should
have
some
more
tcp
settings
very
smooth
by
nature.
E
About
that
vishal,
would
you
please
put
all
that
documentation
in
this
meeting
notes?
Maybe
you
can
put
a
link
and
medium
might
might
not
be
the
best
way
to
engage
with
the
community.
Maybe
you
can
open
an
issue
on
github,
so
we
can
take
it
from
there
because
also
when
touching
the
network
in
defaults,
we
are
not
aware
about
what
changes
our
users
are
doing
right.
So,
let's
try
to
come
up
with
a
kind
of.
E
Maybe
there
are
two
ways
to
fix
it:
maybe
the
code,
maybe
as
a
good
practice
as
a
documentation
or
improving
documentation
for
different
use
cases.
So
just
please
open
a
github
issue
with
the
same
content
a
and
we
can
check
it
from
there.
So
we
can
pick
the
maintenance
of
that
part.
I'm
not
making
that
part
say
hey.
This
is
the
issue
that
autodesk
is
facing.
This
is
the
proposal.
A
I
just
added
your
medium
article
there
too
yeah.
I
think
this
is
great
thanks
for
thanks
for
writing
this
dishes.
We
need
more
content
like
that.
A
Okay,
I
I
would
say
for
the
multi-line
filter,
deprecating
multi
multi-line
filter.
Maybe
we
could
do
something
before
the
next
meeting,
which
is
one
month
after
I'd,
be
open
to
doing
it.
A
I
actually,
I
think
the
us
gets
into
the
thanksgiving
holiday
where
the
next
releases,
so
we
might
want
to
delay
it
a
month
or
sorry
a
week
or
so
so
I
would
propose
maybe
an
ad
hoc
community
meeting
for
30
to
45
minutes
just
on
the
multi-line
piece
and
then
one
two
to
three
weeks
after
for
just
continued
agenda
items,
it's
someone
object
cell
I'll,
go
ahead
and
schedule
some
of
those
things.
A
Where
will
that
be?
I
was
thinking
not
next
week,
but
the
week
after
on
thursday.