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 und
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 Mo
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 wrote:
> +1 to Jake’s comment
>
> The number of “special cases” we’re talking about
+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
I withdraw the re-usable JIRA ticket suggestion - it was semi-facetious
anyway.
On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett wrote:
> +1
>
> All changes in the repo should have a ticket.
>
> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer
> wrote:
>
> > My opinion is that no work should be don
+1
All changes in the repo should have a ticket.
On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer
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 t
+1
On Mon, Feb 29, 2016 at 12:44 PM, Anthony Baker wrote:
> IMO JIRA tickets are useful for two things:
>
> 1) Figuring out things that have to be done.
> 2) Figuring out things that got done.
>
> If something is important enough to show up in release notes, it should
> have a JIRA. This probab
IMO JIRA tickets are useful for two things:
1) Figuring out things that have to be done.
2) Figuring out things that got done.
If something is important enough to show up in release notes, it should have a
JIRA. This probably covers 99.9% of (non-docs) changes. I don’t think reusing
JIRA’s ma
imo, small typo's could be managed through a single JIRA.
Of course the git commit comment should reflect what was done. Otherwise
it becomes a blanket JIRA that could end up covering a very broad
spectrum of work.
But when even that JIRA should have an EOL. Maybe 1 broad JIRA for
typo's per
Docs are an important part of the product and over time we plan to migrate
an increasing number of doc sources to the Apache Geode repo (or an allied
repo in the Apache universe). While the workflow for docs often resembles
that for code, there are also other case, such as typo repairs, that IMO
do
On Spring projects, and in particular, Spring Data GemFire, we file JIRA
tickets and categorize them as "tasks". However, it not uncommon for a bug
(fix)/enhancement/new-feature to have code/test/documentation changes all
filed under a single JIRA. For example...
SGF-123 - Improve feature X...
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
+1 to Dan's points.
[GEODE-XYZ] OR [DOCS] [WEBSITE] would be valid "tags" and could then
still be part of a hook to enforce proper formatting as well...
On Mon, Feb 29, 2016 at 11:05 AM, Dan Smith wrote:
> My opinion is that docs and minor changes to tests or build scripts don't
> need nece
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.
J
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" 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
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
16 matches
Mail list logo
