Re: [DISCUSS] Some JIRA adjustments

2017-09-13 Thread Stephen Mallette
That was my take - yes - i should have wrote that in my conclusion. I've
already updated the current tickets to include both versions. don't think i
missed any.

On Wed, Sep 13, 2017 at 8:42 AM, Daniel Kuppitz  wrote:

> Do we agree now, that Fix Version should contain all affected versions?
>
> Cheers,
> Daniel
>
>
> On Sep 13, 2017 5:11 AM, "Stephen Mallette"  wrote:
>
> > Sorry for all the noise on the list with all those JIRA updates but I've
> > basically gotten our process changes into place at this point. I've
> created
> > the new language specific components and re-assigned all the old
> > language-variants components - language-variants is no longer in use and
> > has been deleted. I also removed "Fix version" assignments - they will
> only
> > be added when we actually complete them (thus preventing future dev list
> > noise on release).
> >
> >
> >
> >
> > On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra <
> > jorge.gon...@datastax.com
> > > wrote:
> >
> > > I'm +1 on adding all fix versions that it was applied to.
> > > I'm +1 on adding a component per GLV.
> > >
> > > On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale 
> wrote:
> > >
> > > > +1 for labeling all versions applied to
> > > >
> > > >
> > > >
> > > > Robert Dale
> > > >
> > > > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > > > I thought about the "Fix version" situation - I guess I don't
> really
> > > care
> > > > > which way we do it so long as it is consistent. If it is more
> > intuitive
> > > > to
> > > > > everyone to add all the versions that a fix went in on then i'm
> fine
> > to
> > > > do
> > > > > that. However, I do think the CHANGELOG is cleaner to look at
> without
> > > all
> > > > > the duplication, so if we did go down that path the release manager
> > > would
> > > > > just need to make sure that the appropriate JIRAs were filtered out
> > > > which I
> > > > > suppose isn't too hard. Anyone prefer that we assign all the fix
> > > versions
> > > > > as necessary in JIRA?
> > > > >
> > > > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette <
> > spmalle...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > You would only know through tribal knowedge and the changelog I
> > > guess.
> > > > > >
> > > > > > sucks - i just realized that there are duplicates all through the
> > > > > > changelog because there's been spotty application of a single fix
> > > > > version.
> > > > > > dah
> > > > > >
> > > > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > > > wrote:
> > > > > >
> > > > > >> But who will remember a few months after a release, that it was
> > > 3.3.1
> > > > > that
> > > > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in
> > the
> > > > fix
> > > > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > > > wouldn't
> > > > > >> know that it was 3.3.1 for example. That's why I always prefer
> to
> > > > > specify
> > > > > >> both / all versions.
> > > > > >>
> > > > > >> Cheers,
> > > > > >> Daniel
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > > > spmalle...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > a while back we'd decided that since all fixes roll forward to
> > > other
> > > > > >> > releases, that we would only add the fix version to the lowest
> > > > common
> > > > > >> > release. so if you fix something 3.2.7 then it will
> > automatically
> > > be
> > > > > >> > included in 3.3.1 (we've not had a case yet where something is
> > > only
> > > > > >> fixed
> > > > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> > > From
> > > > a
> > > > > >> > reporting perspective this approach of adding just one fix
> > version
> > > > > works
> > > > > >> > nicely because when we release we can just filter JIRA on the
> > > > specific
> > > > > >> > version we are releasing without any additional filtering
> (which
> > > is
> > > > > how
> > > > > >> we
> > > > > >> > add those tickets to the changelog on release).
> > > > > >> >
> > > > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz
>  > >
> > > > > wrote:
> > > > > >> >
> > > > > >> > > >
> > > > > >> > > >   a. reserve "fix version" for when we actually close the
> > > ticket
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > That's how I always used to do it. However, sometimes (just
> > > > > recently)
> > > > > >> I
> > > > > >> > > noticed that you took away one version. The fix went into
> > tp32/
> > > > and
> > > > > >> then
> > > > > >> > > got merged into master/. So it will end up being part of
> 3.2.7
> > > and
> > > > > >> 3.3.1
> > > > > >> > > and that's what I was using for the Fix Version. But if I
> > > remember
> > > > > >> > > correctly, you removed 3.3.1 from the Fix Version
> afterwards.
> > > > Why's
> > > > > >> that?
> > > > > >> > >

Re: [DISCUSS] Some JIRA adjustments

