[WG: Sakai QA] 2.6.1: in/out
Michael Korcuska
mkorcuska at sakaifoundation.org
Wed Sep 30 08:09:23 PDT 2009
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
More information about the sakai-qa
mailing list