[sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges

Noah Botimer botimer at umich.edu
Fri Dec 3 10:39:16 PST 2010 

OK. I don't normally do this, but I have to take this one personally.

I find it extremely offensive that you claim that most tool leads do not care enough.

I understand and appreciate your needs in having software that runs in your language and your expertise in getting there. But I find it beyond discourteous and very unhelpful to accuse people of not caring.

The truth is that it IS difficult. The truth is that most of our lead developers are native English speakers only. The truth is that most are not completely up to speed on how to verify their internationalization efforts. The truth is that many of the issues are technically thorny and make it hard to move quickly. The truth is that internationalization and localization are skills, just like technical development, and not many of us are strong in both.

In fact, I read the whole "escalation process" thread as a threat as a project lead. To be specific, OSP has had an outstanding issue levied against it, SAK-19184 (and an earlier part, SAK-14401), for i18n. It has been marked as a blocker for 2.8.x. The fact is that the change forces lost functionality in favor of an edge case i18n scenario. The fix is just not ready and needs heavy duty development attention. To tell Beth, Chris, and me, after many hours of discussion and effort, that we're unresponsive and we should have a procedural way to patch it anyway is, frankly, obnoxious. (Idle, clean, tested patches are not at issue and are probably best handled with an email.)

I think it is unfair to place value judgments by way of policy on what is important to people in a volunteer community. You are obviously an advocate for internationalization and translation. Another might be an advocate for performance. Or security. Or teaching features.

Now, personalization aside, SAK-19184 is getting some work, David has been courteous in his offers to help, and it looks like we might have a nondisruptive fix upcoming. (For the record, it may be that not applying the patch was very prudent as it may unnecessarily change 100+ files while losing parameterized message functionality).

But that doesn't undo the general abuse of telling "all developers" that they don't care. Just as telling "all testers" that they are lazy because we have an outlined 2.8 schedule and they're not complying with it isn't easily undone. "You don't care enough" is a bad general message, even when accompanied by thanks or praise for bits and pieces.

Also, your closing sentiments are not lost on me. Your perspective is helpful on the TCC (not only) because you can be an advocate for i18n. I am genuinely pleased that you have confidence that there are resources available to help. But I have to appeal that we stop amending others' proposals with conditions based on what is important to us.

If these resources truly exist to help fix outstanding i18n issues, I implore you to speak in specifics to project leads. Reach out to them and ask if they understand what you need or if there are problems. Watch for enhancements as they are implemented in trunk and help ensure their complete internationalization and translation before they are merged. Help coach people on good behaviors with patches and conversation. These are things "we" (dev/project) can't do, precisely because we don't have "your" (i18n/QA) skills or needs.

Above all, please do not try to put additional preconditions on people's work on the basis that they don't care about your dearest concerns. It both stifles innovation and discourages the hard work that people and institutions contribute willingly.

Thanks,
-Noah

On Dec 3, 2010, at 12:32 PM, Jean-Francois Leveque wrote:

> Updating properties files is less difficult than including a patch for 
> testing and I'm sure people in Japan, Spain or France, to name a few 
> active communities in i18n, will gladly help with useful enhancements.
> 
> Translations are incomplete because properties files contain keys that 
> are not used anymore, i18n is done badly and, AFAICT, most tool leads 
> (or their employers) do not care enough.
> 
> If we're not trying things in at least two languages, this means we 
> don't care about i18n.
> 
> L10n is more than properties files editing. As far as tool leads are not 
> providing clean and clear enough i18n, you have to check which keys are 
> really used and how they're used before you can even try to translate. 
> Sometimes translation becomes impossible when i18n is bad and you have 
> to report an issue, often provide a fix yourself and too often beg for 
> this fix to be included. I'm currently reporting lots of unused keys, 
> but will have to report lots of misused keys soon. :(
> 
> I don't understand why we should hurry enhancements when i18n fixing is 
> still slowed down.
> 
> I advocate for improving i18n faster than we get new code with bad i18n 
> and get more tool leads and devs to really care for correct i18n. I may 
> be a dreamer, but know a few ready to work to make this dream come true. 
> Please join us.
> 
> Maybe my words are not so good in English but my intent with others is 
> to improve i18n/L10n things faster than ever before.
> 
> I agree with Seth about fixes first and enhancements later. Maybe we 
> should limit the number of enhancements that get in if there are too 
> many important fixes missing.
> 
> J-F
> 
> Beth Kirschner a écrit :
>> I'd agree with Anthony that requiring 3 institutions to test is pretty much disables the original intent of the proposal and Alan Berg's concern that "Sakai 2.x ... does not change functionally fast enough". 
>> 
>> Additionally, as many of you know, I do advocate for better internationalization, and I think the requirement to try out the change in at least 2 languages isn't necessarily effective. Translations continue to be incomplete due to the difficulty of  updating properties files, and testing in 2 languages may be impossible. Perhaps a better approach would be to (1) require that any change be properly internationzalized (as described by our best practices), and any change that requires new translation be part of the announcement to production that Anthony suggested.
>> 
>> In regards to John Bush's comment about this change "enabling" the trend of larger institutions moving slower, I can speak to UM's intentions and this will really not make any difference to our upgrade paths, but it will make our current patch & build process a lot simpler :-)
>> 
>> - Beth
>> 
>> On Dec 3, 2010, at 11:42 AM, Jean-Francois Leveque wrote:
>> 
>>> 1) Report "at-your-own-risk" enhancement to get others to try it with you and get a minimum of 3 total with at least 2 languages
>>> 2) After 30 days in production, you offer it to others who didn't want to take small risks
>>> 
>>> If only one or two want it enough to try it in production, why including it for all?
>>> 
>>> 30 days for enhancements is not long when fixes with patches provided and maintenance releases are waiting longer than that. :(
>>> 
>>> J-F
>>> 
>>> Anthony Whyte a écrit :
>>>> Consider a small enhancement targeted at 2.6.x.  If ANU run with it and Steve Swinsburg reports back in 30 (or x days) that the enhancement is safe then in my view the "in production" requirement is satisfied.
>>>> Attempting to organize three schools to test out what is being described in the proposal as small, low-risk changes is overkill and guaranteed to stretch out the process unnecessarily.
>>>> Anth
>>>> On Dec 3, 2010, at 11:15 AM, Jean-Francois Leveque wrote:
>>>>> I could remove the last one if Alan or a majority of the MT thinks it's not needed.
>>>>> 
>>>>> The first one is needed of i18n and I think the delay of one month is really small as far as maintenance branch releases are concerned. Furthermore, if less than three institutions are using a change, is it really needed for all?
>>>>> 
>>>>> By the way, I don't want lots of merges to be done on a maintenance branch if we're not tagging releases out of them for small institutions. Right now 2.6.3 and 2.7.1 are 3 months old. If we're not releasing 2.6.4 and 2.7.2 in December, I think it should be planned for January.
>>>>> 
>>>>> J-F
>>>>> 
>>>>> Anthony Whyte a écrit :
>>>>>> The addition of the following two requirements to the proposal effectively scuttles any chance that low risk, "small" enhancements will be added to maintenance branches in either a timely or efficient manner.
>>>>>> *The change has been running in production for one month minimum in at least three institutions including one using Sakai in another language than English
>>>>>> *The change only affects code that has full automated test coverage and includes full automated tests for its changes
>>>>>> Anth
>>>>>> On Dec 3, 2010, at 10:43 AM, Jean-Francois Leveque wrote:
>>>>>>> I've updated to make it more restrictive for obvious QA reasons.
>>>>>>> 
>>>>>>> Please, keep debate open until at least next Friday.
>>>>>>> 
>>>>>>> J-F
>>>>>>> 
>>>>>>> Beth Kirschner a écrit :
>>>>>>>> How's this: http://confluence.sakaiproject.org//x/bBFJB
>>>>>>>> 
>>>>>>>> Are we ready for a vote or are there more comments?
>>>>>>>> 
>>>>>>>> - Beth
>>>>>>>> 
>>>>>>>> On Dec 2, 2010, at 8:11 PM, May, Megan Marie wrote:
>>>>>>>> 
>>>>>>>>> Can someone volunteer to pull together this proposal on a Confluence page in the TCC space?   Megan
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Steve Swinsburg
>>>>>>>>> Sent: Thursday, December 02, 2010 6:34 PM
>>>>>>>>> To: csev
>>>>>>>>> Cc: sakai2-tcc at collab.sakaiproject.org Committee
>>>>>>>>> Subject: Re: [sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges
>>>>>>>>> 
>>>>>>>>> If there is stuff you want to see running in a production 2.6, send it our way (ANU). And within this TCC I'm sure there would also be other eager candidates to test on 2.7?
>>>>>>>>> 
>>>>>>>>> cheers,
>>>>>>>>> s
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 03/12/2010, at 3:55 AM, csev wrote:
>>>>>>>>> 
>>>>>>>>>> I like this notion in general - in particular the non-distruptive bit and the option to turn off.
>>>>>>>>>> 
>>>>>>>>>> I think a big issue will be how many versions back do we push something and who will QA those previous release branches.
>>>>>>>>>> 
>>>>>>>>>> I can see a great benefit to schools back a level or two to back-port something to the 2-6-x branch as it allows them to eliminate a local patch earlier in their process and makes moving to new versions easier.
>>>>>>>>>> 
>>>>>>>>>> However - I think that we need to have a school eager and ready to test and run something we are back porting.  So if some school is on 2.6 and there is a new feature that meets the criteria and wants it pulled back into 2-6-x - that school or those schools that want to run the patch should be willing to help in the testing of the 2-6-x branch after the code has been back ported.
>>>>>>>>>> 
>>>>>>>>>> I think that unless there is a strong advocate and resources to support for a back port of a feature we should leave the older branches alone - we need to be mindful that community resources for QA/release are not unlimited.
>>>>>>>>>> 
>>>>>>>>>> /Chuck
>>>>>>>>>> 
>>>>>>>>>> On Dec 2, 2010, at 8:50 AM, David Horwitz wrote:
>>>>>>>>>> 
>>>>>>>>>>> I would add:
>>>>>>>>>>> 
>>>>>>>>>>> 1) If behaviour changes it should be configurable and set to off (current behaviour) in the branch
>>>>>>>>>>> 
>>>>>>>>>>> D
>>>>>>>>>>> 
>>>>>>>>>>> On 12/02/2010 03:32 PM, Beth Kirschner wrote:
>>>>>>>>>>>> The line between a "bug" and and "enhancement" is sometimes blurry (especially if we broaden the definition of "bug" to include usability problems). Additionally there are often small enhancements, low in risk and high in impact that have to wait a full year for release to the community code base because of our policy of only merging bug-fixes into maintenance branches. Some institutions can mitigate these long waits by maintaining their own release branches (msub) and pulling in enhancements early. Not everyone has the resources to to this.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'd like to propose that we rationalize the process for merging small tasks & enhancements into a maintenance branch as follows:
>>>>>>>>>>>> 
>>>>>>>>>>>> Small enhancements and tasks may be merged into a maintenance branch if the following conditions are met:
>>>>>>>>>>>> 1) The change is narrow in scope (modest changes to a single project)
>>>>>>>>>>>> 2) The change does not require database changes
>>>>>>>>>>>> 3) The change is running in production at some institution
>>>>>>>>>>>> 
>>>>>>>>>>>> An example of a good candidate for this type of task is http://jira.sakaiproject.org/browse/SAK-11003, which is running in production at multiple institutions (merged to their institutions's msub branches), but which will not be available to the broader Sakai community until 2.8 is released.
>>>>>>>>>>>> 
>>>>>>>>>>>> This conversation feels familiar to me and it seems we may have discussed and agreed to this in the past, but wanted to bring up the topic with this group for a discussion and vote.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>> - Beth
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
>

More information about the sakai2-tcc mailing list