2017-09-13 Thread Daniel Kuppitz
Do we agree now, that Fix Version should contain all affected versions?

Cheers,
Daniel


On Sep 13, 2017 5:11 AM, "Stephen Mallette"  wrote:

> Sorry for all the noise on the list with all those JIRA updates but I've
> basically gotten our process changes into place at this point. I've created
> the new language specific components and re-assigned all the old
> language-variants components - language-variants is no longer in use and
> has been deleted. I also removed "Fix version" assignments - they will only
> be added when we actually complete them (thus preventing future dev list
> noise on release).
>
>
>
>
> On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra <
> jorge.gon...@datastax.com
> > wrote:
>
> > I'm +1 on adding all fix versions that it was applied to.
> > I'm +1 on adding a component per GLV.
> >
> > On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale  wrote:
> >
> > > +1 for labeling all versions applied to
> > >
> > >
> > >
> > > Robert Dale
> > >
> > > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > I thought about the "Fix version" situation - I guess I don't really
> > care
> > > > which way we do it so long as it is consistent. If it is more
> intuitive
> > > to
> > > > everyone to add all the versions that a fix went in on then i'm fine
> to
> > > do
> > > > that. However, I do think the CHANGELOG is cleaner to look at without
> > all
> > > > the duplication, so if we did go down that path the release manager
> > would
> > > > just need to make sure that the appropriate JIRAs were filtered out
> > > which I
> > > > suppose isn't too hard. Anyone prefer that we assign all the fix
> > versions
> > > > as necessary in JIRA?
> > > >
> > > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > You would only know through tribal knowedge and the changelog I
> > guess.
> > > > >
> > > > > sucks - i just realized that there are duplicates all through the
> > > > > changelog because there's been spotty application of a single fix
> > > > version.
> > > > > dah
> > > > >
> > > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > > wrote:
> > > > >
> > > > >> But who will remember a few months after a release, that it was
> > 3.3.1
> > > > that
> > > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in
> the
> > > fix
> > > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > > wouldn't
> > > > >> know that it was 3.3.1 for example. That's why I always prefer to
> > > > specify
> > > > >> both / all versions.
> > > > >>
> > > > >> Cheers,
> > > > >> Daniel
> > > > >>
> > > > >>
> > > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > > spmalle...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > a while back we'd decided that since all fixes roll forward to
> > other
> > > > >> > releases, that we would only add the fix version to the lowest
> > > common
> > > > >> > release. so if you fix something 3.2.7 then it will
> automatically
> > be
> > > > >> > included in 3.3.1 (we've not had a case yet where something is
> > only
> > > > >> fixed
> > > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> > From
> > > a
> > > > >> > reporting perspective this approach of adding just one fix
> version
> > > > works
> > > > >> > nicely because when we release we can just filter JIRA on the
> > > specific
> > > > >> > version we are releasing without any additional filtering (which
> > is
> > > > how
> > > > >> we
> > > > >> > add those tickets to the changelog on release).
> > > > >> >
> > > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  >
> > > > wrote:
> > > > >> >
> > > > >> > > >
> > > > >> > > >   a. reserve "fix version" for when we actually close the
> > ticket
> > > > >> > >
> > > > >> > >
> > > > >> > > That's how I always used to do it. However, sometimes (just
> > > > recently)
> > > > >> I
> > > > >> > > noticed that you took away one version. The fix went into
> tp32/
> > > and
> > > > >> then
> > > > >> > > got merged into master/. So it will end up being part of 3.2.7
> > and
> > > > >> 3.3.1
> > > > >> > > and that's what I was using for the Fix Version. But if I
> > remember
> > > > >> > > correctly, you removed 3.3.1 from the Fix Version afterwards.
> > > Why's
> > > > >> that?
> > > > >> > >
> > > > >> > > Cheers,
> > > > >> > > Daniel
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> > > > >> spmalle...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Two quick ideas I'd like everyone to consider with respect
> to
> > > > JIRA:
> > > > >> > > >
> > > > >> > > > 1. Add "component" types for each GLV rather than just the
> > > generic
> > > > >> > > > "language variant" one we have now
> > > > >> > > > 2. Remove the "fix version" currently assigned to all 

Re: [DISCUSS] Some JIRA adjustments

