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

[Berg, Alan]

I agree with both Chucks and Steve's comments.

Further, I believe that the process should only be enacted 'if all else fails' and in a deterministic time frame. In my role, I also have a responsibility to support QA leads, they are volunteering time and energy and in return the product needs to be reasonably mallable to improvement, so that the leads can work most efficiently.

I am particularly concerned in the short term about getting patches for cross cutting concerns into trunk in a timely manner without disrupting the community approach. This mostly works, but there are negative examples.

Anthony rightly points out that a formal process can negatively move responsibility away from the community when we should be empowering that community (especially project leads). This is my attempt at expressing patching delays formally. Debate can only refine the concept and balance the contradictory needs.

I would like workfolw and reports added to/about Jira and then then later review the metrics with the TCC to find where the balance lies. Further, I volunteer to continue e-mail project leads over specific patches, but would welcome rules of thumb for when to bring issues to the attention of the TCC.

Alan



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: sakai2-tcc-bounces at collab.sakaiproject.org [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Steve Swinsburg [steve.swinsburg at gmail.com]
Sent: 24 November 2010 23:17
To: sakai2-tcc at collab.sakaiproject.org Committee
Subject: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release

I don't think Alan means that every patch will be committed after the two weeks lag. Of course, if the patch sucks or needs reworking, flick it back to the person who submitted it. The onus is on that person to produce quality patches that ideally merge cleanly.

Also, a level of review needs to be undertaken by the person reviewing the patch, not blindly committed, so ideally, steps to reproduce and steps to test the fix should be included.

But yes, this should only span current MT projects, not into other areas out of our purview. Especially if we are talking about currently maintained projects (portal, profile2, osp, etc) where the project lead or other developers should be the code mentors for those projects and ultimately decide what gets in. If its a good fix with no regressions, there should be no concern.

cheers,
Steve


On 25/11/2010, at 1:58 AM, Anthony Whyte wrote:

While sympathetic to the goals implicit in the escalation process I find it problematic both operationally and philosophically.  I do not support it in its current form.

1.  It assumes that MT members are capable of working in areas such as OSP that are not part of their current resume of experience.  This is not to suggest that MT members are not agile and capable of moving hither and thither about the code base but the basic assumption amounts to an assertion (or hope) rather than a fact.

2.  Not all patches are equal and not all patches are worthy of merging.  If a project lead thinks a patch sucks why does the debate need to escalate to the TCC?  All we are doing here is undermining the trust relationship that currently exists between senior developers on this project.  In hockey we call this crowding the puck.  If Chuck Severance or Matthew Buckett review a portal patch and say it ain't up to snuff then that should end the discussion and the patch submitter should revise and resubmit the patch.  If Steve Swinsburg or Daniel Robinson do not like a Profile2 patch and refuse to put a comment in Jira saying that it's fine to merge then we need to trust their judgement.

3.  The MT does not currently engage in branch management (BM) and it's members have hitherto balked at engaging in such activities (with exceptions of course).  So we have folks talking about an expansion of MT activities here without so much as a preliminary discussion among MT members themselves relative to the merits of the proposal.   Personally, I'd like to see MT members take on BM tasks (we have, for instance, no Community members serving at present as branch managers for 2.7.x) but it's for my MT colleagues to decide not others.

To me the escalations steps point at the wrong target: the project lead.  Indeed, we should not be talking about an "escalation" process at all, a suggested process that moves us a step towards "managing" volunteer contributors.

Cheers,

Anth




On Nov 24, 2010, at 8:54 AM, csev wrote:


On Nov 24, 2010, at 4:06 AM, Berg, Alan wrote:

1)      Wait two weeks for patch to merge
2)      Send email to project lead
3)      If patch is not merged by x then the MT review the patch and merge unless the project lead disagrees.
4)      If the project lead disagrees then the patch is escalated for debate to the TCC.

I think that this is a fine process particularly for things like internationalization that are non-controversial.  But lots of patches are pretty "patchy" and need a lot of rework before they are ready for prime time.

We do need to be careful - in portal patches are very common but it is quite often that the patch maker is content to build code that only works for their skin or for their local property settings.   And they properly write a JIRA and properly include a patch and know full well that their patch is not the ultimate solution but will be helpful in developing the ultimate solution.

We cant just have a timer expire and drop them into trunk - many need a lot of rewrite work so they work properly for all users of Sakai.

So as long as we don't get too stuck on "time expires - patch slammed in" and make it so the project lead can say "this needs a rewrite" and not be stomped on for saying so - then I am comfortable.

I would also like it if the human patch maker were the one pressing the issue forward rather than a mindless perl script that bulk-emails based on a DB pull from JIRA.  And the person submitting the patch should be able to make a decision as to whether in their mind this is a "perfect patch" and ready to go - or if this needs more work and the patch is a starting point.

Another dimension for this is where we are at in the release process.   During QA I tend to hold off on any optional non-bug stuff so I can use whatever time I have to respond to issues QA raises - non-QA patches that come in during that time are put on the back-burner until QA is done and it feels OK to open trunk back up for forward movement.  This also has the advantage that I can catch up a bunch of things and test the together.

All I am really saying is that it is not a simple thing.  And all that said - I like the process in general.

/Chuck

_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101125/1e15fb6e/attachment.html