You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/08/26 13:29:19 UTC

[VOTE] Introduce component/module specific version fields in JIRA

Hello,

This is a second attempt to resolve problem with inaccurate version information in JIRA which I
described here[1]. The first one was to split up our COCOON project into several smaller ones[2].
Unfortunately, this option had several drawbacks like broken links to the current issues.
Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He
proposed[3] to introduce custom fields where information about version specific to the *component*
would be stored.

Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
  * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
to component the issue is assigned.
  * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
component the issue is assigned.

It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so
they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes
to handling of multi-module projects where modules are released independently.

Please cast your votes!

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74876
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/74591
[3] http://article.gmane.org/gmane.text.xml.cocoon.devel/74887

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
>   * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
> to component the issue is assigned.
>   * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
> component the issue is assigned.

+1

Vadim

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
> Joerg Heinicke pisze:
>> On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:
>>
>>> Unexpectedly, Nils Kaiser has come up with much better and, in
>>> general, less intrusive solution. He
>>> proposed[3] to introduce custom fields where information about version
>>> specific to the *component*
>>> would be stored.
>> I don't want to rain on the party again, but have you checked the
>> approach with infrastructure team? I fear this effects all projects and
>> I'm not sure they want to do this.
> 
> I checked this here:
> http://www.atlassian.com/software/jira/docs/v3.2/customfields/overview.html#Custom+field+context
> 
> However, I was sure that we have the most recent version of JIRA, here on Apache. According to the
> footer I was wrong, we are still using 3.1.x...
> 
> Without custom field contexts you are probably right, all projects will be affected. On the other
> hand, we already have custom fields (if patch is attached or bugzilla id) that do not appear in
> other projects. Do someone knows how it works?

Ok, I'm LAME! :-D

On Apache we use JIRA 3.10.x not 3.1.x so there will be no problem with our custom fields.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:
> 
>> Unexpectedly, Nils Kaiser has come up with much better and, in
>> general, less intrusive solution. He
>> proposed[3] to introduce custom fields where information about version
>> specific to the *component*
>> would be stored.
> 
> I don't want to rain on the party again, but have you checked the
> approach with infrastructure team? I fear this effects all projects and
> I'm not sure they want to do this.

I checked this here:
http://www.atlassian.com/software/jira/docs/v3.2/customfields/overview.html#Custom+field+context

However, I was sure that we have the most recent version of JIRA, here on Apache. According to the
footer I was wrong, we are still using 3.1.x...

Without custom field contexts you are probably right, all projects will be affected. On the other
hand, we already have custom fields (if patch is attached or bugzilla id) that do not appear in
other projects. Do someone knows how it works?

Basically, I wanted to have a vote result to start talking with infra about something we want to
have and not something we are wondering about. I believe that infra should help us with our needs.

> Second I wonder if this really works (or if I misunderstood something).
> Nils only seems to talk about an additional field to differ between
> "global" version (like Cocoon 2.2) and component version (like CForms
> 1.0). I guess you can't add component-specific select options to the
> fields. I don't see a logical reason that Jira has support for this
> while it has not the same for the existing version fields.

JIRA has cascading field[1] that would help us in this case but one would have to choose components
two times (one time in components field and one in our custom field). That's not perfect, but I
already realized we are not going to find a perfect solution.

> My vote is +1 though.

Thanks.

[1] http://www.atlassian.com/software/jira/docs/v3.2/customfields/configcustomfield.html

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:

> Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He
> proposed[3] to introduce custom fields where information about version specific to the *component*
> would be stored.

I don't want to rain on the party again, but have you checked the 
approach with infrastructure team? I fear this effects all projects and 
I'm not sure they want to do this.

Second I wonder if this really works (or if I misunderstood something). 
Nils only seems to talk about an additional field to differ between 
"global" version (like Cocoon 2.2) and component version (like CForms 
1.0). I guess you can't add component-specific select options to the 
fields. I don't see a logical reason that Jira has support for this 
while it has not the same for the existing version fields.

