OFBiz › OFBiz - Dev

INCORPORATED ISSUE

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

mrisaliti@libero.it

INCORPORATED ISSUE

Yes, Adrian I move the discussion on dev mailing list.
I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
So I tried to start reorganization of JIRA issues on the following points:

1) assign to all the issues one or more components to understand where more bug/improve are present (done).

2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious component and so I have started to move those issues.
Doing this second step we will have a real view on which components have more issues and need more help.
Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.

3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review and ready to be committed.
So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
I ask if we can add also a new state patch available and patch tested or ready to be committed.

So doing those and others chages can help and speed up in resolution and contribution by committer/developer.

I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.

Thanks in advance
Marco

-------
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]

Marco Risaliti commented on OFBIZ-1151:
---------------------------------------

Also I like this workaround to see how many INCORPORATING ISSUE are active.
Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.

Thanks
Marco

-------

Marco,

Perhaps you should discuss these changes on the dev mailing list before changing them.

-Adrian

BJ Freeman

Re: INCORPORATED ISSUE

So the INCORPORATED ISSUE is taged on all the sub or related tasks?
on related task how do you determine which one should be INCORPORATED ISSUE.
Like to help were I can on the ones I submit

[hidden email] sent the following on 12/20/2007 11:19 AM:

> Yes, Adrian I move the discussion on dev mailing list.
> I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
> So I tried to start reorganization of JIRA issues on the following points:
>
> 1) assign to all the issues one or more components to understand where more bug/improve are present (done).
>
> 2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious component and so I have started to move those issues.
> Doing this second step we will have a real view on which components have more issues and need more help.
> Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.
>
> 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review and ready to be committed.
> So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
> I ask if we can add also a new state patch available and patch tested or ready to be committed.
>
> So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
>
> I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
>
> Thanks in advance
> Marco
>
>
> -------
> [ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]
>
> Marco Risaliti commented on OFBIZ-1151:
> ---------------------------------------
>
> Also I like this workaround to see how many INCORPORATING ISSUE are active.
> Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
>
> Thanks
> Marco
>
> -------
>
> Marco,
>
> Perhaps you should discuss these changes on the dev mailing list before changing them.
>
> -Adrian
>
>
>
>

Adrian Crum

Re: INCORPORATED ISSUE

In reply to this post by mrisaliti@libero.it

Marco,

It's great that you want to work on the Jira issues. I don't agree that changing the components to
INCORPORATED ISSUE makes things easier to understand. Several of the issues you changed were for a
specific component - https://issues.apache.org/jira/browse/OFBIZ-616 for example.

Also keep in mind that issues that are assigned to committers don't need your intervention - because
someone is already working on them.

-Adrian

[hidden email] wrote:

mrisaliti@libero.it

Re: INCORPORATED ISSUE

In reply to this post by mrisaliti@libero.it

Hi Adrian,

I tried to explain better what I want to do with this new INCORPORATING ISSUE.
In your specific case if your issues OFBIZ-1434 and OFBIZ-616 contains both accounting component we will see that accounting component has two different issues instead the issue that affect accounting is only one.
The issue OFBIZ-1434 is only an issue for helping to group issues with the same argument.
So in this case I wrongly put INCORPORATING ISSUE to OFBIZ-616 instead of put it on OFBIZ-1434.

Doing those changes we will se on the JIRA dashboard immediately how many issues are for grouping together issues and making the difference between Open Issues, In Progress, Reopened and INCORPORTING ISSUE we will get immediately how many open issues are really open.

Thanks
Marco

------
Marco,

It's great that you want to work on the Jira issues. I don't agree that changing the components to INCORPORATED ISSUE makes things easier to understand. Several of the issues you changed were for a specific component - https://issues.apache.org/jira/browse/OFBIZ-616 for example.

Also keep in mind that issues that are assigned to committers don't need your intervention - because someone is already working on them.

-Adrian

[hidden email] wrote:

Yes, Adrian I move the discussion on dev mailing list.
I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
So I tried to start reorganization of JIRA issues on the following points:
1) assign to all the issues one or more components to understand where more bug/improve are present (done).
2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious component and so I have started to move those issues.
Doing this second step we will have a real view on which components have more issues and need more help.
Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed. 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review and ready to be committed.
So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
I ask if we can add also a new state patch available and patch tested or ready to be committed.
So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
Thanks in advance
Marco -------
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ] Marco Risaliti commented on OFBIZ-1151:
---------------------------------------
Also I like this workaround to see how many INCORPORATING ISSUE are active.
Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
Thanks
Marco
-------
Marco,
Perhaps you should discuss these changes on the dev mailing list before changing them.
-Adrian

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

In reply to this post by BJ Freeman

Hi All,

I think we need to clarify this. I recently created the INCORPORATING ISSUE component at Marco's demand.

It firstly began around a *very specific* issue I created for the purpose of grouping together all securities issues past and future
(in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525.

At this time I was unable to specify all components as I expected some future security issues to appear and wanted to be able to
collect them there. So I let void the component attribute
Marco seems to use the component attribute to deal with Jira issues. So he asked me to create a specific component to avoid letting
this incorporating issue void of component attribute. Hence I created the INCORPORATING ISSUE.

My goal was nothing more than that. But it seems that Marco has found anther way to use it and I think it's no a good idea. I see
that already Jacopo is undoing some component changes made by Marco and I totally agree with that. Maybe Marco can explain his need
and we will see if another way is possible...

Thanks

Jacques

From: "BJ Freeman" <[hidden email]>

> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
> on related task how do you determine which one should be INCORPORATED ISSUE.
> Like to help were I can on the ones I submit
>
>
> [hidden email] sent the following on 12/20/2007 11:19 AM:
>> Yes, Adrian I move the discussion on dev mailing list.
>> I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
>> So I tried to start reorganization of JIRA issues on the following points:
>>
>> 1) assign to all the issues one or more components to understand where more bug/improve are present (done).
>>
>> 2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious
>> component and so I have started to move those issues.
>> Doing this second step we will have a real view on which components have more issues and need more help.
>> Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.
>>
>> 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review
>> and ready to be committed.
>> So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
>> I ask if we can add also a new state patch available and patch tested or ready to be committed.
>>
>> So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
>>
>> I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
>>
>> Thanks in advance
>> Marco
>>
>>
>> -------
>> [
>> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]
>>
>> Marco Risaliti commented on OFBIZ-1151:
>> ---------------------------------------
>>
>> Also I like this workaround to see how many INCORPORATING ISSUE are active.
>> Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
>>
>> Thanks
>> Marco
>>
>> -------
>>
>> Marco,
>>
>> Perhaps you should discuss these changes on the dev mailing list before changing them.
>>
>> -Adrian
>>
>>
>>
>>
>
>

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

In reply to this post by BJ Freeman

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

In reply to this post by BJ Freeman

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

In reply to this post by Jacques Le Roux

Sorry for the possible triple post, I have some pbs with my ISP's SMTP server.

I reverted some also. I only kept some that made sense even if they were not totally and only incorporating other issues.

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Hi All,
>
> I think we need to clarify this. I recently created the INCORPORATING ISSUE component at Marco's demand.
>
> It firstly began around a *very specific* issue I created for the purpose of grouping together all securities issues past and
> future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525.
>
> At this time I was unable to specify all components as I expected some future security issues to appear and wanted to be able to
> collect them there. So I let void the component attribute
> Marco seems to use the component attribute to deal with Jira issues. So he asked me to create a specific component to avoid
> letting this incorporating issue void of component attribute. Hence I created the INCORPORATING ISSUE.
>
> My goal was nothing more than that. But it seems that Marco has found anther way to use it and I think it's no a good idea. I see
> that already Jacopo is undoing some component changes made by Marco and I totally agree with that. Maybe Marco can explain his
> need and we will see if another way is possible...
>
> Thanks
>
> Jacques
>
>
> From: "BJ Freeman" <[hidden email]>
>> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
>> on related task how do you determine which one should be INCORPORATED ISSUE.
>> Like to help were I can on the ones I submit
>>
>>
>> [hidden email] sent the following on 12/20/2007 11:19 AM:
>>> Yes, Adrian I move the discussion on dev mailing list.
>>> I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
>>> So I tried to start reorganization of JIRA issues on the following points:
>>>
>>> 1) assign to all the issues one or more components to understand where more bug/improve are present (done).
>>>
>>> 2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious
>>> component and so I have started to move those issues.
>>> Doing this second step we will have a real view on which components have more issues and need more help.
>>> Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.
>>>
>>> 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch
>>> review and ready to be committed.
>>> So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
>>> I ask if we can add also a new state patch available and patch tested or ready to be committed.
>>>
>>> So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
>>>
>>> I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
>>>
>>> Thanks in advance
>>> Marco
>>>
>>>
>>> -------
>>> [
>>> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]
>>>
>>> Marco Risaliti commented on OFBIZ-1151:
>>> ---------------------------------------
>>>
>>> Also I like this workaround to see how many INCORPORATING ISSUE are active.
>>> Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
>>>
>>> Thanks
>>> Marco
>>>
>>> -------
>>>
>>> Marco,
>>>
>>> Perhaps you should discuss these changes on the dev mailing list before changing them.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>
>>
>
>

mrisaliti@libero.it

Re: INCORPORATED ISSUE

In reply to this post by mrisaliti@libero.it

Hi Jacques,

for the INCORPORATING ISSUE I think to issue that contains link to single issue.
So for example the issue OFBIZ-1463 is the father (INCORPORATING ISSUE) of 8 issues and everyone are improvements on framework component.
If we set the father issue also to the framework component we will have 9 issues that are based to this component instead there are in reality 8.
That's my idea but if no one like it I can rollback everything.

Marco
---
Hi All,

I think we need to clarify this. I recently created the INCORPORATING ISSUE component at Marco's demand.

It firstly began around a *very specific* issue I created for the purpose of grouping together all securities issues past and future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525.

At this time I was unable to specify all components as I expected some future security issues to appear and wanted to be able to collect them there. So I let void the component attribute
Marco seems to use the component attribute to deal with Jira issues. So he asked me to create a specific component to avoid letting this incorporating issue void of component attribute. Hence I created the INCORPORATING ISSUE.

My goal was nothing more than that. But it seems that Marco has found anther way to use it and I think it's no a good idea. I see that already Jacopo is undoing some component changes made by Marco and I totally agree with that. Maybe Marco can explain his need and we will see if another way is possible...

Thanks

Jacques

From: "BJ Freeman" <[hidden email]>
So the INCORPORATED ISSUE is taged on all the sub or related tasks?
on related task how do you determine which one should be INCORPORATED ISSUE.
Like to help were I can on the ones I submit