2017-09-13 Thread Stephen Mallette
Sorry for all the noise on the list with all those JIRA updates but I've
basically gotten our process changes into place at this point. I've created
the new language specific components and re-assigned all the old
language-variants components - language-variants is no longer in use and
has been deleted. I also removed "Fix version" assignments - they will only
be added when we actually complete them (thus preventing future dev list
noise on release).




On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra  wrote:

> I'm +1 on adding all fix versions that it was applied to.
> I'm +1 on adding a component per GLV.
>
> On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale  wrote:
>
> > +1 for labeling all versions applied to
> >
> >
> >
> > Robert Dale
> >
> > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette 
> > wrote:
> >
> > > I thought about the "Fix version" situation - I guess I don't really
> care
> > > which way we do it so long as it is consistent. If it is more intuitive
> > to
> > > everyone to add all the versions that a fix went in on then i'm fine to
> > do
> > > that. However, I do think the CHANGELOG is cleaner to look at without
> all
> > > the duplication, so if we did go down that path the release manager
> would
> > > just need to make sure that the appropriate JIRAs were filtered out
> > which I
> > > suppose isn't too hard. Anyone prefer that we assign all the fix
> versions
> > > as necessary in JIRA?
> > >
> > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette  >
> > > wrote:
> > >
> > > > You would only know through tribal knowedge and the changelog I
> guess.
> > > >
> > > > sucks - i just realized that there are duplicates all through the
> > > > changelog because there's been spotty application of a single fix
> > > version.
> > > > dah
> > > >
> > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > wrote:
> > > >
> > > >> But who will remember a few months after a release, that it was
> 3.3.1
> > > that
> > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the
> > fix
> > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > wouldn't
> > > >> know that it was 3.3.1 for example. That's why I always prefer to
> > > specify
> > > >> both / all versions.
> > > >>
> > > >> Cheers,
> > > >> Daniel
> > > >>
> > > >>
> > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > a while back we'd decided that since all fixes roll forward to
> other
> > > >> > releases, that we would only add the fix version to the lowest
> > common
> > > >> > release. so if you fix something 3.2.7 then it will automatically
> be
> > > >> > included in 3.3.1 (we've not had a case yet where something is
> only
> > > >> fixed
> > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> From
> > a
> > > >> > reporting perspective this approach of adding just one fix version
> > > works
> > > >> > nicely because when we release we can just filter JIRA on the
> > specific
> > > >> > version we are releasing without any additional filtering (which
> is
> > > how
> > > >> we
> > > >> > add those tickets to the changelog on release).
> > > >> >
> > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz 
> > > wrote:
> > > >> >
> > > >> > > >
> > > >> > > >   a. reserve "fix version" for when we actually close the
> ticket
> > > >> > >
> > > >> > >
> > > >> > > That's how I always used to do it. However, sometimes (just
> > > recently)
> > > >> I
> > > >> > > noticed that you took away one version. The fix went into tp32/
> > and
> > > >> then
> > > >> > > got merged into master/. So it will end up being part of 3.2.7
> and
> > > >> 3.3.1
> > > >> > > and that's what I was using for the Fix Version. But if I
> remember
> > > >> > > correctly, you removed 3.3.1 from the Fix Version afterwards.
> > Why's
> > > >> that?
> > > >> > >
> > > >> > > Cheers,
> > > >> > > Daniel
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> > > >> spmalle...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Two quick ideas I'd like everyone to consider with respect to
> > > JIRA:
> > > >> > > >
> > > >> > > > 1. Add "component" types for each GLV rather than just the
> > generic
> > > >> > > > "language variant" one we have now
> > > >> > > > 2. Remove the "fix version" currently assigned to all open
> > issues
> > > >> > > >   a. reserve "fix version" for when we actually close the
> ticket
> > > >> > > >   b. this will prevent the mass of emails that come out every
> > time
> > > >> we
> > > >> > > > release and have to move forward all the "fix version" of
> issues
> > > >> that
> > > >> > > > didn't close
> > > >> > > >   c. i sense many of the items marked for completion in
> certain
> > > >> > versions
> > > >> > > > are no longer relevant - 

Re: [DISCUSS] Some JIRA adjustments

2017-09-11 Thread Jorge Bay Gondra
I'm +1 on adding all fix versions that it was applied to.
I'm +1 on adding a component per GLV.

On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale  wrote:

