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 makes sense.

Anthony


> On Feb 29, 2016, at 12:39 PM, Udo Kohlmeyer <[email protected]> wrote:
> 
> 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 
> GA release (if required)?
> 
> --Udo
> 
> On 1/03/2016 7:33 am, Dave Barnes wrote:
>> 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
>> don't really merit individual JIRA tickets.
>> Would it be in harmony with the Apache Way to open a single JIRA ticket for
>> 'doc typo repair,' keep it open, and re-use it over and over?
>> That would spare us from creating dozens of identical JIRA tickets that
>> differ only by number.
>> 
>> 
>> On Mon, Feb 29, 2016 at 11:39 AM, John Blum <[email protected]> wrote:
>> 
>>> 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...  // includes code changes/tests, maybe doc
>>> changes
>>> SGF-123 - Add additional test for use case/scenario...
>>> SGF-123 - Update documentation...
>>> 
>>> etc
>>> 
>>> -John
>>> 
>>> 
>>> On Mon, Feb 29, 2016 at 11:20 AM, Udo Kohlmeyer <[email protected]>
>>> 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 <
>>> [email protected]
>>>>> 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" <[email protected]>
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>>> --
>>> -John
>>> 503-504-8657
>>> john.blum10101 (skype)
>>> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to