[hidden email] sent the following on 12/20/2007 11:19 AM:
Yes, Adrian I move the discussion on dev mailing list.
I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
So I tried to start reorganization of JIRA issues on the following points:

1) assign to all the issues one or more components to understand where more bug/improve are present (done).

2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious component and so I have started to move those issues.
Doing this second step we will have a real view on which components have more issues and need more help.
Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.

3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review and ready to be committed.
So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
I ask if we can add also a new state patch available and patch tested or ready to be committed.

So doing those and others chages can help and speed up in resolution and contribution by committer/developer.

I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.

Thanks in advance
Marco

-------
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]

Marco Risaliti commented on OFBIZ-1151:
---------------------------------------

Also I like this workaround to see how many INCORPORATING ISSUE are active.
Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.

Thanks
Marco

-------

Marco,

Perhaps you should discuss these changes on the dev mailing list before changing them.

-Adrian

BJ Freeman

Re: INCORPORATED ISSUE

I think the use of the status is more appropiate
you have a status for has patch for instance.
using the statuses to move a Jira along is more appropiate

[hidden email] sent the following on 12/20/2007 3:10 PM:

> Hi Jacques,
>
> for the INCORPORATING ISSUE I think to issue that contains link to single issue.
> So for example the issue OFBIZ-1463 is the father (INCORPORATING ISSUE) of 8 issues and everyone are improvements on framework component.
> If we set the father issue also to the framework component we will have 9 issues that are based to this component instead there are in reality 8.
> That's my idea but if no one like it I can rollback everything.
>
> Marco
> ---
> Hi All,
>
> I think we need to clarify this. I recently created the INCORPORATING ISSUE component at Marco's demand.
>
> It firstly began around a *very specific* issue I created for the purpose of grouping together all securities issues past and future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525.
>
> At this time I was unable to specify all components as I expected some future security issues to appear and wanted to be able to collect them there. So I let void the component attribute
> Marco seems to use the component attribute to deal with Jira issues. So he asked me to create a specific component to avoid letting this incorporating issue void of component attribute. Hence I created the INCORPORATING ISSUE.
>
> My goal was nothing more than that. But it seems that Marco has found anther way to use it and I think it's no a good idea. I see that already Jacopo is undoing some component changes made by Marco and I totally agree with that. Maybe Marco can explain his need and we will see if another way is possible...
>
> Thanks
>
> Jacques
>
>
> From: "BJ Freeman" <[hidden email]>
> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
> on related task how do you determine which one should be INCORPORATED ISSUE.
> Like to help were I can on the ones I submit
>
>
> [hidden email] sent the following on 12/20/2007 11:19 AM:
> Yes, Adrian I move the discussion on dev mailing list.
> I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
> So I tried to start reorganization of JIRA issues on the following points:
>
> 1) assign to all the issues one or more components to understand where more bug/improve are present (done).
>
> 2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious component and so I have started to move those issues.
> Doing this second step we will have a real view on which components have more issues and need more help.
> Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.
>
> 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review and ready to be committed.
> So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
> I ask if we can add also a new state patch available and patch tested or ready to be committed.
>
> So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
>
> I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
>
> Thanks in advance
> Marco
>
>
> -------
> [ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]
>
> Marco Risaliti commented on OFBIZ-1151:
> ---------------------------------------
>
> Also I like this workaround to see how many INCORPORATING ISSUE are active.
> Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
>
> Thanks
> Marco
>
> -------
>
> Marco,
>
> Perhaps you should discuss these changes on the dev mailing list before changing them.
>
> -Adrian
>
>
>
>
>
>
>
>
>
>

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

In reply to this post by mrisaliti@libero.it

Marco,

Yes I agree that in some cases we should use it. I kept some, please see
http://issues.apache.org/jira/browse/OFBIZ/component/12312085 for those interested.

I guess how to use it is a matter of common sense.

Thanks

Jacques

From: <[hidden email]>

