Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Jens Deppe <jd...@pivotal.io>]

For things like 'doc typos' we could consider a Jira that remains open for
a specific release or period of development and then gets closed at the end
of that cycle.

On Mon, Feb 29, 2016 at 1:55 PM, Kenneth Howe <kh...@pivotal.io> wrote:

> +1 to Jake’s comment
>
> The number of “special cases” we’re talking about is pretty small compared
> to the overall number commits. Even for doc typos it’s not a problem to
> submit a JIRA when you see the problem. I’d be inclined to open one JIRA
> for however many typos or minor textual errors I find on a read-through or
> review of a doc.
>
> Ken
>
> > On Feb 29, 2016, at 1:42 PM, Dave Barnes <db...@pivotal.io> wrote:
> >
> > I withdraw the re-usable JIRA ticket suggestion - it was semi-facetious
> > anyway.
> >
> > On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> >> +1
> >>
> >> All changes in the repo should have a ticket.
> >>
> >> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer <uk...@pivotal.io>
> >> wrote:
> >>
> >>> My opinion is that no work should be done without a JIRA. That way
> there
> >>> is a "documentation" on what the task is and you can measure the
> outcome
> >>> based on the JIRA.
> >>>
> >>> One might think that one could end up in a scenario where we'd end up
> >>> creating JIRA's for the sake of creating JIRA's. But in the long run
> >>> those "trivial" tasks become less frequent.
> >>>
> >>> I also thought that there was some unwritten rule that no changes shall
> >>> be made directly in trunk/develop? ;)
> >>>
> >>>
> >>>
> >>> On 1/03/2016 6:05 am, Dan Smith wrote:
> >>>> My opinion is that docs and minor changes to tests or build scripts
> >> don't
> >>>> need necessarily a JIRA. So I'm not sure we want to enforce this with
> a
> >>>> hook.
> >>>>
> >>>> That said, I definitely see commits in the log that look like product
> >> bug
> >>>> fixes, and I totally agree those should have ticket #s in the commit.
> >>>>
> >>>> Jason suggested something that I think might be a good idea - for
> >> changes
> >>>> that don't need a JIRA, maybe we can put some other tag in that spot.
> >> For
> >>>> example:
> >>>>
> >>>> DOCS: Update most occurrences of "Geode" to "Apache Geode".
> >>>>
> >>>> -Dan
> >>>>
> >>>> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> >>> kareem.shabazz@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Is it by design that there are no client-side Git hooks to prevent
> >> this
> >>>>> sort of thing?
> >>>>>
> >>>>> --
> >>>>> Kareem
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" <
> klund@pivotal.io
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Please remember to include the GEODE-xxx jira ticket # in your commit
> >>>>> messages. I'm looking at git log on develop and I can't correlate
> >>> several
> >>>>> checkins with any jira tickets.
> >>>>>
> >>>>> Thanks,
> >>>>> Kirk
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[kareem shabazz <ka...@gmail.com>]

To add my two-cents, since I missed the party earlier, by way of example
from my own use cases. On my team every sprint/cycle we create an
over-arching "tech debt" epic which we close out at the end of the sprint.
Usually there is some tech debt that requires doing and a Jira task(s) is
created under this epic. For us updating/amending docs is part of tech debt
and it informs the larger picture of things - usually it means something
was missed. Updating of docs is usually part the Jira story (a separate
task) for the code that corresponds to the docs and is considered as part
of meeting the "definition of done".

For Geode, unless there is a new feature/enhancement/bug-fix being done
then there's a large quota of tech debt so creating an epic "tech debt" and
having numerous Jira tasks under it to cleanly tie in what was done for a
particular sprint. Doc changes would just fall inline as we know this is a
period of transition for Geode so there could be a number of tech debt
checkins that just include docs or more usually code and docs.

Sensibly things like typos can be consolidated into a single jira and then
put up for review and merged at the end of the cycle - assuming these typos
can't b done as part of some other checkin. Typos in themselves aren't
usually an urgent and necesary need like a bug-fix that may have to go in
pronto. Either way I think the policy should be set and everyone ack and
abide and move on for smooth sailing.

On Mon, Feb 29, 2016 at 6:25 PM, Dave Barnes <db...@pivotal.io> wrote:

