Re: New JIRA component for observation
Hi, > I would prefer to stay aligned with Maven boundaries as much as possible > as this simplifies bug reporting for parties not deeply involved with > Oak very much. Actually, I don't think that's a problem. I wouldn't expect such a person to specify any module (logical or maven). > Most of the apparent need to break out of that scheme is > to me rather a symptom of missing modularity rather than a cure. It sounds like "modularity" for you means "Maven modularity". I don't agree this is the only "modularity" there is. > If we introduce logical modules in Jira, I strongly suggest to come up with a > clear and concise definition for them: what exactly belongs to them, > what not? Yes. And I would like to understand the reason on why we use modules (for reporting, easier to find issues,…?) Regards, Thomas
Re: New JIRA component for observation
On 31.03.17 07:06, Chetan Mehrotra wrote: On Thu, Mar 30, 2017 at 7:55 PM, Thomas Mueller wrote: Depending on that, we can use "Maven" module boundaries, or "Logical" module boundaries. My preference is for "Logical" module boundaries and not be bounded by the Maven module boundaries. I would prefer to stay aligned with Maven boundaries as much as possible as this simplifies bug reporting for parties not deeply involved with Oak very much. Most of the apparent need to break out of that scheme is to me rather a symptom of missing modularity rather than a cure. If we introduce logical modules in Jira, I strongly suggest to come up with a clear and concise definition for them: what exactly belongs to them, what not? What are the criteria and how are they applied. Can modules overlap? Do they need to stay aligned with the boundaries of the Maven modules or can a logical module be part of multiple Maven modules? Michael
Re: New JIRA component for observation
On Thu, Mar 30, 2017 at 7:55 PM, Thomas Mueller wrote: > Depending on that, we can use "Maven" module boundaries, or "Logical" module > boundaries. My preference is for "Logical" module boundaries and not be bounded by the Maven module boundaries. Chetan Mehrotra
Re: New JIRA component for observation
Hi, I think the main question is, what do we use the Jira component for. Right now, I don't use it. Do we want to use it for statistics, or to be able to "monitor" or "group" issues by group? Depending on that, we can use "Maven" module boundaries, or "Logical" module boundaries. For example, we might want to add "OSGi" even though it's not a separate Maven module. "Observation", "Query", and "Security" are also in multiple Maven projects (at least jcr and core), no matter how we split or not split. Regards, Thomas On 29.03.17, 08:59, "Angela Schreiber" wrote: 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" 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 >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" 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 >>
Re: New JIRA component for observation
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" 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 >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" 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 >>
Re: New JIRA component for observation
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 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" 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 >>> >
Re: New JIRA component for observation
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" 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 >>
Re: New JIRA component for observation
On Mon, Mar 27, 2017 at 12:56 PM, Marcel Reutegger wrote: > 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. For now I prefer a logical separation in JIRA issues. Compared to label the components have better in built support in JIRA ui like open/closed/aging reports, drop down etc. So it would be better to use components over label for such distinct features in Oak. Chetan Mehrotra
Re: New JIRA component for observation
On 27.03.17 09:26, Marcel Reutegger wrote: 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', ... +1 Michael
Re: New JIRA component for observation
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
New JIRA component for observation
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
