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

[DAVID ROLDAN MARTINEZ]

Please, forward my mails to sakai2-tcc, because my answers are being rejected...probably, I'm not in the list.

I'm absolutely agree with Anth pointings, but relating to the following

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.

I must add that when I'm talking about bugs, not feature request or so, and, in my particular case, of i18n bugs that makes Sakai tools not to work at all in a multilingual environment, from my point of view, patches are always worth to be applied. I know you know what I'm talking about because we discussed these subjects in detail during the last Spanish Sakai Conference at BCN. 

David

________________________________________
De: Anthony Whyte [arwhyte at umich.edu]
Enviado el: miércoles, 24 de noviembre de 2010 15:58
Para: csev; Alan Berg; DAVID ROLDAN MARTINEZ
CC: sakai2-tcc at collab.sakaiproject.org Committee
Asunto: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release

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