hi chetan i don't really see the problem with the big amount of issues inside the 'core' module. on a regular basis i look at unassigned issues and those without a component to see if there is anything in there that i missed.
from a consumer point of view though i see a lot of benefit of having the structure aligned with svn because you don't have to wonder where to put stuff. kind regards angela On 29/03/17 08:02, "Chetan Mehrotra" <[email protected]> wrote: >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 >>>> >>
