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] Division of Cocoon's JIRA project
Date Tue, 21 Aug 2007 14:57:58 GMT
Hi Nils,

Nils Kaiser pisze:

> Well, there is even a nicer way to do this. Depending on which edition 
> of JIRA Apache has, you could add a Custom field "Fix Version 
> (Component)" and "Affects Version (Component)". You should be able to do 
> searches and filters on the field then.

Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and
"Fix 
Version (Component)" we could give up standard JIRA fields as they only cause unnecessary
confusion.

How others feel about such solution?

> In fact, I was asking myself of users would provide such detailled 
> information anyway when they post a new issue. Even if internally, the 
> software is made of components, a user will still download a version in 
> the future - on a user's perspective, the bug will be affecting a cocoon 
> version and not a component version.

Up to date, when releasing Cocoon 2.2 we were focusing on releasing artifacts and putting
them on 
Maven repository. Most of the time we assume (or at least advise) Maven is used so user already

needs to deal with Cocoon artifacts' versions in her own pom. Moreover, Maven already provides
nice 
tools to find out what versions are used so we are likely to ask users this information anyway.

Without exact version of artifact (block) we will not be able to help in most cases, IMO.

All in all, it's not a big deal to ask user to fire mvn project-info-reports:dependencies
command.

> So maybe its more in the responsibily of the developers to recognize and 
> manage the component version anyway... in that case the custom field 
> solution seem to be enough in my opinion.

Or telling user how to provide this information, se above.

> Another remark on the splitted JIRA projects approach: what about issues 
> covering more than one component (for example, feature requests)? Or 
> where the reporting user does not know which components the error 
> belongs to? Or where the components are not existing yet?
> 
> In that case it is much easier to correct the information when the 
> issues are all in one project where you can add the component(s) 
> affected by the issue.

You and others have convinced me that splitting is not such a great idea as I thought previously.

What about this solution?

Anyway, thanks Nils for very useful comments!!

-- 
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. ***

Mime
View raw message