[sakai2-tcc] add Target version field in Jira?

[Neal Caidin]

I don't think the merge fields quite do the trick because they only indicate the merge intention to a branch, not to a particular tag. And I hypothesis, but of course could be very very wrong, that adding a target version will help, over time, the data to improve, because it will make the overall process clearer. While (thanks to your help) the processes and fields among the various projects are starting to converge, but they are still different and have different management processes in place (which makes sense to some extent, since that would be the idea of an Indie).

-- Neal

On Mar 12, 2013, at 10:17 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:

> The merge fields already address this need in my opinion (at least for
> the CLE and KNL projects). Indies which use their own versioning are
> not really part of the same schedule so they shouldn't be using the
> same fields. We already have filters which use those fields and as far
> as I can tell they work.
> 
> The fix version and affects version fields already tend to be wrong in
> many cases and adding another field is just going to me more wrong
> data.
> Maybe a better task would be fix up all the wrong fix and affects
> versions. After that is completed we can look at adding more fields
> and decide how we would maintain them accurately going forward.
> 
> -AZ
> 
> 
> On Tue, Mar 12, 2013 at 10:09 PM, Neal Caidin
> <nealcaidin at sakaifoundation.org> wrote:
>> Hi TCC,
>> 
>> This has come up before, recently I think, but I bring it up again because I think there is still a need. As I work on a query to cross projects for identify issues for qa testing, merging, etc, I still see an important use case of Jiras which it is not clear if they are intended for a particular release (2.9.2, for example), and after the fact, to identify issues that have been merged into the release (inconsistent use of fix version).
>> 
>> Two possible strategies, both of which seem reasonable to me are:
>> 
>> 1) Use of labels. The advantage of labels is that across the main project and indie projects we can use the same label to tie things together for a particular release, even with indies on different versions. One label, 292triage for example, can tie together disparate versioning conventions across MSGCNTR, LSNBLDR, BASICLTI, SAMIGO, etc. This should make it easier to do clean up on the fix version and help with queries for merging and testing (it did for me and the QA group in 2.9.1).
>> 
>> OR
>> 
>> 2) Add a Target version field in Jira, in addition to the affects version and fix version.  The advantage of a target version is that it will make it clearer which version an issue is intended to be included in (though extra translation may be needed to the overall release version) and it will also clear up confusion around the fix version, which many still use as a target version field.
>> 
>> If you don't like either of these ideas do you have alternatives that might address these issues? If you are not convinced there is a need, I wonder how I can convince you? Hypnotism? Psychedilics? <just kidding!> You are feeling very sleepy. Oh, wait, that's me after a large dinner. Nevermind.
>> 
>> Wondering if I should loop in QA and Dev groups. Folks in QA group definitely are with me on this issue, I would say.
>> 
>> Cheers,
>> Neal
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile