[WG: Sakai QA] 2.6.1: in/out
Michael Korcuska
mkorcuska at sakaifoundation.org
Wed Sep 30 11:08:05 PDT 2009
No, its not hard once we know what we want. I'm not convinced we know
what we want.
Michael
On Sep 30, 2009, at 10:38, Anthony Whyte wrote:
> 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
>>
>>
>>
>>
>>
>>
>>
>
--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska at sakaifoundation.org
phone: +1 510-859-4247 (google voice)
skype: mkorcuska
More information about the sakai-qa
mailing list