[WG: Sakai QA] 2.6.1: in/out
Anthony Whyte
arwhyte at umich.edu
Wed Sep 30 10:38:40 PDT 2009
The August thread to which MK refers can be read here:
http://n2.nabble.com/WG-Sakai-QA-Jira-process-clarification-and-modification-Target-Version-tt3484193.html#a3484193
Is revising Sakai Jira workflows all that hard? Across the pond the
3.x team has a reworked set of workflows that can serve as a model and
then there is Megan and IU.
For myself, I don't even need to see a target version so long as we
stop using maintenance branches as a fix version. But now I am
drifting in to implementation details.
Anth
On Sep 30, 2009, at 11:09 AM, Michael Korcuska wrote:
> The QA list is included here Seth, so it is public. Perhaps it
> should go to sakai-dev at some point too, but doesn't seem necessary
> at this stage.
>
> As to your other point, I'm wondering the same thing. I made the
> following suggestion in August, basically that we figure out our
> workflow "on paper" before changing Jira:
>
>> I think this is a good discussion. I think we need to take a bit
>> more time and that some confusion is resulting from the fact that
>> we don't have a common understanding of what the work flow is (or
>> should be). So I recommend starting with a plain English (no
>> reference to Jira) description of what should be happening. Once we
>> agree on that then we can figure out how to wrestle jira into
>> helping us reflect that as simply as possible. It would also serve
>> as good documentation for newcomers.
>>
>> For bug something like:
>>
>> Someone identifies issue and the version(s) of the software it
>> affects
>> Others verify the issue exists and examine whether it affects other
>> releases/trunk
>> Some developer takes responsibility for the issue and lets everyone
>> know it is being worked on
>> Developer describes fix on list and asks for approval to commit
>> (possibly optional)
>> Developer submits a fix to the relevant branch and asks for testing
>> QA tests the issue and either sends it back for more work or
>> confirms it is fixed
>> Branch managers apply fix to their branches, resolving merge
>> conflicts along the way
>> Fix is verified in the relevant branches
>>
>> I know this probably isn't exactly right, but I hope you get the
>> idea. There are other complexities like "I was working on this but
>> now I'm not" that might be relevant.
>>
>> The crux of the matter, I think, happens after a fix is created for
>> a particular branch, say trunk. In some sense, from the developers
>> perspective, that closes the issue. But there may still be work to
>> apply that issue to multiple branches. And so a single bug turns
>> into multiple issues to track from a QA and release perspective.
>> The branch managers and release team want to be able to figure out
>> not only if a bug was fixed but whether that fix was applied to
>> their branch.
>
>
> On Sep 30, 2009, at 07:36, Seth Theriault wrote:
>
>> Hello,
>>
>> What you see below is a current thread that needs to go public.
>> It started out as a status update request, but has lot of useful
>> information about the proposed forthcoming 2.6.1 release.
>>
>> To Pete's response below, I thought a small group was
>> discussing/forming recommendations for changes to improve our use
>> of Jira. This was discussed in Boston. Has anything bee put into
>> writing?
>>
>> Seth
>>
>> Pete Peterson wrote:
>>
>>> I agree with most of this, but I think the "Fix Version",
>>> should represent the "Fixed Version". In other words I think it
>>> should be limited to only released versions. If this field is
>>> used as a place holder for tentative releases, then we have the
>>> potential for possibly excluding these fixes. For example a fix
>>> is marked "Fix Version 2.6.2", but doesn't get merged into the
>>> branch in time. We then need to go and manually find these
>>> stragglers and change them all to 2.6.3. It makes much more
>>> sense to me to have this field blank until it the issue is
>>> released in a version. I don't think it should be used as a
>>> target version field.
>>>
>>> Thoughts?
>>>
>>> Pete
>>>
>>> From: Anthony Whyte [mailto:arwhyte at umich.edu]
>>> Sent: Tuesday, September 29, 2009 5:27 PM
>>> To: Noah Botimer; Kirschner Beth; Qian Zhen; Jones Matthew; Jean-
>>> Francois Leveque; May Megan; Li Lydia; Karen Tsao
>>> Cc: Theriault Seth; Horwitz David; Pete Peterson; sakai-foundation-
>>> staff sakai-foundation-staff
>>> Subject: 2.6.1: in/out
>>>
>>> Please take a moment to review the closed issues that Jira tells
>>> me are ready for merging to 2.6.x with an eye on what you deem is
>>> essential to include in 2.6.1. There is a healthy set of
>>> assignment fixes to review, another set of French translations, a
>>> chunk of gradebook fixes and other stuff. There may well be other
>>> needed fixes that the 2.6 filters aren't picking up -- is so
>>> please update Jira.
>>>
>>> 2.6.x merge candidates
>>> http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12075
>>>
>>> 2.6 resolved issues (critical)
>>> http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12101
>>>
>>> Also I want to propose that we cease using any maintenance branch
>>> for a fix version and instead select actual and tentative versions
>>> (plus trunk) only. I reviewed and fixed hundreds of Jiras today
>>> by comparing svn commits against fix versions in order to try and
>>> achieve an accurate 2.6.1 list of fixes. In my view, 2.6.x as an
>>> affects version is ok but we should limit the fix version to
>>> actual versions, whether released or not (look ahead fix versions
>>> are good).
>>>
>>> So if you merge an issue to 2.6.x before we release 2.6.1, set the
>>> fix version to 2.6.1 and get rid of any fix version reference to
>>> 2.6.x. Unless, of course, you disagree. If you do let's talk
>>> about this now because I want to send an email out on tomorrow on
>>> this aspect of Sakai Jira practice.
>>>
>>> By the way, I am not suggesting you merge anything more into
>>> 2.6.x; but if something is outside of 2.6.x that needs to be in so
>>> that it gets picked up by 2.6.1 please merge it (and or discuss it
>>> on list).
>>>
>>> Cheers,
>>>
>>> Anth
>>>
>>>
>>> Begin forwarded message:
>>>
>>>
>>> From: Anthony Whyte <arwhyte at umich.edu<mailto:arwhyte at umich.edu>>lyd
>>> Date: September 29, 2009 7:44:21 PM EDT
>>> To: Sakai QA <sakai-qa at collab.sakaiproject.org<mailto:sakai-qa at collab.sakaiproject.org
>>> >>
>>> Cc: "sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org
>>> > Developers" <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org
>>> >>
>>> Subject: 2.6.1 update
>>>
>>> I spent a good deal of time today cleaning up Jira in order to
>>> provide an overview of the upcoming 2.6.1 release. I've cleared
>>> away a large number of issues (200+) not properly associated with
>>> the 2.6.0 release which have made it difficult to track post-2.6.0
>>> fixes destined for 2.6.1. My view of the issues as of tonight is
>>> listed below:
>>>
>>> Jira highlights (current)
>>>
>>> 2.6.1 fixes = 100
>>> 2.6.x/2.6.1 merge candidates = 58
>>> 2.6.1 blockers = true
>>> 2.6.1 conversion scripts required = true
>>>
>>> 2.6.1 is heavy on I18n (internationalization) updates and fixes to
>>> assignments and portfolios. Further details respecting the
>>> release can be gleaned from the reference section below.
>>>
>>>
>>> REVIEW 2.6 ISSUES
>>>
>>> Project teams should review issues lodged against their 2.6 code.
>>> If fixes you deem are essential for the health and well-being of
>>> 2.6.1 have yet to be merged to the 2.6.x maintenance branch,
>>> please alert the release/branch management team (listed in
>>> Confluence).
>>>
>>> http://confluence.sakaiproject.org/display/REL/Release+Management+Team
>>>
>>>
>>> RELEASE WEEK
>>>
>>> My plan is to create a 2.6.0 release branch (a copy of 2.6.x) no
>>> later than Friday, 2 October 2009 in order to perform pom tweeks
>>> and generate artifacts for a release during the week of 4-9
>>> October 2009.
>>>
>>> Unlike previous "rationed" maintenance releases that mapped to a
>>> variable set of maintenance branch project revisions, 2.6.1 will
>>> take the entire maintenance branch at a known point in its
>>> revision history. The release will then be cut from this parallel
>>> branch within a few days of branching in order to limit the
>>> artifact "staleness" that characterizes current Sakai maintenance
>>> releases when compared to their parent *.x branch.
>>>
>>> In order to hit these dates the following issues must be resolved:
>>>
>>> 1. elimination of blockers and regressions
>>> 2. creation of 2.6.0->2.6.1 conversion scripts
>>> 3. final resolution of 2.6.x/2.6.1 merge candidates. Those
>>> deemed essential for this release by the branch management team
>>> get merged, the rest get bumped to 2.6.2 and beyond.
>>>
>>> Once the above conditions are satisfied the following will occur:
>>>
>>> 1. release branch is created based on the chosen *.x branch
>>> revision; branch poms are tweeked as necessary
>>> 2. release branch is deployed to QA servers for final QA review
>>> 3. release artifacts are generated, 2.6 release notes are updated
>>> and code is publicly released (ideally within 3-4 business days of
>>> initial branching in order to limit artifact staleness)
>>> 4. we start work on 2.6.2 for a mid-November release.
>>>
>>> cheers,
>>>
>>> Anthony
>>>
>>> _________________________________
>>>
>>> REFERENCES
>>>
>>> 2.6.1 FIXES (MERGED TO 2.6.x)
>>>
>>> 2.6.1 fixes (n=100) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12092
>>>
>>> The Jira 2.6.1 version filter (http://jira.sakaiproject.org/browse/SAK/fixforversion/11484
>>> ) inflates the number of issues currently merged to 2.6.x and
>>> destined for 2.6.1 as it filters on version and resolution (fixed)
>>> but see also:
>>> 2.6.1 issues n=127 (this number includes closed as well as
>>> resolved fixes that have yet to be merged to 2.6.x branch) http://jira.sakaiproject.org/browse/SAK/fixforversion/11484
>>> ; see merge candidates below.
>>> 2.6.1 issues (unresolved) n=20 http://jira.sakaiproject.org/secure/BrowseVersion.jspa?id=10010&versionId=11484&showOpenIssuesOnly=true
>>>
>>>
>>> 2.6 MERGE CANDIDATES
>>>
>>> These issues are fixed, closed and ready for merging to 2.6.x.
>>> Branch managers should review these issues as to whether or not
>>> they should be included in 2.6.1 or bumped to 2.6.2.
>>>
>>> 2.6 merge candidates (n=58) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12075
>>>
>>>
>>> 2.6 RESOLVED (AWAITING TESTING VERIFICATION)
>>>
>>> Unless a compelling reason is advanced to include any of these
>>> resolved issues in 2.6.1, these fixes that are awaiting testing
>>> verification will be bumped to a future maintenance release.
>>>
>>> 2.6 resolved blockers (n=0) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12102
>>> 2.6 resolved critical (n=14) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12101
>>> 2.6 resolved other (n=176) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12100
>>>
>>>
>>> 2.6 OPEN (UNRESOLVED)
>>>
>>> Open unresolved issues will be bumped to 2.6.2 and beyond unless
>>> there is a compelling reason to escalate an open 2.6 issue to
>>> blocker status.
>>>
>>> 2.6 open blockers http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12086
>>>
>>> * A number of issues currently block me from releasing 2.6.1.
>>> However, I recommend that only SAK-17057 be considered a 2.6.1
>>> blocker. The others, all unassigned, should be bumped to 2.6.2.
>>> If you disagree with this assessment please email me with reasons.
>>>
>>> http://jira.sakaiproject.org/browse/SAK-17057
>>>
>>> 2.6 open critical (n=69) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12087
>>> 2.6 open other (n=933) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12060
>>>
>>>
>>> KNOWN CONVERSION SCRIPT ISSUES
>>>
>>> http://jira.sakaiproject.org/browse/SAK-16809
>>> http://jira.sakaiproject.org/browse/SAK-16548
>>> http://jira.sakaiproject.org/browse/SAK-16847
>>>
>>>
>>> KNOWN PROPERTIES ISSUES (changes, additions, missed)
>>>
>>> asn.share.drafts http://jira.sakaiproject.org/browse/SAK-16753
>>>
>>>
>>> RELEASE NOTES ADDITIONS
>>>
>>> Update documetation re: time outwarning properties per
>>> http://www.nabble.com/-Building-Sakai--Time-out-warning-td25599130.html
>>>
>>>
>>>
>>> Begin forwarded message:
>>>
>>>
>>> From: Anthony Whyte <arwhyte at umich.edu<mailto:arwhyte at umich.edu>>
>>> Date: September 14, 2009 1:54:59 PM EDT
>>> To: Developers Sakai <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org
>>> >>, Sakai QA <sakai-qa at collab.sakaiproject.org<mailto:sakai-qa at collab.sakaiproject.org
>>> >>
>>> Subject: Sakai 2.6.1 maintenance release recommendations
>>>
>>> The 2.6.x maintenance branch is overripe for a maintenance
>>> release: the merge delta between 2.6.0 and 2.6.x now stands
>>> around 260, roughly half the 2.6.x merges involve fixes to code
>>> while the remainder involve updates to internationalization
>>> property bundles. In particular, 2.6.x assignment, chat,
>>> portfolio and site-manage have witnessed a good deal of merge
>>> (e.g., bug fixing) activity. In addition, new updates for
>>> Catalan, French, Russian, Spanish and Swedish translations have
>>> been added.
>>>
>>> Sitting outside the 2.6.x branch are an additional 120 fixed
>>> issues with an affects version of 2.6.* that should be reviewed
>>> for potential inclusion in 2.6.1:
>>>
>>> 1. 45 fixed issues that are closed with a request to merge to
>>> 2.6.x. Assuming these are tested, this set should be reviewed by
>>> RM/QA/project teams for inclusion in 2.6.1, and if appropriate,
>>> merged.
>>> 2. 75 fixed and resolved issues with a request to merge to 2.6.x.
>>> These require testing verification before merging can take
>>> place. They too should be reviewed for inclusion in 2.6.1 or
>>> pushed to 2.6.2.
>>>
>>> I recommend we cut the 2.6.1 release on Monday, 28 Sept 2009 with
>>> a followup 2.6.2 release to occur sometime before Thanksgiving.
>>> Sometime between 16-18 September I would create a 2.6.1 release
>>> branch based on a known revision of 2.6.x (rXXXXX). Unlike
>>> previous "rationed" maintenance releases that mapped to a variable
>>> set of maintenance branch project revisions, 2.6.1 and future
>>> maintenance releases will take the entire maintenance branch at a
>>> known point in its revision history. The release will then be cut
>>> from this parallel branch within a few days of branching in order
>>> to limit the artifact "staleness" that characterizes current Sakai
>>> maintenance releases when compared to their parent *.x branch.
>>>
>>> No freezing of the 2.6.x maintenance branch will be required. No
>>> alpha, beta, or rc tags will be generated prior to the release.
>>> Instead, a new sakai-2.6.x-qa branch (https://source.sakaiproject.org/svn/sakai/branches/sakai-2.6.x-qa/
>>> ) has been created to facilitate pre-release testing. This branch
>>> is updated periodically (e.g., weekly) based on a known 2.6.x
>>> revision. The branch can then be checked out and deployed to a
>>> set of *.x branch QA servers, permitting QA to test changes to the
>>> branch on a near continuous basis. QA testing of the "parallel"
>>> release branch would be discretionary and likely limited to those
>>> tools/services that have seen a good deal of merge activity (e.g.,
>>> assignments, site-manage) as well as ensuring that required
>>> conversion scripts are in order.
>>>
>>> In effect, I propose the following steps when the Sakai Community
>>> determines a maintenance branch is ripe for a maintenance release:
>>>
>>> 1. Release/Branch Management/QA teams with input from project
>>> teams choose an *.x branch revision point that contains no
>>> blockers, agreed-upon kernel (K1) and other project bindings and a
>>> revised set of conversion scripts (if the latter are required)
>>> 2. release branch is created based on the chosen *.x branch
>>> revision; branch poms are tweeked as necessary
>>> 3. release branch is deployed to QA servers for final QA review
>>> 4. release artifacts are generated, release notes are completed,
>>> the release page is updated and code is publicly released (ideally
>>> within 3-4 business days of initial branching in order to limit
>>> artifact staleness)
>>>
>>> Other than QA staffing challenges, I see no impediments to cutting
>>> maintenance releases both more frequently and without the long
>>> delays we currently experience since *.x branch merges are (in
>>> theory) tested and verified (a merge pre-req) and because the *.x
>>> branch production branch strategy adopted successfully by a number
>>> of Sakai schools suggests that we should be able to operate close
>>> to the head of the maintenance branch without undue risk to the
>>> health of our release artifacts.
>>>
>>> Arguably, 2.6.1 is already a bit bloated from a fix inclusion
>>> standpoint. We should aim for smaller, more frequent maintenance
>>> releases. But if we can put out 2.6.1 in the next couple of weeks
>>> followed by 2.6.2 before the year is out (a Sakai 2.5.6 release is
>>> also worth exploring) we should be able to position ourselves for
>>> a release early, release often strategy for 2010.
>>>
>>> Whatever we do we should endeavor to reduce the delays that impede
>>> our maintenance releases in order to help reduce the number of
>>> patches that deployers are currently forced to implement when
>>> working with our often stale artifacts.
>>>
>>> Let me know what you think of these recommendations.
>>>
>>> Anthony
>>>
>>>
>>>
>> _______________________________________________
>> sakai-qa mailing list
>> sakai-qa at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>>
>> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska at sakaifoundation.org
> phone: +1 510-859-4247 (google voice)
> skype: mkorcuska
>
>
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090930/ac0fdb83/attachment-0001.bin
More information about the sakai-qa
mailing list