cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [VOTE] Introduce component/module specific version fields in JIRA
Date Mon, 27 Aug 2007 08:05:10 GMT
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/

Mime
View raw message