> +1 for labeling all versions applied to
>
>
>
> Robert Dale
>
> On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette 
> wrote:
>
> > I thought about the "Fix version" situation - I guess I don't really care
> > which way we do it so long as it is consistent. If it is more intuitive
> to
> > everyone to add all the versions that a fix went in on then i'm fine to
> do
> > that. However, I do think the CHANGELOG is cleaner to look at without all
> > the duplication, so if we did go down that path the release manager would
> > just need to make sure that the appropriate JIRAs were filtered out
> which I
> > suppose isn't too hard. Anyone prefer that we assign all the fix versions
> > as necessary in JIRA?
> >
> > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette 
> > wrote:
> >
> > > You would only know through tribal knowedge and the changelog I guess.
> > >
> > > sucks - i just realized that there are duplicates all through the
> > > changelog because there's been spotty application of a single fix
> > version.
> > > dah
> > >
> > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> wrote:
> > >
> > >> But who will remember a few months after a release, that it was 3.3.1
> > that
> > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the
> fix
> > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > wouldn't
> > >> know that it was 3.3.1 for example. That's why I always prefer to
> > specify
> > >> both / all versions.
> > >>
> > >> Cheers,
> > >> Daniel
> > >>
> > >>
> > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > >> wrote:
> > >>
> > >> > a while back we'd decided that since all fixes roll forward to other
> > >> > releases, that we would only add the fix version to the lowest
> common
> > >> > release. so if you fix something 3.2.7 then it will automatically be
> > >> > included in 3.3.1 (we've not had a case yet where something is only
> > >> fixed
> > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From
> a
> > >> > reporting perspective this approach of adding just one fix version
> > works
> > >> > nicely because when we release we can just filter JIRA on the
> specific
> > >> > version we are releasing without any additional filtering (which is
> > how
> > >> we
> > >> > add those tickets to the changelog on release).
> > >> >
> > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz 
> > wrote:
> > >> >
> > >> > > >
> > >> > > >   a. reserve "fix version" for when we actually close the ticket
> > >> > >
> > >> > >
> > >> > > That's how I always used to do it. However, sometimes (just
> > recently)
> > >> I
> > >> > > noticed that you took away one version. The fix went into tp32/
> and
> > >> then
> > >> > > got merged into master/. So it will end up being part of 3.2.7 and
> > >> 3.3.1
> > >> > > and that's what I was using for the Fix Version. But if I remember
> > >> > > correctly, you removed 3.3.1 from the Fix Version afterwards.
> Why's
> > >> that?
> > >> > >
> > >> > > Cheers,
> > >> > > Daniel
> > >> > >
> > >> > >
> > >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> > >> spmalle...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Two quick ideas I'd like everyone to consider with respect to
> > JIRA:
> > >> > > >
> > >> > > > 1. Add "component" types for each GLV rather than just the
> generic
> > >> > > > "language variant" one we have now
> > >> > > > 2. Remove the "fix version" currently assigned to all open
> issues
> > >> > > >   a. reserve "fix version" for when we actually close the ticket
> > >> > > >   b. this will prevent the mass of emails that come out every
> time
> > >> we
> > >> > > > release and have to move forward all the "fix version" of issues
> > >> that
> > >> > > > didn't close
> > >> > > >   c. i sense many of the items marked for completion in certain
> > >> > versions
> > >> > > > are no longer relevant - we've been bumping some issues forward
> on
> > >> the
> > >> > > > 3.2.x line since 3.2.1
> > >> > > >
> > >> > > > Anyway, if there are no objections in the next 72 hours, I'll
> > assume
> > >> > lazy
> > >> > > > consensus and move forward with these changes. Thanks!
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-11 Thread Robert Dale
+1 for labeling all versions applied to



Robert Dale

On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette 
wrote:

