[sakai2-tcc] Cross cutting concerns and prompt patching during a major release

[Anthony Whyte]

I count 102 open "contributed patch" tickets but as Alan notes the number covers all recorded time and if examined from the perspective of what we need to do today the gross count is misleading.  Leaving aside for the moment those contributed patches that may be languishing under "bug" tickets, a quick analysis of the 102 contributed patch tickets shows that 50 tickets were filed against pre-2.6 code.  Some of those patches might still be useful but that remains to be demonstrated.

Second, open unapplied patches are not uniformly distributed across the code base but are clustered; 20 unapplied patches or nearly 20% of the open contributed patch tickets are filed against Samigo; worksite setup and Site info taken together total 16 while the kernel totals 8.

The Samigo team has reported on more than one occasion that their local resource base places constraints on the speed with which they can accommodate feature requests, patches, bug fixes etc.  Site Info and worksite setup are currently maintained by a single developer operating in heroic mode.  

A focus on people rather than process is what we need here to reduce the lags in the way we handle contributed patches .  If you want to reduce bottlenecks in patch processing it would do well to look first at how we as a development team can assist each other directly rather than to imagining that we can process our way out of these challenges.

Cheers,

Anth





AFFECTS VERSION (n=102)

2.8 = 3
2.7 = 8
2.6 = 41
2.5 = 20
Other = 30

BY PROJECT

SAK Project = 71

>= 3 open contributed patch tickets

Assignments = 3
Dropbox = 3
OSP = 4
Portal = 4
Realms/Admin Site Mgmt = 3
Resources = 3
Site Info = 8
Web services = 4
Worksite Setup = 8

Indies (tracked separately)

Basiclti = 0
Kernel = 8
Messages & Forums = 1
Polls = 0
Profile2 = 1
Reset Password = 1
Samigo = 20
Search = 0
Shortenedurl = 0
SiteStats = 0

project in (SAK, BLTI, KNL, MSGCNTR, POLL, PRFL, RES, SAM, SRCH, SHORTURL, STAT) AND issuetype = "Contributed Patch" AND status in (Open, "In Progress", Reopened) ORDER BY priority DESC, key DESC

project in (SAK, BLTI, KNL, MSGCNTR, POLL, PRFL, RES, SAM, SRCH, SHORTURL, STAT) AND issuetype = "Contributed Patch" AND status in (Open, "In Progress", Reopened) and affectedVersion in ("2.8.0", "2.8.0-a01", "2.8.0-a02", "2.8.0-a03", "2.8.0-a04", "2.8.x")

etc. . . 

project in (SAK, BLTI, KNL, MSGCNTR, POLL, PRFL, RES, SAM, SRCH, SHORTURL, STAT) AND issuetype = "Contributed Patch" AND status in (Open, "In Progress", Reopened) and affectedVersion in ("2.5.0", "2.5.1", "2.5.2", "2.5.3", "2.5.4", "2.5.5", "2.5.6", "2.5.x")

On Nov 25, 2010, at 12:36 PM, Berg, Alan wrote:

> Hi,
> 
> There are 99 contributed patches still open, so to use the contributed patch tag probably requires a review and placing in a known state these already open patches before indicative use.
> 
> 
> Alan
> 
> Alan Berg
> QA Director - The Sakai Foundation
> 
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
> 
> http://home.uva.nl/a.m.berg
> 
> ________________________________________
> From: azeckoski at gmail.com [azeckoski at gmail.com] on behalf of Aaron Zeckoski [aaronz at vt.edu]
> Sent: 25 November 2010 17:28
> To: csev
> Cc: sakai2-tcc at collab.sakaiproject.org Committee; Berg, Alan
> Subject: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release
> 
> There is always the contributed patch case type. Making a contributed
> patch case and linking it to the original would certainly flag things
> up (though it is a bit of a pain to have multiple tickets so I don't
> really love this as an option).
> -AZ
> 
> 
> On Thu, Nov 25, 2010 at 10:24 AM, csev <csev at umich.edu> wrote:
>> 
>> On Nov 25, 2010, at 10:44 AM, Anthony Whyte wrote:
>> 
>>> One relatively painless process tweek we could implement is to add a "Patch attached" checkbox to our tickets in Jira.  This would add a fourth checkbox to the Jira form but it would help simplify tracking the progress of tickets that include a submitted patch.  I am not suggesting this a solution to the problem of patch management but as a tweek that may help us better measure the extent of the problem.
>> 
>> I don't think a checkbox of "patch attached" is all that valuable.  I prefer my proposal that says "This JIRA is trunk-ready" - it communicates far more useful information to a project lead.  Just having a patch attached is zero indication that this is something that needs a little bit of immediate attention.
>> 
>> /Chuck
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 
> 
> 
> --
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
> 

-------------- 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/sakai2-tcc/attachments/20101125/986a70d8/attachment.bin