My vote is +1 though.

Joerg

[VOTE RESULT] Introduce component/module specific version fields in JIRA

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
> 
> Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
>   * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
> to component the issue is assigned.
>   * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
> component the issue is assigned.

I counted five positive votes from Ralph, Joerg, Reinhard, Felix, Vadim and no negative ones so the
vote passed.

I'm going to take care of adding these fields as soon as I have some spare time.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Ralph Goers <Ra...@dslextreme.com>.
Grzegorz Kossakowski wrote:
> Hello,
>
> This is a second attempt to resolve problem with inaccurate version information in JIRA which I
> described here[1]. The first one was to split up our COCOON project into several smaller ones[2].
> Unfortunately, this option had several drawbacks like broken links to the current issues.
> Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He
> proposed[3] to introduce custom fields where information about version specific to the *component*
> would be stored.
>
> Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
>   * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
> to component the issue is assigned.
>   * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
> component the issue is assigned.
>
> It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so
> they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes
> to handling of multi-module projects where modules are released independently.
>
> Please cast your votes!
>   
+1

Ralph

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Felix Knecht <fe...@otego.com>.
>>> Hello,
>>>
>>> This is a second attempt to resolve problem with inaccurate version
>>> information in JIRA which I
>>> described here[1]. The first one was to split up our COCOON project
>>> into several smaller ones[2].
>>> Unfortunately, this option had several drawbacks like broken links to
>>> the current issues.
>>> Unexpectedly, Nils Kaiser has come up with much better and, in
>>> general, less intrusive solution. He
>>> proposed[3] to introduce custom fields where information about
>>> version specific to the *component*
>>> would be stored.
>>>
>>> Thereby, I would like to propose adding two new custom fields in our
>>> COCOON project on JIRA:
>>>   * Affects version (Component) - counterpart of standard Affects
>>> version field in JIRA but limited
>>> to component the issue is assigned.
>>>   * Fix version (Component) - counterpart of standard Fix version
>>> field in JIRA but limited to
>>> component the issue is assigned.
>>>
>>> It's worth to say that, AFAIK, options in fields cannot be filtered
>>> basing on component choice so
>>> they will contain all versions of all components. Unfortunately, JIRA
>>> is very limited when it comes
>>> to handling of multi-module projects where modules are released
>>> independently.
>>>
>>> Please cast your votes!
>>


+1

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>> Hello,
>>
>> This is a second attempt to resolve problem with inaccurate version information in JIRA which I
>> described here[1]. The first one was to split up our COCOON project into several smaller ones[2].
>> Unfortunately, this option had several drawbacks like broken links to the current issues.
>> Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He
>> proposed[3] to introduce custom fields where information about version specific to the *component*
>> would be stored.
>>
>> Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
>>   * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
>> to component the issue is assigned.
>>   * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
>> component the issue is assigned.
>>
>> It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so
>> they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes
>> to handling of multi-module projects where modules are released independently.
>>
>> Please cast your votes!
> 
> I forgot to vote myself, so here is mine:
> +1
> 
> If there is anyone other willing to vote, do it quickly. I'm going to take care of adding new fields
> in upcoming weekend.
> 

+1 for your proposal


-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: [VOTE] Introduce component/module specific version fields in JIRA

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
> Hello,
> 
> This is a second attempt to resolve problem with inaccurate version information in JIRA which I
> described here[1]. The first one was to split up our COCOON project into several smaller ones[2].
> Unfortunately, this option had several drawbacks like broken links to the current issues.
> Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He
> proposed[3] to introduce custom fields where information about version specific to the *component*
> would be stored.
> 
> Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA:
>   * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited
> to component the issue is assigned.
>   * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to
> component the issue is assigned.
> 
> It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so
> they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes
> to handling of multi-module projects where modules are released independently.
> 
> Please cast your votes!

I forgot to vote myself, so here is mine:
+1

If there is anyone other willing to vote, do it quickly. I'm going to take care of adding new fields
in upcoming weekend.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/