Not sure if we should have a 1-1 mapping between JIRA Component and
Module at svn level. We can create logical components and later align
them as and when new modules are carved out. If required JIRA
components can be merged and renamed easily.

As said having specific JIRA component for some logical feature set in
Oak allows better tracking and discovery of logged issues which is
harder with current set where "core" component has lots of different
types of issues clubbed together
Chetan Mehrotra


On Tue, Mar 28, 2017 at 12:32 PM, Angela Schreiber <[email protected]> wrote:
> i agree with marcel.
> in general i would rather move forward with the modularisation and then
> adjust jira accordingly.
>
> kind regards
> angela
>
> On 27/03/17 09:26, "Marcel Reutegger" <[email protected]> wrote:
>
>>Hi,
>>
>>I'm wondering if this is the best approach. Initially we used the JIRA
>>component 1:1 for modules we have in SVN. Now we also use them for
>>sub-modules like 'documentmk', 'mongomk', 'property-index', ...
>>
>>In my view this indicates that the existing modules should probably be
>>split and we'd be back to a 1:1 relation between modules in SVN and
>>components in JIRA. Alternatively, we could also use JIRA labels and
>>group issues by features like observation.
>>
>>Regards
>>  Marcel
>>
>>On 27/03/17 07:57, Chetan Mehrotra wrote:
>>> I analyzed the issues currently logged under component "core" which
>>> has ~100 issues. Looking at most issues I think we can do following
>>>
>>> 1. Create a new component for observation issues i.e. "observation"
>>> 2. Avoid marking same issue for multiple component like "documentmk
>>> and core" unless the change impacts code base outside of that
>>> component like in this case outside of documentmk package
>>>
>>> This would ensure that we can get some better sense out of issues
>>> currently clubbed under "core"
>>>
>>> Thoughts?
>>>
>>> Chetan Mehrotra
>>>
>

Reply via email to