> I thought about the "Fix version" situation - I guess I don't really care
> which way we do it so long as it is consistent. If it is more intuitive to
> everyone to add all the versions that a fix went in on then i'm fine to do
> that. However, I do think the CHANGELOG is cleaner to look at without all
> the duplication, so if we did go down that path the release manager would
> just need to make sure that the appropriate JIRAs were filtered out which I
> suppose isn't too hard. Anyone prefer that we assign all the fix versions
> as necessary in JIRA?
>
> On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette 
> wrote:
>
> > You would only know through tribal knowedge and the changelog I guess.
> >
> > sucks - i just realized that there are duplicates all through the
> > changelog because there's been spotty application of a single fix
> version.
> > dah
> >
> > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz  wrote:
> >
> >> But who will remember a few months after a release, that it was 3.3.1
> that
> >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the fix
> >> version, I know it must be somewhere in the 3.3 line, too, but I
> wouldn't
> >> know that it was 3.3.1 for example. That's why I always prefer to
> specify
> >> both / all versions.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette 
> >> wrote:
> >>
> >> > a while back we'd decided that since all fixes roll forward to other
> >> > releases, that we would only add the fix version to the lowest common
> >> > release. so if you fix something 3.2.7 then it will automatically be
> >> > included in 3.3.1 (we've not had a case yet where something is only
> >> fixed
> >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a
> >> > reporting perspective this approach of adding just one fix version
> works
> >> > nicely because when we release we can just filter JIRA on the specific
> >> > version we are releasing without any additional filtering (which is
> how
> >> we
> >> > add those tickets to the changelog on release).
> >> >
> >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz 
> wrote:
> >> >
> >> > > >
> >> > > >   a. reserve "fix version" for when we actually close the ticket
> >> > >
> >> > >
> >> > > That's how I always used to do it. However, sometimes (just
> recently)
> >> I
> >> > > noticed that you took away one version. The fix went into tp32/ and
> >> then
> >> > > got merged into master/. So it will end up being part of 3.2.7 and
> >> 3.3.1
> >> > > and that's what I was using for the Fix Version. But if I remember
> >> > > correctly, you removed 3.3.1 from the Fix Version afterwards. Why's
> >> that?
> >> > >
> >> > > Cheers,
> >> > > Daniel
> >> > >
> >> > >
> >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> >> spmalle...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Two quick ideas I'd like everyone to consider with respect to
> JIRA:
> >> > > >
> >> > > > 1. Add "component" types for each GLV rather than just the generic
> >> > > > "language variant" one we have now
> >> > > > 2. Remove the "fix version" currently assigned to all open issues
> >> > > >   a. reserve "fix version" for when we actually close the ticket
> >> > > >   b. this will prevent the mass of emails that come out every time
> >> we
> >> > > > release and have to move forward all the "fix version" of issues
> >> that
> >> > > > didn't close
> >> > > >   c. i sense many of the items marked for completion in certain
> >> > versions
> >> > > > are no longer relevant - we've been bumping some issues forward on
> >> the
> >> > > > 3.2.x line since 3.2.1
> >> > > >
> >> > > > Anyway, if there are no objections in the next 72 hours, I'll
> assume
> >> > lazy
> >> > > > consensus and move forward with these changes. Thanks!
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-11 Thread Stephen Mallette
I thought about the "Fix version" situation - I guess I don't really care
which way we do it so long as it is consistent. If it is more intuitive to
everyone to add all the versions that a fix went in on then i'm fine to do
that. However, I do think the CHANGELOG is cleaner to look at without all
the duplication, so if we did go down that path the release manager would
just need to make sure that the appropriate JIRAs were filtered out which I
suppose isn't too hard. Anyone prefer that we assign all the fix versions
as necessary in JIRA?

On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette 
wrote:

