[cle-release-team] Indie Filters and JIRA Workflow

[Steve Swinsburg]

The projects without the merge flags need them added.

In addition, there are a number of indie projects not in this list, which are versioned separately to the SAK issues, but end up using the SAK version which doesn't make sense, for example Email Template Service, e.g.: https://jira.sakaiproject.org/browse/SAK-21739?focusedCommentId=158466&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-158466

There are more too, EntityBroker, edu services, web services are a few.

I think we need to perhaps decide on what really needs to be an indie and then rationalise this list and get Jira squared away. I don't think portal should be an indie, for example.

I just tried to run some cross project searches and it was too complex to pick multiple projects and then the particular versions of each, so as soon as the merge flags are set for each, then it can be much simpler, and we can create filters for each project:

project = PRFL AND status in (Resolved, Closed) AND "1.5.x Status" = Merge

cheers,
Steve



On 11/05/2012, at 5:44 AM, Thomas, Gregory J wrote:

> During the CLE meeting today, while having the core filters for the various states (Fixed/Needing QA, Verified/Needing merged, merged into 2.9 with a 2.9.0-bXX version) are great, we don't have any great filters for all the CLE indie projects to know what might be coming up in the next beta tag or new items that have been done for a given version.  I started looking into figuring out filters for these, but it became very difficult to do since jira workflows are different for each compared to SAK.
> 
> I think it's safe to say none of them follow the newer current guidelines (https://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines), specifically, the QA step in the middle, which is fine and by no means a requirement.  What would be nice is for all the projects to use the version status flags(None, Merge, Resolved, Closed, Won't Fix).  Some of them have them (not sure if the ones that do have them actually use it) and some projects don't.  I'm wondering if this is something worth pursuing for each indie project to start using regularly or if this might be a waste of time?
> 
> Either way, here's what I've currently figured out for the different projects based on the master pom.xml in the 2.9.x branch:
> KNL - does have a 1.3.x status flag and think it's being used
> BLTI - does not have a 2.0.0 status flag.  Not sure how exactly how to tell what's in that version for 2.9.x
> LSNBLDR - same as BLTI in not having a 1.4 flag
> MSND - does have a 1.6.x status flag, but not convinced it's being used
> MSGCNTR - has the sakai 2.7.x, 2.8.x, and 2.9.x status flags on the jiras, but it's indie version is actually 3.0 for 2.9.x.  I'm not really sure how to interpret this one
> POLL - does not have a 1.5 status flag
> PRFL - does have a 1.5.x status flag and think it's being used
> RES - does have a 2.9.x status flag and think it's being used
> SAM - does have a 2.9.x status flag and think it's being used
> SRCH - does have a 1.4.x status flag and think it's being used
> SHORTURL - does have a 1.4.x status flag, but not convinced it's being used
> STAT - does not have a 2.3.x status flag
> I think I covered them all.  If anyone knows some answers on how some of these projects are currently tracking their versioning, that'd be great.  I think anything to help track this stuff better will help as we continue to push out more beta tags for 2.9, as well as other future releases.
> 
> Thanks,
> Greg
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20120511/b3addd8c/attachment-0006.html