> Hi Jacques,
>
> for the INCORPORATING ISSUE I think to issue that contains link to single issue.
> So for example the issue OFBIZ-1463 is the father (INCORPORATING ISSUE) of 8 issues and everyone are improvements on framework
> component.
> If we set the father issue also to the framework component we will have 9 issues that are based to this component instead there
> are in reality 8.
> That's my idea but if no one like it I can rollback everything.
>
> Marco
> ---
> Hi All,
>
> I think we need to clarify this. I recently created the INCORPORATING ISSUE component at Marco's demand.
>
> It firstly began around a *very specific* issue I created for the purpose of grouping together all securities issues past and
> future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525.
>
> At this time I was unable to specify all components as I expected some future security issues to appear and wanted to be able to
> collect them there. So I let void the component attribute
> Marco seems to use the component attribute to deal with Jira issues. So he asked me to create a specific component to avoid
> letting this incorporating issue void of component attribute. Hence I created the INCORPORATING ISSUE.
>
> My goal was nothing more than that. But it seems that Marco has found anther way to use it and I think it's no a good idea. I see
> that already Jacopo is undoing some component changes made by Marco and I totally agree with that. Maybe Marco can explain his
> need and we will see if another way is possible...
>
> Thanks
>
> Jacques
>
>
> From: "BJ Freeman" <[hidden email]>
> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
> on related task how do you determine which one should be INCORPORATED ISSUE.
> Like to help were I can on the ones I submit
>
>
> [hidden email] sent the following on 12/20/2007 11:19 AM:
> Yes, Adrian I move the discussion on dev mailing list.
> I'm sorry but was not my intention to made confusion on JIRA issues but instead remove confusion from JIRA issues.
> So I tried to start reorganization of JIRA issues on the following points:
>
> 1) assign to all the issues one or more components to understand where more bug/improve are present (done).
>
> 2) for the INCORPORATED ISSUE (issue that contains link to single issue) I would like to switch those to the new fictitious
> component and so I have started to move those issues.
> Doing this second step we will have a real view on which components have more issues and need more help.
> Some current INCORPORATED ISSUE has now all the linked issues closed but the main issue has been not yet closed.
>
> 3) at the moment committer cannot understand easily which issue has already patch attached to it and issue that have patch review
> and ready to be committed.
> So it's a very big problem for a new committer like me understand where I can help like committer or like contributor.
> I ask if we can add also a new state patch available and patch tested or ready to be committed.
>
> So doing those and others chages can help and speed up in resolution and contribution by committer/developer.
>
> I would like to receive some feedbacks otherwise I'm thinking that normally people accept my proposals.
>
> Thanks in advance
> Marco
>
>
> -------
> [
> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553492 ]
>
> Marco Risaliti commented on OFBIZ-1151:
> ---------------------------------------
>
> Also I like this workaround to see how many INCORPORATING ISSUE are active.
> Before switch the others INCORPORATING ISSUE to this new fictitious components I will wait some other feedback from others.
>
> Thanks
> Marco
>
> -------
>
> Marco,
>
> Perhaps you should discuss these changes on the dev mailing list before changing them.
>
> -Adrian
>
>
>
>
>
>
>
>
>

David E Jones

Re: INCORPORATED ISSUE

Yeah... I'm not sure I agree with this, or like the idea of this as a
"component" at all. It seems like all of these issues are better
solved through other means, some of which has been discussed here, and
more discussion of this for anyone who isn't sure about what to do in
a certain situation is certainly appropriate.

Unless there is a REALLY good reason to keep it I'd rather not dilute
(or destroy!) the concept of the components in the system that are
associated with something (keeping in mind that more than one
component can be associated with an issue). What I'd rather see is
that this be totally removed. What concerns me the most is that this
came out of a failure to "read before writing", or to understand
existing processes and discuss issues with them or propose extensions
to them. A lot of this is de-facto and based just on how Jira and
other things are used and isn't really documented anywhere, so the
best approach to all of this is discussion, being as specific and
concise as possible to facilitate it of course!

If anyone (Marco, please chime in too!) has an objection to removing
it or specific reason why it is needed, then let's talk about that and
see if there is a better/cleaner way, or more likely a way that we're
already doing things.

-David

On Dec 20, 2007, at 3:25 PM, Jacques Le Roux wrote:

> Marco,
>
> Yes I agree that in some cases we should use it. I kept some, please
> see http://issues.apache.org/jira/browse/OFBIZ/component/12312085
> for those interested.
>
> I guess how to use it is a matter of common sense.
>
> Thanks
>
> Jacques
>
> From: <[hidden email]>
>> Hi Jacques,
>>
>> for the INCORPORATING ISSUE I think to issue that contains link to
>> single issue.
>> So for example the issue OFBIZ-1463 is the father (INCORPORATING
>> ISSUE) of 8 issues and everyone are improvements on framework
>> component.
>> If we set the father issue also to the framework component we will
>> have 9 issues that are based to this component instead there
>> are in reality 8.
>> That's my idea but if no one like it I can rollback everything.
>>
>> Marco
>> ---
>> Hi All,
>>
>> I think we need to clarify this. I recently created the
>> INCORPORATING ISSUE component at Marco's demand.
>>
>> It firstly began around a *very specific* issue I created for the
>> purpose of grouping together all securities issues past and
>> future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525
>> .
>>
>> At this time I was unable to specify all components as I expected
>> some future security issues to appear and wanted to be able to
>> collect them there. So I let void the component attribute
>> Marco seems to use the component attribute to deal with Jira
>> issues. So he asked me to create a specific component to avoid
>> letting this incorporating issue void of component attribute. Hence
>> I created the INCORPORATING ISSUE.
>>
>> My goal was nothing more than that. But it seems that Marco has
>> found anther way to use it and I think it's no a good idea. I see
>> that already Jacopo is undoing some component changes made by Marco
>> and I totally agree with that. Maybe Marco can explain his
>> need and we will see if another way is possible...
>>
>> Thanks
>>
>> Jacques
>>
>>
>> From: "BJ Freeman" <[hidden email]>
>> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
>> on related task how do you determine which one should be
>> INCORPORATED ISSUE.
>> Like to help were I can on the ones I submit
>>
>>
>> [hidden email] sent the following on 12/20/2007 11:19 AM:
>> Yes, Adrian I move the discussion on dev mailing list.
>> I'm sorry but was not my intention to made confusion on JIRA issues
>> but instead remove confusion from JIRA issues.
>> So I tried to start reorganization of JIRA issues on the following
>> points:
>>
>> 1) assign to all the issues one or more components to understand
>> where more bug/improve are present (done).
>>
>> 2) for the INCORPORATED ISSUE (issue that contains link to single
>> issue) I would like to switch those to the new fictitious
>> component and so I have started to move those issues.
>> Doing this second step we will have a real view on which components
>> have more issues and need more help.
>> Some current INCORPORATED ISSUE has now all the linked issues
>> closed but the main issue has been not yet closed.
>>
>> 3) at the moment committer cannot understand easily which issue has
>> already patch attached to it and issue that have patch review
>> and ready to be committed.
>> So it's a very big problem for a new committer like me understand
>> where I can help like committer or like contributor.
>> I ask if we can add also a new state patch available and patch
>> tested or ready to be committed.
>>
>> So doing those and others chages can help and speed up in
>> resolution and contribution by committer/developer.
>>
>> I would like to receive some feedbacks otherwise I'm thinking that
>> normally people accept my proposals.
>>
>> Thanks in advance
>> Marco
>>
>>
>> -------
>> [
>> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
>> #action_12553492 ]
>>
>> Marco Risaliti commented on OFBIZ-1151:
>> ---------------------------------------
>>
>> Also I like this workaround to see how many INCORPORATING ISSUE are
>> active.
>> Before switch the others INCORPORATING ISSUE to this new fictitious
>> components I will wait some other feedback from others.
>>
>> Thanks
>> Marco
>>
>> -------
>>
>> Marco,
>>
>> Perhaps you should discuss these changes on the dev mailing list
>> before changing them.
>>
>> -Adrian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

smime.p7s (3K) Download Attachment

mrisaliti@libero.it

Re: INCORPORATED ISSUE

In reply to this post by mrisaliti@libero.it

I'm sorry probably I made same confusion and it was not my intention to do it but instead to have a cleared situation of issues into JIRA.
In any case if no one like the idea INCORPORATING ISSUE I remove it from the actual issues and if you can remove it from the components everythings go back as previously.
In my opinion made some changes into JIRA can help committer/developer to understand where can contribute.

Thanks
Marco

>
> Yeah... I'm not sure I agree with this, or like the idea of this as a
> "component" at all. It seems like all of these issues are better
> solved through other means, some of which has been discussed here, and
> more discussion of this for anyone who isn't sure about what to do in
> a certain situation is certainly appropriate.
>
> Unless there is a REALLY good reason to keep it I'd rather not dilute
> (or destroy!) the concept of the components in the system that are
> associated with something (keeping in mind that more than one
> component can be associated with an issue). What I'd rather see is
> that this be totally removed. What concerns me the most is that this
> came out of a failure to "read before writing", or to understand
> existing processes and discuss issues with them or propose extensions
> to them. A lot of this is de-facto and based just on how Jira and
> other things are used and isn't really documented anywhere, so the
> best approach to all of this is discussion, being as specific and
> concise as possible to facilitate it of course!
>
> If anyone (Marco, please chime in too!) has an objection to removing
> it or specific reason why it is needed, then let's talk about that and
> see if there is a better/cleaner way, or more likely a way that we're
> already doing things.
>
> -David
>
>
> On Dec 20, 2007, at 3:25 PM, Jacques Le Roux wrote:
>
> > Marco,
> >
> > Yes I agree that in some cases we should use it. I kept some, please
> > see http://issues.apache.org/jira/browse/OFBIZ/component/12312085
> > for those interested.
> >
> > I guess how to use it is a matter of common sense.
> >
> > Thanks
> >
> > Jacques
> >
> > From: <[hidden email]>
> >> Hi Jacques,
> >>
> >> for the INCORPORATING ISSUE I think to issue that contains link to
> >> single issue.
> >> So for example the issue OFBIZ-1463 is the father (INCORPORATING
> >> ISSUE) of 8 issues and everyone are improvements on framework
> >> component.
> >> If we set the father issue also to the framework component we will
> >> have 9 issues that are based to this component instead there
> >> are in reality 8.
> >> That's my idea but if no one like it I can rollback everything.
> >>
> >> Marco
> >> ---
> >> Hi All,
> >>
> >> I think we need to clarify this. I recently created the
> >> INCORPORATING ISSUE component at Marco's demand.
> >>
> >> It firstly began around a *very specific* issue I created for the
> >> purpose of grouping together all securities issues past and
> >> future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525
> >> .
> >>
> >> At this time I was unable to specify all components as I expected
> >> some future security issues to appear and wanted to be able to
> >> collect them there. So I let void the component attribute
> >> Marco seems to use the component attribute to deal with Jira
> >> issues. So he asked me to create a specific component to avoid
> >> letting this incorporating issue void of component attribute. Hence
> >> I created the INCORPORATING ISSUE.
> >>
> >> My goal was nothing more than that. But it seems that Marco has
> >> found anther way to use it and I think it's no a good idea. I see
> >> that already Jacopo is undoing some component changes made by Marco
> >> and I totally agree with that. Maybe Marco can explain his
> >> need and we will see if another way is possible...
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
> >> From: "BJ Freeman" <[hidden email]>
> >> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
> >> on related task how do you determine which one should be
> >> INCORPORATED ISSUE.
> >> Like to help were I can on the ones I submit
> >>
> >>
> >> [hidden email] sent the following on 12/20/2007 11:19 AM:
> >> Yes, Adrian I move the discussion on dev mailing list.
> >> I'm sorry but was not my intention to made confusion on JIRA issues
> >> but instead remove confusion from JIRA issues.
> >> So I tried to start reorganization of JIRA issues on the following
> >> points:
> >>
> >> 1) assign to all the issues one or more components to understand
> >> where more bug/improve are present (done).
> >>
> >> 2) for the INCORPORATED ISSUE (issue that contains link to single
> >> issue) I would like to switch those to the new fictitious
> >> component and so I have started to move those issues.
> >> Doing this second step we will have a real view on which components
> >> have more issues and need more help.
> >> Some current INCORPORATED ISSUE has now all the linked issues
> >> closed but the main issue has been not yet closed.
> >>
> >> 3) at the moment committer cannot understand easily which issue has
> >> already patch attached to it and issue that have patch review
> >> and ready to be committed.
> >> So it's a very big problem for a new committer like me understand
> >> where I can help like committer or like contributor.
> >> I ask if we can add also a new state patch available and patch
> >> tested or ready to be committed.
> >>
> >> So doing those and others chages can help and speed up in
> >> resolution and contribution by committer/developer.
> >>
> >> I would like to receive some feedbacks otherwise I'm thinking that
> >> normally people accept my proposals.
> >>
> >> Thanks in advance
> >> Marco
> >>
> >>
> >> -------
> >> [
> >> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
> >> #action_12553492 ]
> >>
> >> Marco Risaliti commented on OFBIZ-1151:
> >> ---------------------------------------
> >>
> >> Also I like this workaround to see how many INCORPORATING ISSUE are
> >> active.
> >> Before switch the others INCORPORATING ISSUE to this new fictitious
> >> components I will wait some other feedback from others.
> >>
> >> Thanks
> >> Marco
> >>
> >> -------
> >>
> >> Marco,
> >>
> >> Perhaps you should discuss these changes on the dev mailing list
> >> before changing them.
> >>
> >> -Adrian
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>

Jacques Le Roux

Re: INCORPORATED ISSUE

Administrator

I have no strong opinion with this. Like I said, It might be usefull for some rare issues. But if it's confusing a Jira admistrator
can just drop it...

Note : if we drop it, it might be interesting to consider the opportunity to create a special component entry : ALL COMPONENTS. It's
easier to check a sole entry than check all components (using uppercase to find it easily). WDYTF© (What Do You Think Folks ;o) ?

Jacques

From: <[hidden email]>

> I'm sorry probably I made same confusion and it was not my intention to do it but instead to have a cleared situation of issues
> into JIRA.
> In any case if no one like the idea INCORPORATING ISSUE I remove it from the actual issues and if you can remove it from the
> components everythings go back as previously.
> In my opinion made some changes into JIRA can help committer/developer to understand where can contribute.
>
> Thanks
> Marco
>
>>
>> Yeah... I'm not sure I agree with this, or like the idea of this as a
>> "component" at all. It seems like all of these issues are better
>> solved through other means, some of which has been discussed here, and
>> more discussion of this for anyone who isn't sure about what to do in
>> a certain situation is certainly appropriate.
>>
>> Unless there is a REALLY good reason to keep it I'd rather not dilute
>> (or destroy!) the concept of the components in the system that are
>> associated with something (keeping in mind that more than one
>> component can be associated with an issue). What I'd rather see is
>> that this be totally removed. What concerns me the most is that this
>> came out of a failure to "read before writing", or to understand
>> existing processes and discuss issues with them or propose extensions
>> to them. A lot of this is de-facto and based just on how Jira and
>> other things are used and isn't really documented anywhere, so the
>> best approach to all of this is discussion, being as specific and
>> concise as possible to facilitate it of course!
>>
>> If anyone (Marco, please chime in too!) has an objection to removing
>> it or specific reason why it is needed, then let's talk about that and
>> see if there is a better/cleaner way, or more likely a way that we're
>> already doing things.
>>
>> -David
>>
>>
>> On Dec 20, 2007, at 3:25 PM, Jacques Le Roux wrote:
>>
>> > Marco,
>> >
>> > Yes I agree that in some cases we should use it. I kept some, please
>> > see http://issues.apache.org/jira/browse/OFBIZ/component/12312085
>> > for those interested.
>> >
>> > I guess how to use it is a matter of common sense.
>> >
>> > Thanks
>> >
>> > Jacques
>> >
>> > From: <[hidden email]>
>> >> Hi Jacques,
>> >>
>> >> for the INCORPORATING ISSUE I think to issue that contains link to
>> >> single issue.
>> >> So for example the issue OFBIZ-1463 is the father (INCORPORATING
>> >> ISSUE) of 8 issues and everyone are improvements on framework
>> >> component.
>> >> If we set the father issue also to the framework component we will
>> >> have 9 issues that are based to this component instead there
>> >> are in reality 8.
>> >> That's my idea but if no one like it I can rollback everything.
>> >>
>> >> Marco
>> >> ---
>> >> Hi All,
>> >>
>> >> I think we need to clarify this. I recently created the
>> >> INCORPORATING ISSUE component at Marco's demand.
>> >>
>> >> It firstly began around a *very specific* issue I created for the
>> >> purpose of grouping together all securities issues past and
>> >> future (in any states, open, closed, etc.) https://issues.apache.org/jira/browse/OFBIZ-1525
>> >> .
>> >>
>> >> At this time I was unable to specify all components as I expected
>> >> some future security issues to appear and wanted to be able to
>> >> collect them there. So I let void the component attribute
>> >> Marco seems to use the component attribute to deal with Jira
>> >> issues. So he asked me to create a specific component to avoid
>> >> letting this incorporating issue void of component attribute. Hence
>> >> I created the INCORPORATING ISSUE.
>> >>
>> >> My goal was nothing more than that. But it seems that Marco has
>> >> found anther way to use it and I think it's no a good idea. I see
>> >> that already Jacopo is undoing some component changes made by Marco
>> >> and I totally agree with that. Maybe Marco can explain his
>> >> need and we will see if another way is possible...
>> >>
>> >> Thanks
>> >>
>> >> Jacques
>> >>
>> >>
>> >> From: "BJ Freeman" <[hidden email]>
>> >> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
>> >> on related task how do you determine which one should be
>> >> INCORPORATED ISSUE.
>> >> Like to help were I can on the ones I submit
>> >>
>> >>
>> >> [hidden email] sent the following on 12/20/2007 11:19 AM:
>> >> Yes, Adrian I move the discussion on dev mailing list.
>> >> I'm sorry but was not my intention to made confusion on JIRA issues
>> >> but instead remove confusion from JIRA issues.
>> >> So I tried to start reorganization of JIRA issues on the following
>> >> points:
>> >>
>> >> 1) assign to all the issues one or more components to understand
>> >> where more bug/improve are present (done).
>> >>
>> >> 2) for the INCORPORATED ISSUE (issue that contains link to single
>> >> issue) I would like to switch those to the new fictitious
>> >> component and so I have started to move those issues.
>> >> Doing this second step we will have a real view on which components
>> >> have more issues and need more help.
>> >> Some current INCORPORATED ISSUE has now all the linked issues
>> >> closed but the main issue has been not yet closed.
>> >>
>> >> 3) at the moment committer cannot understand easily which issue has
>> >> already patch attached to it and issue that have patch review
>> >> and ready to be committed.
>> >> So it's a very big problem for a new committer like me understand
>> >> where I can help like committer or like contributor.
>> >> I ask if we can add also a new state patch available and patch
>> >> tested or ready to be committed.
>> >>
>> >> So doing those and others chages can help and speed up in
>> >> resolution and contribution by committer/developer.
>> >>
>> >> I would like to receive some feedbacks otherwise I'm thinking that
>> >> normally people accept my proposals.
>> >>
>> >> Thanks in advance
>> >> Marco
>> >>
>> >>
>> >> -------
>> >> [
>> >> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
>> >> #action_12553492 ]
>> >>
>> >> Marco Risaliti commented on OFBIZ-1151:
>> >> ---------------------------------------
>> >>
>> >> Also I like this workaround to see how many INCORPORATING ISSUE are
>> >> active.
>> >> Before switch the others INCORPORATING ISSUE to this new fictitious
>> >> components I will wait some other feedback from others.
>> >>
>> >> Thanks
>> >> Marco
>> >>
>> >> -------
>> >>
>> >> Marco,
>> >>
>> >> Perhaps you should discuss these changes on the dev mailing list
>> >> before changing them.
>> >>
>> >> -Adrian
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>
>
>

BJ Freeman

Re: INCORPORATED ISSUE

I am not clear on what this does
however I guess it is more for commiters to evaluate if a Jira is open
for Count.
so once decided a explanation my be helpful, if my understanding is not
correct

I have few questions, if you use the statuses, How will searching for
Open help. would you not have to search for all the statuses that
indicated not closed or not resolved.

How do you evaluate statuses like Hold.

maybe find a way t count the top jira for those that are related by sub
task.

Jacques Le Roux sent the following on 12/21/2007 1:09 AM:

> I have no strong opinion with this. Like I said, It might be usefull for
> some rare issues. But if it's confusing a Jira admistrator
> can just drop it...
>
> Note : if we drop it, it might be interesting to consider the
> opportunity to create a special component entry : ALL COMPONENTS. It's
> easier to check a sole entry than check all components (using uppercase
> to find it easily). WDYTF© (What Do You Think Folks ;o) ?
>
> Jacques
>
> From: <[hidden email]>
>> I'm sorry probably I made same confusion and it was not my intention
>> to do it but instead to have a cleared situation of issues
>> into JIRA.
>> In any case if no one like the idea INCORPORATING ISSUE I remove it
>> from the actual issues and if you can remove it from the
>> components everythings go back as previously.
>> In my opinion made some changes into JIRA can help committer/developer
>> to understand where can contribute.
>>
>> Thanks
>> Marco
>>
>>>
>>> Yeah... I'm not sure I agree with this, or like the idea of this as a
>>> "component" at all. It seems like all of these issues are better
>>> solved through other means, some of which has been discussed here, and
>>> more discussion of this for anyone who isn't sure about what to do in
>>> a certain situation is certainly appropriate.
>>>
>>> Unless there is a REALLY good reason to keep it I'd rather not dilute
>>> (or destroy!) the concept of the components in the system that are
>>> associated with something (keeping in mind that more than one
>>> component can be associated with an issue). What I'd rather see is
>>> that this be totally removed. What concerns me the most is that this
>>> came out of a failure to "read before writing", or to understand
>>> existing processes and discuss issues with them or propose extensions
>>> to them. A lot of this is de-facto and based just on how Jira and
>>> other things are used and isn't really documented anywhere, so the
>>> best approach to all of this is discussion, being as specific and
>>> concise as possible to facilitate it of course!
>>>
>>> If anyone (Marco, please chime in too!) has an objection to removing
>>> it or specific reason why it is needed, then let's talk about that and
>>> see if there is a better/cleaner way, or more likely a way that we're
>>> already doing things.
>>>
>>> -David
>>>
>>>
>>> On Dec 20, 2007, at 3:25 PM, Jacques Le Roux wrote:
>>>
>>> > Marco,
>>> >
>>> > Yes I agree that in some cases we should use it. I kept some, please
>>> > see http://issues.apache.org/jira/browse/OFBIZ/component/12312085
>>> > for those interested.
>>> >
>>> > I guess how to use it is a matter of common sense.
>>> >
>>> > Thanks
>>> >
>>> > Jacques
>>> >
>>> > From: <[hidden email]>
>>> >> Hi Jacques,
>>> >>
>>> >> for the INCORPORATING ISSUE I think to issue that contains link to
>>> >> single issue.
>>> >> So for example the issue OFBIZ-1463 is the father (INCORPORATING
>>> >> ISSUE) of 8 issues and everyone are improvements on framework
>>> >> component.
>>> >> If we set the father issue also to the framework component we will
>>> >> have 9 issues that are based to this component instead there
>>> >> are in reality 8.
>>> >> That's my idea but if no one like it I can rollback everything.
>>> >>
>>> >> Marco
>>> >> ---
>>> >> Hi All,
>>> >>
>>> >> I think we need to clarify this. I recently created the
>>> >> INCORPORATING ISSUE component at Marco's demand.
>>> >>
>>> >> It firstly began around a *very specific* issue I created for the
>>> >> purpose of grouping together all securities issues past and
>>> >> future (in any states, open, closed, etc.)
>>> https://issues.apache.org/jira/browse/OFBIZ-1525
>>> >> .
>>> >>
>>> >> At this time I was unable to specify all components as I expected
>>> >> some future security issues to appear and wanted to be able to
>>> >> collect them there. So I let void the component attribute
>>> >> Marco seems to use the component attribute to deal with Jira
>>> >> issues. So he asked me to create a specific component to avoid
>>> >> letting this incorporating issue void of component attribute. Hence
>>> >> I created the INCORPORATING ISSUE.
>>> >>
>>> >> My goal was nothing more than that. But it seems that Marco has
>>> >> found anther way to use it and I think it's no a good idea. I see
>>> >> that already Jacopo is undoing some component changes made by Marco
>>> >> and I totally agree with that. Maybe Marco can explain his
>>> >> need and we will see if another way is possible...
>>> >>
>>> >> Thanks
>>> >>
>>> >> Jacques
>>> >>
>>> >>
>>> >> From: "BJ Freeman" <[hidden email]>
>>> >> So the INCORPORATED ISSUE is taged on all the sub or related tasks?
>>> >> on related task how do you determine which one should be
>>> >> INCORPORATED ISSUE.
>>> >> Like to help were I can on the ones I submit
>>> >>
>>> >>
>>> >> [hidden email] sent the following on 12/20/2007 11:19 AM:
>>> >> Yes, Adrian I move the discussion on dev mailing list.
>>> >> I'm sorry but was not my intention to made confusion on JIRA issues
>>> >> but instead remove confusion from JIRA issues.
>>> >> So I tried to start reorganization of JIRA issues on the following
>>> >> points:
>>> >>
>>> >> 1) assign to all the issues one or more components to understand
>>> >> where more bug/improve are present (done).
>>> >>
>>> >> 2) for the INCORPORATED ISSUE (issue that contains link to single
>>> >> issue) I would like to switch those to the new fictitious
>>> >> component and so I have started to move those issues.
>>> >> Doing this second step we will have a real view on which components
>>> >> have more issues and need more help.
>>> >> Some current INCORPORATED ISSUE has now all the linked issues
>>> >> closed but the main issue has been not yet closed.
>>> >>
>>> >> 3) at the moment committer cannot understand easily which issue has
>>> >> already patch attached to it and issue that have patch review
>>> >> and ready to be committed.
>>> >> So it's a very big problem for a new committer like me understand
>>> >> where I can help like committer or like contributor.
>>> >> I ask if we can add also a new state patch available and patch
>>> >> tested or ready to be committed.
>>> >>
>>> >> So doing those and others chages can help and speed up in
>>> >> resolution and contribution by committer/developer.
>>> >>
>>> >> I would like to receive some feedbacks otherwise I'm thinking that
>>> >> normally people accept my proposals.
>>> >>
>>> >> Thanks in advance
>>> >> Marco
>>> >>
>>> >>
>>> >> -------
>>> >> [
>>> >>
>>> https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
>>>
>>> >> #action_12553492 ]
>>> >>
>>> >> Marco Risaliti commented on OFBIZ-1151:
>>> >> ---------------------------------------
>>> >>
>>> >> Also I like this workaround to see how many INCORPORATING ISSUE are
>>> >> active.
>>> >> Before switch the others INCORPORATING ISSUE to this new fictitious
>>> >> components I will wait some other feedback from others.
>>> >>
>>> >> Thanks
>>> >> Marco
>>> >>
>>> >> -------
>>> >>
>>> >> Marco,
>>> >>
>>> >> Perhaps you should discuss these changes on the dev mailing list
>>> >> before changing them.
>>> >>
>>> >> -Adrian
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>>
>
>
>
>