> You would only know through tribal knowedge and the changelog I guess.
>
> sucks - i just realized that there are duplicates all through the
> changelog because there's been spotty application of a single fix version.
> dah
>
> On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz  wrote:
>
>> But who will remember a few months after a release, that it was 3.3.1 that
>> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the fix
>> version, I know it must be somewhere in the 3.3 line, too, but I wouldn't
>> know that it was 3.3.1 for example. That's why I always prefer to specify
>> both / all versions.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette 
>> wrote:
>>
>> > a while back we'd decided that since all fixes roll forward to other
>> > releases, that we would only add the fix version to the lowest common
>> > release. so if you fix something 3.2.7 then it will automatically be
>> > included in 3.3.1 (we've not had a case yet where something is only
>> fixed
>> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a
>> > reporting perspective this approach of adding just one fix version works
>> > nicely because when we release we can just filter JIRA on the specific
>> > version we are releasing without any additional filtering (which is how
>> we
>> > add those tickets to the changelog on release).
>> >
>> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  wrote:
>> >
>> > > >
>> > > >   a. reserve "fix version" for when we actually close the ticket
>> > >
>> > >
>> > > That's how I always used to do it. However, sometimes (just recently)
>> I
>> > > noticed that you took away one version. The fix went into tp32/ and
>> then
>> > > got merged into master/. So it will end up being part of 3.2.7 and
>> 3.3.1
>> > > and that's what I was using for the Fix Version. But if I remember
>> > > correctly, you removed 3.3.1 from the Fix Version afterwards. Why's
>> that?
>> > >
>> > > Cheers,
>> > > Daniel
>> > >
>> > >
>> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
>> spmalle...@gmail.com>
>> > > wrote:
>> > >
>> > > > Two quick ideas I'd like everyone to consider with respect to JIRA:
>> > > >
>> > > > 1. Add "component" types for each GLV rather than just the generic
>> > > > "language variant" one we have now
>> > > > 2. Remove the "fix version" currently assigned to all open issues
>> > > >   a. reserve "fix version" for when we actually close the ticket
>> > > >   b. this will prevent the mass of emails that come out every time
>> we
>> > > > release and have to move forward all the "fix version" of issues
>> that
>> > > > didn't close
>> > > >   c. i sense many of the items marked for completion in certain
>> > versions
>> > > > are no longer relevant - we've been bumping some issues forward on
>> the
>> > > > 3.2.x line since 3.2.1
>> > > >
>> > > > Anyway, if there are no objections in the next 72 hours, I'll assume
>> > lazy
>> > > > consensus and move forward with these changes. Thanks!
>> > > >
>> > >
>> >
>>
>
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-08 Thread Stephen Mallette
You would only know through tribal knowedge and the changelog I guess.

sucks - i just realized that there are duplicates all through the changelog
because there's been spotty application of a single fix version. dah

On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz  wrote:

> But who will remember a few months after a release, that it was 3.3.1 that
> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the fix
> version, I know it must be somewhere in the 3.3 line, too, but I wouldn't
> know that it was 3.3.1 for example. That's why I always prefer to specify
> both / all versions.
>
> Cheers,
> Daniel
>
>
> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette 
> wrote:
>
> > a while back we'd decided that since all fixes roll forward to other
> > releases, that we would only add the fix version to the lowest common
> > release. so if you fix something 3.2.7 then it will automatically be
> > included in 3.3.1 (we've not had a case yet where something is only fixed
> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a
> > reporting perspective this approach of adding just one fix version works
> > nicely because when we release we can just filter JIRA on the specific
> > version we are releasing without any additional filtering (which is how
> we
> > add those tickets to the changelog on release).
> >
> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  wrote:
> >
> > > >
> > > >   a. reserve "fix version" for when we actually close the ticket
> > >
> > >
> > > That's how I always used to do it. However, sometimes (just recently) I
> > > noticed that you took away one version. The fix went into tp32/ and
> then
> > > got merged into master/. So it will end up being part of 3.2.7 and
> 3.3.1
> > > and that's what I was using for the Fix Version. But if I remember
> > > correctly, you removed 3.3.1 from the Fix Version afterwards. Why's
> that?
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette  >
> > > wrote:
> > >
> > > > Two quick ideas I'd like everyone to consider with respect to JIRA:
> > > >
> > > > 1. Add "component" types for each GLV rather than just the generic
> > > > "language variant" one we have now
> > > > 2. Remove the "fix version" currently assigned to all open issues
> > > >   a. reserve "fix version" for when we actually close the ticket
> > > >   b. this will prevent the mass of emails that come out every time we
> > > > release and have to move forward all the "fix version" of issues that
> > > > didn't close
> > > >   c. i sense many of the items marked for completion in certain
> > versions
> > > > are no longer relevant - we've been bumping some issues forward on
> the
> > > > 3.2.x line since 3.2.1
> > > >
> > > > Anyway, if there are no objections in the next 72 hours, I'll assume
> > lazy
> > > > consensus and move forward with these changes. Thanks!
> > > >
> > >
> >
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-08 Thread Daniel Kuppitz
But who will remember a few months after a release, that it was 3.3.1 that
went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the fix
version, I know it must be somewhere in the 3.3 line, too, but I wouldn't
know that it was 3.3.1 for example. That's why I always prefer to specify
both / all versions.

Cheers,
Daniel


On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette 
wrote:

> a while back we'd decided that since all fixes roll forward to other
> releases, that we would only add the fix version to the lowest common
> release. so if you fix something 3.2.7 then it will automatically be
> included in 3.3.1 (we've not had a case yet where something is only fixed
> in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a
> reporting perspective this approach of adding just one fix version works
> nicely because when we release we can just filter JIRA on the specific
> version we are releasing without any additional filtering (which is how we
> add those tickets to the changelog on release).
>
> On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  wrote:
>
> > >
> > >   a. reserve "fix version" for when we actually close the ticket
> >
> >
> > That's how I always used to do it. However, sometimes (just recently) I
> > noticed that you took away one version. The fix went into tp32/ and then
> > got merged into master/. So it will end up being part of 3.2.7 and 3.3.1
> > and that's what I was using for the Fix Version. But if I remember
> > correctly, you removed 3.3.1 from the Fix Version afterwards. Why's that?
> >
> > Cheers,
> > Daniel
> >
> >
> > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette 
> > wrote:
> >
> > > Two quick ideas I'd like everyone to consider with respect to JIRA:
> > >
> > > 1. Add "component" types for each GLV rather than just the generic
> > > "language variant" one we have now
> > > 2. Remove the "fix version" currently assigned to all open issues
> > >   a. reserve "fix version" for when we actually close the ticket
> > >   b. this will prevent the mass of emails that come out every time we
> > > release and have to move forward all the "fix version" of issues that
> > > didn't close
> > >   c. i sense many of the items marked for completion in certain
> versions
> > > are no longer relevant - we've been bumping some issues forward on the
> > > 3.2.x line since 3.2.1
> > >
> > > Anyway, if there are no objections in the next 72 hours, I'll assume
> lazy
> > > consensus and move forward with these changes. Thanks!
> > >
> >
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-08 Thread Stephen Mallette
a while back we'd decided that since all fixes roll forward to other
releases, that we would only add the fix version to the lowest common
release. so if you fix something 3.2.7 then it will automatically be
included in 3.3.1 (we've not had a case yet where something is only fixed
in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a
reporting perspective this approach of adding just one fix version works
nicely because when we release we can just filter JIRA on the specific
version we are releasing without any additional filtering (which is how we
add those tickets to the changelog on release).

On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  wrote:

> >
> >   a. reserve "fix version" for when we actually close the ticket
>
>
> That's how I always used to do it. However, sometimes (just recently) I
> noticed that you took away one version. The fix went into tp32/ and then
> got merged into master/. So it will end up being part of 3.2.7 and 3.3.1
> and that's what I was using for the Fix Version. But if I remember
> correctly, you removed 3.3.1 from the Fix Version afterwards. Why's that?
>
> Cheers,
> Daniel
>
>
> On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette 
> wrote:
>
> > Two quick ideas I'd like everyone to consider with respect to JIRA:
> >
> > 1. Add "component" types for each GLV rather than just the generic
> > "language variant" one we have now
> > 2. Remove the "fix version" currently assigned to all open issues
> >   a. reserve "fix version" for when we actually close the ticket
> >   b. this will prevent the mass of emails that come out every time we
> > release and have to move forward all the "fix version" of issues that
> > didn't close
> >   c. i sense many of the items marked for completion in certain versions
> > are no longer relevant - we've been bumping some issues forward on the
> > 3.2.x line since 3.2.1
> >
> > Anyway, if there are no objections in the next 72 hours, I'll assume lazy
> > consensus and move forward with these changes. Thanks!
> >
>


Re: [DISCUSS] Some JIRA adjustments

2017-09-08 Thread Daniel Kuppitz
>
>   a. reserve "fix version" for when we actually close the ticket


That's how I always used to do it. However, sometimes (just recently) I
noticed that you took away one version. The fix went into tp32/ and then
got merged into master/. So it will end up being part of 3.2.7 and 3.3.1
and that's what I was using for the Fix Version. But if I remember
correctly, you removed 3.3.1 from the Fix Version afterwards. Why's that?

Cheers,
Daniel


On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette 
wrote:

> Two quick ideas I'd like everyone to consider with respect to JIRA:
>
> 1. Add "component" types for each GLV rather than just the generic
> "language variant" one we have now
> 2. Remove the "fix version" currently assigned to all open issues
>   a. reserve "fix version" for when we actually close the ticket
>   b. this will prevent the mass of emails that come out every time we
> release and have to move forward all the "fix version" of issues that
> didn't close
>   c. i sense many of the items marked for completion in certain versions
> are no longer relevant - we've been bumping some issues forward on the
> 3.2.x line since 3.2.1
>
> Anyway, if there are no objections in the next 72 hours, I'll assume lazy
> consensus and move forward with these changes. Thanks!
>