►
From YouTube: 2020-09-03 Spec SIG
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
C
C
B
Where
are
you,
where
are
you
based
out
of
robert
up
until
recently
I
was
in
ottawa,
but
with
my
company
being
remote
now
back
where
I'm
from,
which
is
winnipeg,
oh
cool,
do
you
know
where
that
is.
B
C
No,
I
I
know
some
canada
actually
there's
a
lot
of.
I
think
it's
like
all
the
waterloo
people
there's
a
lot
of
waterloo
people
at
datadogs,
so
there's
some
good
representation,
yeah
I'm
from
philadelphia.
So
I
don't
know
canada
yeah.
That
was
nice.
B
C
B
D
C
For
sure
I
think
it's
I
think
it's
it's
definitely
an
adjustment,
but
it
creates
some
good
practices.
If
you,
if
you
try,
I
guess
so.
Yeah.
C
In
florida
I'm
in
paris,
but
I'm
I'm
from,
I
lived
in
new
york
for
a
long
time
and
then
my
wife
and
I
moved
out
here
for
her
job,
seven
yeah
coming
so
it's
late
here.
It's
six
o'clock.
B
C
Sorry,
what
was
that
is
matt
matthew?
Where
is
he
on
ptl.
B
C
C
Oh
I
apologize
is
he
on
vacation?
Oh.
B
B
A
A
A
A
A
Probably
suggest
waiting
just
a
couple
more
minutes
in
case
he
does
show
up.
I
don't
really
have
the
background
to
run
through
the
spec
sig
update.
F
A
Yeah
he
said
he's
in
a
meeting:
that's
going
along,
we
can
start
without
him
and
he'll
show
up
soon
cool,
so
yeah.
I
don't
have
a
whole
lot
other
than
we've
got
some
prs
in
flight
at
the
moment.
A
I'm
trying
to
wrap
that
up,
probably
tomorrow
at
this
point
I've
got
a
bunch
of
meetings
this
afternoon
the
jaeger
collector
exporter
is
almost
done.
Robert
gave
me
some
pointers
for
the
client
auth.
Sorry,
the
basic
auth
support
so
I'll.
A
A
So
I
think
those
are
the
key
three
items.
I'm
just
going
to
bring
up
milestones.
A
Michael
looking
at
the
support
for
the
standard
environment
variables
in
the
sdk,
so
we're
supporting
most
of
those
at
the
moment,
the
key
ones
that
we're
not
dealing
with
right
now
other
than
the
otlp
exporter
related
things
are
hotel,
log
level
and
overtold
propagators.
A
C
Yeah,
I
can,
I
saw
you,
mark
the
jaeger
collector
exporter
for
review
overnight,
so
I
can
take
a
look
at
that.
You
know
I've
been
a
little
behind
on
taking
a
look
at
some
of
the
prs
and
then
otlp
had
been
pretty.
I
can
give
that
another
look.
If
you
want,
I
think
the
last
yeah
there
was
one
or
two
to
do's
is
that
is
that
good
to
go?
I
guess.
A
I
have
sorry
I'm
just
taking
off
the
two
days.
I've
done
I've
added
the
remaining
items
to
a
to-do
list.
I'm
gonna
punch
a
handling
of
redirects
to
a
subsequent
pr.
Gzip
requires
some
upstream
support
in
the
collector,
so
the
remaining
items
are
user-specified
headers,
which
should
be
pretty
easy
to
add.
A
I
have
implemented
group
by
span
resource.
I
just
need
to
make
the
test
a
little
bit
more
robust
for
that
environment.
Variable
config
should
be
pretty
trivial.
I've
implemented
that
in
the
jaeger
exporter
and
then
I'm
proposing
to
rename
the
gym
to
open
telemetry
exporter
otlp
http,
to
clarify
that
like
this
is
export
number
http
and
then
later
we
can
have
an
open,
telemetry,
export
or
otlp
grpc
version
as
well.
That
way
people
can
pick
which
exporter
they
want
if
they
don't
want
to
take
a
dependency
on
grpc,
okay,.
A
B
For
the
dolly
gem,
I
saw
that
there
were
some
comments
left
there,
so
I
guess,
does
it
make
sense
to
shift
it
from
instrumenting
at
the
client
level
to
like
the
server
patch
instead,
like?
Should
I
just
go
ahead
and
switch
that
over?
I.
A
A
C
You
get
some
better,
you
do
pick
up
the
full.
I
think
the
one
trade-off
to
be
clear
about
is
for
the
mo
when
you're
doing
whatever.
Like
a
multi
query,
I
think
you'd
lose
some
of
the
visibility
into
what
the
you
might
only
get
the
individual
queries,
which
is
maybe
fine
and
that
span
would
be
a
series
of
smaller
spans
instead
of
one
longer-ish
span,
yeah.
A
Like,
ironically,
our
complaint
with
our
instrumentation
internally
was
when
you
do
a
multi-get
that
hits
multiple
servers,
you
don't
get
visibility
into
the
individual
requests,
which
is
what
you
really
want
and
yeah
there
you
go
so
yeah.
Clearly
we
had
a
path
forward.
We
just
didn't
know
what
it
was.
So
thanks
for
that.
C
Yeah
no
problem,
I
just
looked
at
what
some
guy
did,
did
it
all
through
whatever
I
noticed
the
delta
was
there
that
there
was
a
small
difference,
cool
but
yeah
I
mean
it
did.
Look.
It
looked
pretty
good,
there's
some
tests.
I
guess
that
we
should
fill
in
on
just
some
of
the
you
know
basic
just
some
of
the
unit
test
stuff
but
yeah,
but
the
instrumentation
looked
really
solid.
Yeah.
B
C
B
Yeah
because,
like
honestly,
I'm
just
kind
of
figuring
out
the
layout
for
this
project
in
terms
of
ci,
like
I
haven't,
made
much
changes
there
like
there's
the
the
docker
file
or
the
docker
compose.
I
added
like
that's
only
for
the
local,
your
local
setup
right,
so
I
haven't
actually
tested
that
yet
gotcha.
A
I
was
just
going
to
say
just
be
aware
that
we've
moved
from
circle
ci
to
like
github
for
ci,
github
actions,
and
so
the
circle
configuration
that
you
pointed
me
out
previously
is
actually
the
wrong
place.
To
change
to
to
add
this,
you
need
to
go,
and
I
think,
there's
like
a
ci
directory
with
some
shell
scripts
in
it
for
some
of
the
tasks.
So
there's
one
there
for
running
stuff
like
mysql
needs
a
container
brought
up.
So
you
probably
need
to
add
something
in
there.
B
E
Because
I
wasn't
sure
what
was
happening,
we
should
do
it.
Okay!
Yes,
sorry
that
the
there's
a
bunch
of
cleanup
that
we
haven't
yet
done
since,
since
we
moved
over
to
github
actions
so
yeah,
that's
that
needs
to
be
done.
B
A
A
Cool,
if
there's
nothing
else,
maybe
we
can
throw
it
over
to
matt
for
the
specific
update.
D
C
G
G
G
So
yeah
we're
we're
still
running
up
to
ga
and
a
lot
of
the
the
meeting
has
just
been
kind
of
going
through,
like
triaging
the
new
stuff
that
comes
in.
So
these
are
all
just
like
general
stats
around
that.
G
So
yeah,
I
guess
that
brings
us
down
to
just
these
last
few
bullet
points.
A
lot
of
that
meeting
was
was
general
triage
around
stuff
running
up
to
ga
of
of
things
that
were
kind
of
like
up
up
to
debate.
G
G
Probably
the
most
yeah-
I
guess
one
of
the
biggest
things
that
has
been
going
on
at
a
spec
level
is
the
reason
why
I
was
so
late
to
this
meeting
and
it
was
kind
of
touched
on
at
the
spec
meeting
but
kind
of
deferred
until
this
morning.
Talking
about
adding
this
error
hint
semantic
convention,
basically,
we
have,
like,
I
don't
know,
finding
consensus
on
errors,
how
to
record
errors
and
how
to
ultimately
do
something
like.
G
We
have
not
gotten
to
this
point
yet
in
open,
telemetry
and
like
we
at
least
got
to
a
point
where
you
can
record
exceptions
as
events
on
your
spans,
which
is
good.
It
took
a
lot
of
work
to
get
there.
G
I
think
there
is,
though,
the
conversations
quickly
turn
into
like
who
who
can
possibly
tell
definitively
what
what
is
an
error
and
that's
why
we
went
with
calling
these
exceptions
to
begin
with
is
because
you
can
at
least
identify
that
there
was
an
exception,
but
I
think
there
are
a
lot
of
people
who
are
of
the
mind
that
well
I
mean
it
is
true
that
errors
are
going
to
be
subjective
based
on
like
application
and-
and
you
know,
other
scenarios
that
aren't
always
detectable
by
code
and
I've
always
kind
of
commented
from
like
these
are
actually
back
end
features.
G
I
had
a
pr
up
that
did
this
and
through
through
that
discussion,
the
error,
the
error,
hints
semantic
eventually
got
a
little
bit
more
complicated,
it's
something
that
was
recommended
that
you
added
on
the
event
that
caused
the
hint
as
well
as
the
span
that
has
the
hint.
So
you
can
potentially
link
these
up.
You'd
have
multiple
exceptions
on
a
span,
but
only
one
might
have
the
the
the
error
hint
and
it
got
complicated.
G
G
People
don't,
like
I
don't
know
for
some
reason,
there's
like
a
huge,
a
huge
there
yeah
and
there
are
people
who
think
that
there's
no
reason
to
have
this,
on
the
record
exception
api
that
you
can
just
use.
You
know
event
set
attribute
and
spam
set
attribute
and
just
read
it
through
all
the
semantic
inventions
and
know
all
the
fine
details
about
them,
and
just
you
know
put
this
on
your
telemetry
properly
all
the
time
and
it's
no
big
deal
like.
G
So
it's
had
me
like
walking
back
my
error,
hint
idea,
all
together
and
basically
saying
I
think
we
were
better
off
with
span
status,
which
is
kind
of
the
other
thing
that
we
have
and
like
I,
I
can't
recommend
that
we
re
they're
talking
about
removing
expand
status
and
this
would
be
a
potential
replacement
for
spam
status
and
I'm
kind
of
holding
firm
on
the
line
that,
like
without
an
api,
to
use
this
air
hint
properly.
G
We
are
better
off
as
fan
status,
so
with
this
last
meeting
that
I
was
in
was
a
huge
bike
shed
around
all
of
this.
To
be
honest,
I
don't
even
know
how
it
ended
at
this
point,
but.
G
D
Because
I'm
feeding
that
would
not
end
you
had
to
get
kicked
off
on
this
team
coming
in
yeah.
It
just
doesn't
circle
in
certain
circles.
At
the
end
of
the
day,
as
long
as
you
have
the
facilities
in
place
to
start
arrows
or
something
hands
to
whatever
you
have
to
do
so
and
propagate
and
be
interpreted
later,
we
stopped
figuring
out
what
exactly
is
supposed
to
be.
I
think
it's
going
too
deep
with
it.
G
Yeah
I
mean
I
personally
think
it
is
essential
for
a
telemetry
system
to
be
able
to
tell
you
an
error
rate
or
highlight
a
span
like
this
is
my
whole
reason
for
kind
of
being
involved
in
this
situation.
Like
it's,
it's
been
a
lot
harder.
I
mean
I
never
expected
any
of
this
would
be
easy
but
like
how
hard
could
at
adding
a
boolean
semantic
convention
and
a
convenience
wrapper
around
it,
be
if
you
ever
find
yourself
asking
yourself
this
question:
don't
ever
come
back
thinking?
Oh,
it
should
be
easy
or
reasonable,
but.
C
Datadog
ends
up
just
having
a
status
of
one
or
zero
for
what
it's
worth,
which
is
not
great
because
then
it's
just
you
have
to
infer
with
all
these
tags
what
it
really
means
but
like,
and
I
thought
the
hint
was
a
nice
way
on
top
of
having
exceptions
like
more
finely
tuned
except
multiple
possible
exceptions.
C
G
I
feel
like
there
are:
there
are
at
a
bare
minimum
individuals
with
opinions.
I
don't
know
that
their
opinions
necessarily
reflect
that
of
an
entire
vendor,
but
right
yeah.
I
think
if
you
get
enough
opinionated
people
in
the
same
room,
it
will
be
impossible
to
reach
an
agreement
and
I
think
that's
just
kind
of
what
we're
running
into.
C
Well,
while
we're
here
actually
one
question,
I've
been
curious
about
is
like
in
the
open,
telemetry
sense.
If,
if
you
just
wanted
to
say,
like
I
don't
know,
calculate
hits
and
errors
on
your
sinatra,
application
is
what's
like
the
way
of
doing
that,
and
is
it
that
you're
supposed?
Should
it
be
that,
like
the
sinatra
instrumentation
provides
metrics,
which
we
would
export
at
the
metric
xpi?
C
A
So
there's
no
convention
for
this
there's,
I
I
think
in
an
ideal
world
we
would
have
implemented
metrics
and
then
we
would
be
capturing
metrics
for
this
and
the
sinatra
instrumentation
as
well
and
exporting
those
the
collector
itself
right
now
does
not
have
support
for
effectively
extracting
metrics
or
synthesizing
slis
from
the
trace
data
that
it's
seeing
the
span.
Data
back
ends
typically
provide
that
capability.
So
you
know
light
step.
Has
that
ability
and
like
splunk
or
ammunition
as
it
used
to
be
provides
that
capability
as
well?
A
But
it
is
not
functionality,
that's
built
into
the
collector.
It
is
something
that
shopify
is
considering
building
for
the
collector.
So
we
may
add
that
at
some
point-
and
I
think,
there's
community
interest
in
that
as
well,
I
feel,
like
I've,
seen
open
issues
in
the
collector
repo
where
people
are
asking
about
that
functionality.
C
Yeah,
it
seems
pretty
like
a
core
thing
you
would
want
out
of
like
yeah.
I
just
wasn't
sure
if
we
missed
it
and
if
we're
not
getting
it
in
ruby
because
we
don't
have
the
sdk
for
metrics
or
whether
it's
just
because
there's
no
real
like
is
there
a
language
out
there?
That's
doing
this
at
the
application
level,
I'm
not
sure
so.
A
There's
there's
two
things
that
we're
missing
in
ruby
one.
Well,
sorry,
there's
one
thing:
we're
missing
in
ruby,
which
is
metrics
sdk
implementation,
but
the
other
thing
that's
missing
more
generally
in
optometry
is
like
metrics
is
a
little
later
to
mature
than
tracing
was,
and
I
think
we
haven't
established
yet
what
kinds
of
things
instrumentation
should
be
tracking
for
metrics.
So
we
don't
have
the
same
detail
around
semantic
conventions,
cool,
okay,
that
thank
you.
It.
G
Helps
yeah,
so
I
guess
we
can
wrap
up
this
wrap
up
the
specs
egg.
I
think
the
other
thing
that's
really
kind
of
going
on
is
defining
the
exact
semantics
of
kind
of
open
tracing
compatibility.
It's
always
been
a.
G
It's
always
been
on
the
list
of
things
that
is
expected
from
open
telemetry,
but
I
think
a
lot
of
the
details
were
kind
of
hand
waved.
I
know
there
has
been
quite
a
bit
of
work
with
this
guy.
G
Carlos
has
been
doing
around
formally
specifying
it,
and
I
think
they
were
talking
about
having
to
add
a
parent
reference
type
to
distinguish
between
sink
and
async
children,
and
that's
really
the
the
child
of
or
follows
from
semantics
from
from
open
tracing
and
their
things
are
a
little
bit
different
in
in
open
telemetry.
It's
we
kind
of
have.
G
I
think
I
think
this
was
something
complicated
is
was
kind
of
the
result
of
that.
The
little
discussion
we
had
at
the
spec
sig,
and
there
were
some
questions
as
to
whether
anybody
in
open
tracing
really
had
great
support
for
this
and
would
be
missing
it
if
it
were
kind
of
fudged
in
the
in
the
compatibility
layer,
and
I
think
they
were
because
it
was
looking
a
little
complicated.
I
think
they
were
going
to
kind
of
research
what
what
the
implications
would
be
if,
on
that
particular
issue,.
A
Has
there
been
any
discussion
about
open
census
compatibility
and
what
that
will
entail.
G
That
there
hasn't
been,
there
hasn't
been,
it's
been
suspiciously
like
not
talked
about.
I
know.
We've
had
some
informal
talks
here
about
it
and.
G
And
have
had
some,
I,
like
the
the
tldr.
My
takeaway
is
that
census,
ruby.
G
I
don't
know
where
it
actually
landed
in
terms
of
official
versioning,
but
the
project
had
tracing
it.
Never
really
fully
had
metrics
and
the
the
known
set
of
users
was
like
fairly
small
and
most
of
them
seemed
pretty
interested
in
adopting
open,
telemetry
or
like
they
would
likely
could
be
encouraged
to
just
adopt
open
developmentary.
E
E
I
I
have
serious
doubts
that
it
is
at
all
worth
the
effort
to
to
include
any
compatibility
layer.
G
Yeah,
so
I
think
I
think
that
is
an
important
topic
that
we
should
probably
bring
up
just
to
make
sure
that
we're
clear
on
expectations
for
things,
but
it's
definitely
a
thing
that,
like
I
haven't
heard
anybody
talking
about,
I
haven't
seen
in
any
of
like
it's
not
in
the
current
matrix.
I
don't
know
if
open
tracing
is
there,
but
open
tracing
is
something
that
has
regularly
come
up.
G
I
guess
I
think,
since
the
beginning
of
open
telemetry,
there
has
always
been
kind
of
a
proposal
for
how
things
would
work
with
with
open
tracing,
and
it
has
always
been
like
it's
always
kind
of
an
actionable
proposal.
I
would
say,
like
the
fine
details
haven't
always
been
hammered
out,
but,
like
I
never
saw
I've
never
seen
anything
similar
for
census.
G
The
the
the
most
I've
seen
was
kind
of
some
hand-wavy
things
where
open
telemetry
api
would
be
close
enough
for
for
a
lot
of
things
and
yeah.
This
is
this
is
from
a
long
time
ago,
but
it
was
basically
like
there
would
be
a
version
of
open
telemetry
that
would
be
close
enough
to
census
that
you
could
use
it
and
then
you
could
deprecate
quickly
the
things
that
were
census
related,
but
that
was
a
plan
that
I
heard
about
maybe
around
last
summer's
time,
and
I
don't
think
that
that's
possible
any
longer.
G
So
yeah
and
then
kind
of
the
last
thing
was
in
this
run-up
to
ga
like
there
are
like
a
lot
of
issues
coming
in
or
it
seems
like.
A
lot
of
people
are
like
trying
to
get
their
thing
into
open
telemetry.
I
guess-
and
I
think
there
was
just
a
little
bit
of
a
discussion
about
for
ga
we're
just
trying
to
get
like
mvp
more
than
anything
and
additions
are
fine.
G
After
the
fact
like
additive
changes
are
not
a
big
deal,
we're
just
trying
to
make
sure
that
we
have
a
minimum
viable
product,
a
and
b
that
the
things
that
we're
going
to
ship
as
part
of
that
and
call
kind
of
stable
are
going
to
be
around
for
a
while.
G
So
the
it's
not
necessarily
a
race
to
get
everything
in
before
ga.
It's
not
like
you
can't
add,
but
it's
it's
more
about
firming
up
the
things
that
we
have
committing
to
supporting
the
things
that
we
have
and
making
those
kind
of
changes,
and
then
also
just
making
sure
that
mvp
things
that
we
need
for
the
core
functionality
are
there.
G
But
for
for
other
stuff,
that's
additive.
We
can
still
do
that
and
we
are
going
to
have
to
define
kind
of
since,
since
we
are
kind
of
doing
this
rolling
ga
like
how
do
how
do
new
things
come
in,
I
guess,
and
how
to
officially
how
to
officially
identify
things
as
experimental
etc,
but
yeah.
That
was
really
the
conversation
around
this
last
bullet
point.
G
F
C
That's
about
all
I
have
for
the
spec
sig
any
when,
if
you
had
to
guess
you
think
ga
happens
next
week
in
two
weeks
october
for
tracing
this
tracing
signal.
G
So
technically,
technically
tracing
was
supposed
to
be
done,
or
it's
supposed
to
be
done
tomorrow.
This
week
this
week
is
supposed
to
be
kind
of
like
the
the
drop
dead
date
on
that
stuff
and
after
that,
it's
kind
of
like.
I
think
the
tc
has
some
kind
of
you
know
enhanced
abilities
to
make
decisions
on
things
that
have
been
kind
of
blocked.
G
So
I
think
they're
kind
of
sticking
to
that.
As
far
as
I
know,
I
know
this
error
hint
stuff
is
it's
technically
kind
of
needed
because
of
you
do
need
backwards,
compatibility
for,
say,
open
tracing
and
the
error
equals
true
tag
was
a
thing
that
a
number
of
open
tracing
back
ends,
supported
and
had
special
behavior.
For
so
not
having
a
way
to
be
able
to
translate
to
error
equals
true
or
false
on
a
span
is
would
kind
of
degrade.
C
So
that's
already
pretty
degrading
sorry,
my
bad
I'm
having
a
bad
day.
G
Yes,
but
it
I
mean
we
should
limit
the
degrading,
I
think,
but
I
feel
like
there's
this
other
batch
of
adjacent
issues
that
have
to
kind
of
be
that
you
can't
totally
separate
from
the
trace
ga.
This
is
my
opinion.
I
think
maybe
this
is
understood
at
a
larger
level,
but
I
don't
have
enough
context
to
understand,
but
that
is
actually
the
context
portion.
G
So
there
are
like
some
some
things
around
context
that
need
to
be
decided
and,
like
I
feel
like
this,
has
to
be
understood
because
as
stable
as
your
saying,
api
is
like
your.
The
individual
projects
are
not
going
to
work.
You
know
with.
E
F
C
Okay,
that's
a
good,
that's
good
context.
It
sounds
like
after
this
week,
people
will
sort
of
make
reasonable
decisions
and
get
things
out
in
the
next.
In
the
coming
weeks.
G
Yeah
yeah,
so
I
think
the
context
stuff
is
the
next
batch
of
stuff,
but
it
does
seem
like
I
think
people
are
really
committed
to
gaining
soon
and
you
know
not
like
forever.
C
C
G
F
I
have
another
topic
if,
if,
if
we
can
move
on
to
another
topic,.
E
So
I've
been
I've
been
working
on
the
release
process
release
scripts.
There
was
there
was
some
earlier
desire
to
to
see
if
there's,
if
we
can
do
things
like
generate
change,
log
entries
automatically
and
so
forth
turns
out
it's
nice
timing,
because
I
actually
had
to
be
working
on
this
for
several
other
projects.
At
the
same
time,
so
I've
been
prototyping
some
of
these
ideas.
It's
it's
a
number
306
in
that
in
the
list
there.
E
So
I've
been
prototyping
these
ideas
in
in
another
project,
the
cloud
events
sdk.
Basically,
the
this
centers
around
conventional
commits,
which
is
a
standard
for
commit
messages
in
which
you
you.
Basically
you
tag
your
commit
messages
with
a
type
and
you
have
a
kind
of
a
standard
format
for
at
least
the
first
line
of
a
commit
message.
E
By
doing
this,
you
can
identify
commits,
as
you
know,
things
you
can
identify
things
like
breaking
changes.
You
can
identify
features
versus
bug,
fixes
things
like
that.
That
can
then
feed
into
semantic
versioning
and
so
forth.
So
we've
been,
we've
actually
been
using
this.
So
so
the
idea
is
you
can
then
you
build
tooling
around
this?
E
You
can
you
can
analyze
commit
messages,
decide
you
know
if
you
want
to
do
a
release,
what
should
the
the
release
version
be
build
out
a
a
change
log
based
on
those
commit
messages
and
so
forth?
So
we've
actually
been
using
a
bunch
of
tooling
that
we've
we've
built
in
house
at
google
for
for
a
lot
of
google's
libraries
in.
E
Useful,
for
you
know
this
mass
automation
like
we,
so
we
maintain,
like
hundreds
of
api,
client,
libraries
and
manually
editing,
change,
logs
and
so
forth,
would
just
be
a
pain
in
the
ass.
So
we
so
we
have
all
this
automation
around
and
it's
basically
around
conventional
commits.
E
So
what
I've
been
doing
is
kind
of
porting,
some
of
the
tooling
that
we
have-
or
at
least
some
of
the
at
least
the
ideas
that
we
have
in
our
google
tooling
over
to
apply
to
projects
like
open,
telemetry
and
like
like
cloud
events
and
some
of
the
other
products
that
I'm
involved
with.
So
there
are
two
things
here
number
one:
this
these
techniques
will
depend
on
us
if
we
want.
E
If
we
want
to
adopt
this,
we
we
have
to
adopt
conventional
commits,
and
so
it's
kind
of
a
so
I
guess
that's.
The
first
thing
is
for
for
the
group
is
that
something
that
we
are
interested
in
doing
so?
That's
something
that
we're
willing
to
do.
Basically,
it's
it
means
there's,
there's
a
particular
format
that
the
first
line
of
of
all
your
git
commit
messages
should
should
follow.
If
a
commit
message
does
not
follow
it,
then
it's
not
a
big
deal
it
just.
E
Doesn't
it
just
means
that
our
you
know
we
won't
be
able
to
detect
things
like
you
know.
Is
this
a
feature
edition?
Is
this?
You
know
what
what
what
sort
of
thing
is
this
and
therefore,
when
we
build
out
a
change
log
automatically
it
won't.
It
won't
include
it
when
we
decide
what
version
bump
the
next
release
should
have
based
on
semantic
versioning.
We
won't
be
able
to
semantically
analyze.
This
particular
commit.
E
So
it's
so
it
is
it's
not
the
end
of
the
world,
but
it
is
still
important
that
our
commits
do
follow
conventional
commits.
So
so,
basically,
that's
that's.
The
first
thing
are
we
are.
Would
you
be
okay
with
adopting
conventional
commits?
E
The
second
thing
is:
if,
if
that
is
the
case,
then
I
can
go
ahead
and
implement
the
the
release
process
and
what
that
would
look
like
is
basically
spelled
out
here
generally,
so
what
I've
been?
What
I'm
doing
in
the
the
cloud
events
sdk
is
it's
based
on
github
actions.
Basically,
what
you
would
do
is
you
go
to
the
github
actions?
Tab
and
and
there's
a
way
to
manually,
kick
off
a
workflow.
E
Just
this,
basically
there's
a
button
that
you
can
press
in
the
the
github
ui.
So
if
you
want
to
kick
off
for
release,
anyone
who
has
write
permission
in
the
the
repo
can
do
it
and
you
would
just
go
into
dui,
you
would
you
would
press
a
button
and
they
would
and
there's
a
a
field
where
you
can
specify
either
which
gems
you
want
to
release,
or
you
can
leave
it.
E
Blank
and
they'll
just
go
through
and
and
figure
out
which
gems
have
semantic
changes
since
the
last
release
of
that
gem
and
what
it
will
do
is
we'll
actually
open
the
pull
request
for
each
of
the
gems
and
the
pull
request
will
include
bumping
the
version
and
a
kind
of
an
initial
change
log.
E
That's
automatically
generated
from
the
commit
messages
and
then
in
the
pull
request,
you
can
look
at
it,
so
you
can
do
things,
you
can
either
accept
it
as
it
is,
or
you
can
change
the
version.
If,
if
you
want
to
to
release
as
a
different
version,
you
can
edit
the
change
log
in
the
in
the
pull
request
and
and
then
you
can
merge
it.
E
If
you,
if
you
say
we
don't
want
to
do
release,
you
can
just
close
it
close
the
the
pull
request
and
it'll
just
go
away.
If
you
merge
the
pull
request,
then
what
will
happen
is
an
automatic
workflow
will
will
get,
will
get
kicked
off?
That
will
go
ahead
and
do
the
release.
E
That's
what
kind
of
that
what
that
would
look
like
if
we
are,
if,
if
we
would
like
to
do
this,
if
we're
okay
with
adopting
conventional
commits
and-
and
we
like
a
workflow
that
looks
like
this
francis,
I
know
you,
you
added
a
comment
here
about
breaking
changes
for
for
pre-ga
and
yes,
the
the
yes,
the
scripts
do
do
that
correctly.
E
So
do
people
have
opinions
about
this,
are,
is
convinced,
are
people
willing
to
adopt
conventional,
commit
messages?
What
what
what
what
people
think
about
this
yeah.
A
E
A
My
perspective,
I
think
this
is
good
and
it
it
helps
with
the
release
workflow
significantly,
it's
going
to
take
a
little
getting
used
to
mostly
you
know,
making
sure
that
our
commit
messages
are
meaningful
and
clearly
identify
things
like
breaking
changes
and
fixes
and
so
forth,
but
it's
more
about
like
breaking
some
bad
old
habits
and
creating
some,
hopefully
better
new
habits.
G
Yeah,
I
was
gonna
say
I
would
be
on
board
with
this.
I
believe
they're
using
this
on
the
javascript
project.
I
kind
of
found
out
about
this,
just
because
there
is
a,
I
think,
it's
like
a
pre-commit
hook
or
something
that
runs.
G
So
I
think,
there's
some
tooling
that
you
can
set
up
it's.
This
thing
called
husky
at
least
that
you're,
using
on
javascript.
That
will
basically
like
your
the
default
is
if
your
message,
your
commit
message
that
does
not
conform
to
to
these
conventional
convent
commits
like
your
commit,
will
not
go
through.
G
I
think
you
can
override
it
or
something,
but
that's
the
thing
that
we
could
do.
I
guess
I
I
will
take
this
opportunity
to
ask
a
few
questions
about
how
to
make
the
best
use
out
of
conventional
commits,
because,
like
the
only
thing
that
I've
done
in
at
least
on
js
is
try,
try
my
best
to
have
the
right.
What
I
think
might
very
possibly
be
the
right
keyword
in
front
of
my
message,
but
I'm
not
always
sure
what
that
should
be
so
like.
G
I
guess
I
ultimately
have
like
two
questions
around
that,
and
one
is
like
how
important
is
this
on
your
individual
commits,
given
that
we
like
squash
and
merge
in
the
end
like?
Does
that
squash
and
merge
commit?
Is
that
the
only
one
that
really
needs
to
have
the
right
message?.
E
Yes,
it
is,
they
commit
whatever
commits
that
get
that
ends
up
in
the
permanent.
You
know
get
git
repository,
that's
the
one
that
matters.
E
E
That
does
mean
that
we
do
have
to
have
there's
basically
a
one-to-one
correspondence
between
commits
and
lines
in
the
change
log,
so
it
does
mean
some
discipline
about
the
size
of
our
commits
or
the
scope
of
of
our
commits,
or
I
guess,
since
we're
squashing
commits
essentially
the
scope
of
our
pull
request.
A
pull
request
is
either
you
know
a
a
line
in
the
change
log
or
it's
or
I
guess
it
could
be,
not
a
line.
E
The
change
log,
if,
if
a
pull
request,
is
just
it's
kind
of
not
really
a
functional
thing,
it's
editing
the
you
know
if
it's
heading
anything
to
release
scripts
and
that's
not
a
a
functional
change
to
any
of
the
products
themselves.
So
you
can
have
zero
clients
and
change
block,
but
you
can't
have
multiple.
You
can't
have
a
pull
request
that
corresponds
to
multiple
lines
that
I
change
log.
So
there's
there's
some
scoping
discipline
that
it
kind
of
enforces.
G
G
I
don't
know
suppose
that
I'm
like
working
on
a
feature
and
I'm
going
to
open
this
as
a
pr
so
often
times
like
during
a
feature
you
end
up.
You
end
up
having
multiple
commits
and
you
do
like
a
few
things
you
might
have
like.
You
know
feet
feet
feet
I
added
this
stuff
and
then
you
might
have
refactor.
G
I
changed
a
bunch
of
stuff
that
I
added
in
this
commit
and
then
maybe
like
a
docs
commit,
or
something
so
like
is-
is
that
the
right
thing
to
do
in
your
feature
is
to
label
each
commit
like
that.
But
then,
when
you
open
your
pr
and
ultimately
the
squash
during
the
squash
and
merge
process,
you're
like
oh,
this
is
all
just
actually
a
feature.
So
I
guess
my
question.
G
There
is
kind
of
that
flow
of
commits
you
have
in
your
feature
where
you
kind
of
have
like
this
mix
of
like
feet
and
other
things
based
on
what
was
happening
like
does,
that,
does
that
make
sense?
Are
you
kind
of
using
conventional
commits
properly
when
you
do
that,
or
should
literally
every
commit
in
your
feature,
be
a
feat
commit
yeah,
so.
E
Again,
it's
that's
so
it
doesn't
matter
so
the
individual
commits
that
go
into
a
a
pull
request
because
we're
gonna
squash
it
really
in
the
end.
It
doesn't
matter
how
those
are
labeled,
even
whether
those
are
labeled.
So
in
that
so
then
I
think
it
it
really
just
kind
of
comes
down
to
you
know.
As
you
know,
your
your
own
kind
of
you
know,
or
maybe
our
maybe
kind
of
our
team's
workflow
style.
E
You
know
how
how
the
is
it
useful
for
communication
with
the
the
reviewer
of
the
the
the
pr
to
to
say?
Oh,
this
particular
commit
within
the
pr
is:
is
the
docs
change
with
with
the
pr,
and
this
commit
is
a
fix.
You
know
maybe
that's
interesting
for
or
useful
for
kind
of
as
a
as
a
communication
mechanism
during
the
during
the
review
process,
but
in
the
end
there's
nothing
that,
because
those
commits
are
gonna,
get
squashed
away
there
there's
no
real
requirement.
E
E
A
A
The
other
thing
that
it
might
be
worth
doing
is
setting
up
templates
for
pr's
so
that
we
at
least
have
some
text
in
there,
reminding
people
that,
for
their
final
kind
of
squash,
that
squash
emoji,
although
I
guess
that's
really
up
to
the
approvers
to
remember,
but
for
the
the
final
squashing
merge
that
they
should
identify,
whether
it's
like
a
feature,
a
fix
or
a
docs
change.
At
the
very
least.
G
Yeah,
I
think
that's
good
and
then
just
whatever
I
guess
as
we
develop
this
process,
we
just
need
to
make
sure
that
we
have
the
right
things
in
place
so
that
us
as
maintainers,
when
we're
actually
merging
these
things
like
we,
we
don't
forget
to
make
sure
that
that
squash
and
merge
commit
does
or
is
labeled
properly.
G
So
so
I
don't
know
if
there's
actually
like,
if
we
can
somehow
build
some
github
labels
into
this
process-
and
you
know
a
pr
should
be
labeled
as
a
feature,
a
bug
breaking
and
there
can
be
multiples
of
those.
But
we
can
somehow
use
that
as
a
way
to
just
make
sure
that
we're
applying
the
most
accurate
label.
A
Looks
like
breaking
actually
is
a
footer
on
the
commit
message,
so
the
label
feat,
fix
and
docs
is
part
of
the
header
and
then
a
footer
indicates.
If
there's
breaking
change.
E
Yeah
there
there
are
a
couple
of
ways
to
annotate
breaking
changes.
One
of
them
is
a
footer.
The
other
is,
you
can
include
a,
I
think,
it's
an
exclamation
mark
in
the
in
the
label
itself,
but
it
is
kind
of
orthogonal
to
the
label.
G
So
squash
emerge
does
it
usually
pick
up
the
title
of
the
pull
request,
as
the
commit
message
is
that
the
default
behavior
does
anyone
know
I
feel
like
that's
what
it
does?
I
think
so
I.
F
E
Can
experiment
with
it
and
see
what
it's
actually
doing
and
if,
if
it
does
pick
up
the,
if
it
does
pick
up
the
pull
request
title
that
would
be
useful
because
then
we
can
make,
we
can
just
make
sure
it's
part
of
the
process
to
make
sure
the
pull
request.
Title
is
annotated
with
the
correct
label
during
the
during
the
process,
but
if
it's
the
first
commit,
then
that
would
that's
difficult
to
edit
after
the
fact
so
that'll
make
it
a
little
bit
harder.
E
G
Yeah,
I
was
just
gonna
say
like
I'm
totally
thumbs
up
on
this.
If
anybody
isn't
maybe
speak
up
but
yeah,
we
don't
have
to
solve
all
the
problems,
but
you
know
I
think,
whatever
we
can
do
to
make
this
a
clear
and
be
as
hard
to
mess
up
as
possible,
like
the
better.
B
B
Yeah
I
like
it
too.
I
think
my
only
thing
is
that
it
just
it
just
potentially
adds
a
bit
of
friction
for
people
who
are
contributing
like
because
it's
like
people
that
aren't
us
that
know
the
convention
that
may
be
coming
in
that
are
using
open
telemetry
and
they
want
to
contribute
to
the
project.
It's
just
like
another
thing
that
they
have
to.
B
A
Like
in
practice,
though,
because
this
is
happening
with
the
squash
merch
portion,
which
the
maintainers
and
approvers
are
or
possibly
only
maintainers
can
do,
I
think
the
like.
The
onus
is
on
us
to
get
that
right,
while
it's
nice
for
contributors
to
know
that
it's
not
like
it's,
it's
not
vital.
G
I
think
that's
fine.
I
there
is
that
tool
husky.
I
don't
think
it's
specific
to
javascript.
We
could
see
about
using
that,
but
I
think
it's
like.
I
think
there
might
be
a
config
that
just
goes
in
the
top
level
of
the
repo
and
it
automatically
ties
in
with
with
git
as
like
a
a
hook.
G
Then
that
would
be
a
way
to
at
least
automate
the
education
of
contributors.
It
might
cause
them
to
have
to
go
kind
of
investigate
your
readme
a
little
bit,
but
we
could
probably
deal
with
that.
D
C
One
thing
that
is
a
little
annoying
is
like,
I
think,
the
first
time
I
bumped
into
husky
in
the
js
open
telemetry
was
like
my
computer
was
on
like
one
percent,
and
I
was
like-
I
really
want
to
make
this
commit,
and
I
was
like,
like
screw
you
not
telling
me
what
I
can
do
on
my
computer
like
so
yeah,
maybe
we
just
make
sure
there's
like
a
how
to
override
just
in
case
but
yeah.
I
think
it's
good
and
it
helped
it's
like
in
two
years.
C
G
All
right
cool,
I
think
I
think
we're
all
in
favor
I
mentioned
on
the
issue
if,
for
some
reason,
you're
not
or
you
change
your
mind,
but
otherwise
they
say
go
forward
with
it.
We
are
at
time
so
I'll
see
you
all
next.