[Building Sakai] JIRA Questions

Mon May 2 13:38:37 PDT 2011

> When I look at some JIRAs, it is apparent from the 2.7.x status field that they have been applied to 2.7.x (the 2.7.x status reads Resolved or Closed). Is this enough to tell me that it will appear in the 2.7.2 release? Even if the Fix Versions field does not indicate 2.7.2 (i.e., only indicates 2.8.0).

When a trunk commit has been merged to a particular maintenance branch the corresponding *.x dropdown is supposed to be set to resolved or closed (I choose closed).  However, these values are rarely if ever set programatically.  Rather they are typically set manually and are thus subject to the vagaries of the human imagination. 

In my release work I only trust what the svn logs reveal and approach each Jira ticket with a good-natured skepticism.  The Jira "Subversion Commits" tab is essential in helping to confirm the claims of any ticket although not always sufficient in helping determine if a trunk commit also intended for a particular maintenance branch has actually been committed to the target branch.  If unsure I review svn's "viewvc" (https://source.sakaiproject.org/viewsvn/) or check the svn logs from the terminal.  I also look at the code change itself in many cases.

> 1.       Is the only/best way to tell if a JIRA fix has made it into 2.7.x to inspect the code itself or am I missing something?

Yes,  you need to review what's actually been committed to an *.x branch.  All else is largely hearsay.  

In my merge work I provide a ticket comment that specifies the revision (-r) number generated by a commit to trunk and/or a maintenance branch (e.g., trunk r92000; 2.8.x r92001).  Other developers do the same.  It's a useful visual cue when reviewing the ticket but ultimately it's no substitute to confirming the commit yourself as well as reviewing the actual code change.

> 2.       If the fix appears to be in source.sakaiproject.org/svn/sakai/branches/sakai-2.7.x, what tells me it will make its way into 2.7.2? 

Tagging core projects using the Maven release plugin (i.e., Indies) involves performing the release from a stable maintenance branch at a given revision (e.g.  msgcntr-2.7.x -> msgcntr/tags/msgcntr-2.7.5 and binaries for the repo).  Jira tickets are reviewed prior to each release (e.g., svn branch commits are confirmed prior to the release, fix versions checked, etc.).  If your fix is merged to an indie maintenance branch after the previous release, it will be included in the next release, unless reverted.

Tagging core project releases that don't use the release plugin requires the creation of a "release" branch at a given revision in order to update the pom versions to the next release number (assignment/branches/sakai-2.8.x/ -> assignment/branches/sakai-2.7.2/ -> assignment/tags/sakai-2.7.2 and binaries for the repo).  This means creating a branch of the *.x branch at a known revision point in order to tweek the poms (e.g., 2.7-SNAPSHOT -> 2.7.2).  In such cases, a branch commit will be generally be included in the next release if it was committed (but not reverted):

a) AFTER the creation of the previous tag's "release" branch (e.g. assignment/branches/sakai-2.7.1)

and

b) BEFORE the creation of the next tag's "release" branch (e.g. assignment/branches/sakai-2.7.2)

This is the general rule for core projects that don't as yet utilize the release plugin; exceptions frequently occur however when late-breaking blocker fixes are merged to both the *.x and release branches prior to the final release.  

> For instance, do I need to reopen such JIRAs and directly indicate a fix version of 2.7.2? And if so, should I update the 2.7.x merge status from “none” to “merge” even though it already is present in 2.7.x?

If the ticket's fix version is set correctly to a prior release, say 2.7.1, then no, you do not update the fix version to 2.7.2.  If you find that a fix has been merged to 2.7.x but the branch status is incorrect do not set the merge status to "merge".  Set it to closed.  If in such cases the fix version is not listed you can usually set it correctly by checking version release dates in Jira.

example: https://jira.sakaiproject.org/browse/SAK#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

SAK-18845 Sakai 2.7.1 release branches created, 1 Aug 2010, r80495
SAK-19024 Sakai 2.7.1 tagged, 23 Aug 2010

Cheers,

Anth

On May 2, 2011, at 11:54 AM, Richwine, Brian L wrote:

> Hello,
>  
> I am working on finding Accessibility JIRAs from the 2.8.0 Accessibility Review to backport to 2.7.x, so they can appear in the 2.7.2 maintenance release and have a couple questions.
>  
> When I look at some JIRAs, it is apparent from the 2.7.x status field that they have been applied to 2.7.x (the 2.7.x status reads Resolved or Closed). Is this enough to tell me that it will appear in the 2.7.2 release? Even if the Fix Versions field does not indicate 2.7.2 (i.e., only indicates 2.8.0).
>  
> Also, some JIRAs (like https://jira.sakaiproject.org/browse/SAK-19886) do not indicate through the 2.7.x status field that they have been applied to 2.7.x and don’t list any 2.7 versions as a Fix Version – however when I look to see if the issue is still present in 2.7.x, I find that it appears as if the change already has been applied to 2.7.x. I’ve tried inspecting the subversion commits, to see if I can tell from that, but find my lack of knowledge about how the svn sources are organized and also used by the various maven projects is failing me (i.e. in SAK-19886’s case, the svn commit path was ‘/site-manage/trunk/site-manage-tool/tool/src/bundle/membership.properties’ and doesn’t tell me any version info, etc.).
>  
> I guess my questions really are:
> 1.       Is the only/best way to tell if a JIRA fix has made it into 2.7.x to inspect the code itself or am I missing something?
> 2.       If the fix appears to be in source.sakaiproject.org/svn/sakai/branches/sakai-2.7.x, what tells me it will make its way into 2.7.2? For instance, do I need to reopen such JIRAs and directly indicate a fix version of 2.7.2? And if so, should I update the 2.7.x merge status from “none” to “merge” even though it already is present in 2.7.x?
>  
> Thanks,
>   Brian
>  
> Brian Richwine
> Adaptive Technology Support Specialist
> Adaptive Technology and Accessibility Centers
> Indiana University - Bloomington/Indianapolis
> http://iuadapts.indiana.edu
> (812) 856-4112
>  
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110502/99dd785e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110502/99dd785e/attachment.bin 