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

[DAVID ROLDAN MARTINEZ]

Hi all,

The "Trunk Ready" flag is very good idea!!!!. If this helps project leaders to make their life easier, I'm sure it will work.

However, this doesn't solve the other problem: project leader unresponsiveness. From my point of view, this only can be solved if three issues are good stated:

a) Strategic plan in relation of what are the markets the SF and Sakai are willing to reach. Not all cross cutting concers are equal. Having a well-defined strategy is key to prioritize. For example, if SF and community wants to spread Sakai around the world, this means that i18n is key and, thus, i18n patches should be absolutely considered before other patches. If i18n is secondary but accesibility is key, then accessibility patches should be expedited traffic.

b) Project leader status should not be static. If a project leader is unresponsive because he/she cannot invest time on its supposed role, then he/she should pass the batton to other member of the community or the community can suggest him/her to accept help from MT or other members of the community (probably, this last approach is less confrontational). Excuse if I use i18n as example, but it is what I know because it is what I deal every day. When I attach a patch that fixes an i18n bugs, I ask the tool/project leader to commit it. If he/she doesn't answer, I would like to have the power to make the commit on my own without hurts or missunderstanding as I have offered my help to the tool/project leader and he/she is unresponsive.

c) What happens if a tool has blockers bug in a cross cutting area? Will TCC make the tool out of the release? Probably a penalty mechanism must be defined but, to do this, first of all a) should be clear. Will you put in production a software that doesn't works at all in English? This is what happens with several i18n bugs. Take a look at this one: http://jira.sakaiproject.org/browse/SAK-3824. I cannot see the date in my language!!!! Imagine you can only work with Sakai in Chinese. Will you install Sakai at your institution? Do you know how many complaints we receive because of i18n issues? And the worst is that they are repeated release after release, independently of if there is a patch available or it isn't.

Returning to i18n once again, I've been offering myself and some Sakai Spanish Universities (S2U) resources not only to test i18n each release (which I happily do as a QA lead in this area) but also to fix issues. But in order to motivate my team I need to know that if they make the effort of fixing/testing bugs, they will be applied and they won't find the same errors release after release...

Cheers,
  David

________________________________________
De: csev [csev at umich.edu]
Enviado el: jueves, 25 de noviembre de 2010 16:02
Para: sakai2-tcc at collab.sakaiproject.org Committee
CC: DAVID ROLDAN MARTINEZ
Asunto: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during      a major release

I was thinking about this some more and came up with the following idea.  I think that one of the ideas this discussion is trying to get its hands around is quicker throughput for patches that are ready to go.   The proposed process feels like an "escalation process" which probably is not really necessary.

As a project lead myself, I would *love* to have a nice, simple place I could look for patches that are considered "trunk-ready" - this would be very useful for me - I would have a few hours of time and ready to clean up so low-hanging fruit - I would go and look for these easy wins and review and commit them.

So I propose the follows:  Add (yet another) drop down to JIRA similar to the "Which branch(es) to put this in" to allow anyone to create and/or edit a JIRA and indicate that in their opinion this JIRA and its patch is good quality and just needs to be put in trunk.  The drop down should be three-states - trunk-ready/not-trunk-ready/applied

I could make a filter in Basic LTI and Portal that I could pull these up easily and separate the low-hanging fruit from the harder stuff that will take more time.

And if I take a look and disagree, I simply edit the JIRA with a note as to how and why I think this is not trunk ready and we have a dialog right there in JIRA for all to see and nicely recorded in the right place.   Just like a branch merge - things might go back and forth a bit.

Or perhaps the initial committer did not indicate "trunk ready" and a QA sweep goes through and thinks it is trunk-ready, and indicates as such and thus begins the interaction.

I think this is cool as heck and would be really useful for me as a project lead.

I think that this discussion talks about a second problem that to me is very independent - the problem of unresponsive project leads.  Again, this is pretty independent - and this is why we have the MT - at some point if a lead sort of retires and becomes completely unresponsive, the TCC and MT can then step in.  The MT scope is as wide as it likes but it is natural for it to focus on the fallow parts of the code base.   I think that when anyone gets the feeling that there is no one home in some project, then we should have a discussion in the TCC and MT to get a handle on things and figure out the best way forward.

But these discussions are quite different than a discussion about a single patch not moving quickly enough - I think that the "Trunk Ready" flag is a great solution for that - a solution that makes thins easier, smoother, and less confrontational.

/Chuck