> Based on some off-line discussions, as well as this thread, I'm buying into
> the idea that all changes should follow the same rules. It's simpler that
> way and the additional overhead of crafting a JIRA ticket is minimal,
> really. [I'm assuming we won't run out of JIRA numbers anytime soon...]
>
>
> On Mon, Feb 29, 2016 at 3:20 PM, Jens Deppe <jd...@pivotal.io> wrote:
>
> > For things like 'doc typos' we could consider a Jira that remains open
> for
> > a specific release or period of development and then gets closed at the
> end
> > of that cycle.
> >
> > On Mon, Feb 29, 2016 at 1:55 PM, Kenneth Howe <kh...@pivotal.io> wrote:
> >
> > > +1 to Jake’s comment
> > >
> > > The number of “special cases” we’re talking about is pretty small
> > compared
> > > to the overall number commits. Even for doc typos it’s not a problem to
> > > submit a JIRA when you see the problem. I’d be inclined to open one
> JIRA
> > > for however many typos or minor textual errors I find on a read-through
> > or
> > > review of a doc.
> > >
> > > Ken
> > >
> > > > On Feb 29, 2016, at 1:42 PM, Dave Barnes <db...@pivotal.io> wrote:
> > > >
> > > > I withdraw the re-usable JIRA ticket suggestion - it was
> semi-facetious
> > > > anyway.
> > > >
> > > > On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > >
> > > >> +1
> > > >>
> > > >> All changes in the repo should have a ticket.
> > > >>
> > > >> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer <
> ukohlmeyer@pivotal.io
> > >
> > > >> wrote:
> > > >>
> > > >>> My opinion is that no work should be done without a JIRA. That way
> > > there
> > > >>> is a "documentation" on what the task is and you can measure the
> > > outcome
> > > >>> based on the JIRA.
> > > >>>
> > > >>> One might think that one could end up in a scenario where we'd end
> up
> > > >>> creating JIRA's for the sake of creating JIRA's. But in the long
> run
> > > >>> those "trivial" tasks become less frequent.
> > > >>>
> > > >>> I also thought that there was some unwritten rule that no changes
> > shall
> > > >>> be made directly in trunk/develop? ;)
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 1/03/2016 6:05 am, Dan Smith wrote:
> > > >>>> My opinion is that docs and minor changes to tests or build
> scripts
> > > >> don't
> > > >>>> need necessarily a JIRA. So I'm not sure we want to enforce this
> > with
> > > a
> > > >>>> hook.
> > > >>>>
> > > >>>> That said, I definitely see commits in the log that look like
> > product
> > > >> bug
> > > >>>> fixes, and I totally agree those should have ticket #s in the
> > commit.
> > > >>>>
> > > >>>> Jason suggested something that I think might be a good idea - for
> > > >> changes
> > > >>>> that don't need a JIRA, maybe we can put some other tag in that
> > spot.
> > > >> For
> > > >>>> example:
> > > >>>>
> > > >>>> DOCS: Update most occurrences of "Geode" to "Apache Geode".
> > > >>>>
> > > >>>> -Dan
> > > >>>>
> > > >>>> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> > > >>> kareem.shabazz@gmail.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Is it by design that there are no client-side Git hooks to
> prevent
> > > >> this
> > > >>>>> sort of thing?
> > > >>>>>
> > > >>>>> --
> > > >>>>> Kareem
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" <
> > > klund@pivotal.io
> > > >>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> Please remember to include the GEODE-xxx jira ticket # in your
> > commit
> > > >>>>> messages. I'm looking at git log on develop and I can't correlate
> > > >>> several
> > > >>>>> checkins with any jira tickets.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> Kirk
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> >
>



-- 
Kareem

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Dave Barnes <db...@pivotal.io>]

Based on some off-line discussions, as well as this thread, I'm buying into
the idea that all changes should follow the same rules. It's simpler that
way and the additional overhead of crafting a JIRA ticket is minimal,
really. [I'm assuming we won't run out of JIRA numbers anytime soon...]


On Mon, Feb 29, 2016 at 3:20 PM, Jens Deppe <jd...@pivotal.io> wrote:

> For things like 'doc typos' we could consider a Jira that remains open for
> a specific release or period of development and then gets closed at the end
> of that cycle.
>
> On Mon, Feb 29, 2016 at 1:55 PM, Kenneth Howe <kh...@pivotal.io> wrote:
>
> > +1 to Jake’s comment
> >
> > The number of “special cases” we’re talking about is pretty small
> compared
> > to the overall number commits. Even for doc typos it’s not a problem to
> > submit a JIRA when you see the problem. I’d be inclined to open one JIRA
> > for however many typos or minor textual errors I find on a read-through
> or
> > review of a doc.
> >
> > Ken
> >
> > > On Feb 29, 2016, at 1:42 PM, Dave Barnes <db...@pivotal.io> wrote:
> > >
> > > I withdraw the re-usable JIRA ticket suggestion - it was semi-facetious
> > > anyway.
> > >
> > > On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > >> +1
> > >>
> > >> All changes in the repo should have a ticket.
> > >>
> > >> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer <ukohlmeyer@pivotal.io
> >
> > >> wrote:
> > >>
> > >>> My opinion is that no work should be done without a JIRA. That way
> > there
> > >>> is a "documentation" on what the task is and you can measure the
> > outcome
> > >>> based on the JIRA.
> > >>>
> > >>> One might think that one could end up in a scenario where we'd end up
> > >>> creating JIRA's for the sake of creating JIRA's. But in the long run
> > >>> those "trivial" tasks become less frequent.
> > >>>
> > >>> I also thought that there was some unwritten rule that no changes
> shall
> > >>> be made directly in trunk/develop? ;)
> > >>>
> > >>>
> > >>>
> > >>> On 1/03/2016 6:05 am, Dan Smith wrote:
> > >>>> My opinion is that docs and minor changes to tests or build scripts
> > >> don't
> > >>>> need necessarily a JIRA. So I'm not sure we want to enforce this
> with
> > a
> > >>>> hook.
> > >>>>
> > >>>> That said, I definitely see commits in the log that look like
> product
> > >> bug
> > >>>> fixes, and I totally agree those should have ticket #s in the
> commit.
> > >>>>
> > >>>> Jason suggested something that I think might be a good idea - for
> > >> changes
> > >>>> that don't need a JIRA, maybe we can put some other tag in that
> spot.
> > >> For
> > >>>> example:
> > >>>>
> > >>>> DOCS: Update most occurrences of "Geode" to "Apache Geode".
> > >>>>
> > >>>> -Dan
> > >>>>
> > >>>> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> > >>> kareem.shabazz@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Is it by design that there are no client-side Git hooks to prevent
> > >> this
> > >>>>> sort of thing?
> > >>>>>
> > >>>>> --
> > >>>>> Kareem
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" <
> > klund@pivotal.io
> > >>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Please remember to include the GEODE-xxx jira ticket # in your
> commit
> > >>>>> messages. I'm looking at git log on develop and I can't correlate
> > >>> several
> > >>>>> checkins with any jira tickets.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Kirk
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>