Re: [babel-dev] Release strategy needed

[Denis Roy <denis.roy@xxxxxxxxxxx>]

Thanks for the comments, Antoine.

First off,
> I think we should add a field to the translations table to accept a translation. Language champions may review the translation and accept it.

I will start a different thread about this later.  We have discussed this at EclipseCon last year and during some of our team calls, so I'll reiterate some of those thoughts :)


As for the release process, I should not have included steps 0 and 5 in my text, below, as they put nonexistent tooling in the critical path of implementing a process that we need now.  Just to be clear, my thoughts are to implement a process ASAP, with the tools we have now, even if the process is not perfect.  My immediate goal is to implement a regular, predictable release schedule to offer stable language packs that people can download and expect to work.  Once that's implemented, we can work in additional tooling to improve the process.

I do agree that locking the server is bad, and leveraging the Language Champions is good, so here is my revised proposal that reflects what we have now:

1. We build a language pack from 'live'... Call this RC1.

2. We build/use a testing framework to ensure the language packs are *functional*... If any 'bugs' are fixed, we rebuild, and this becomes RC2
--> this is the only tooling we don't have right now, but need -- but the process can be implemented without it.
--> the purpose here is to check the translations for syntactic errors such as those from bug 250734
--> this syntax checking could actually be done when a translation is saved

3. We ask language champions (and the community at large) to review the language packs ... If any bad translations need correcting, they are fixed. 
--> For now, this would be an informal review / sign-off.  Just a 'yes, the German translations look good' approval for now
    3.1 If the 'bad' translations are deemed stop-ship, we start over from step 1, rebuild and call this RC3.  We try to avoid this, as this will introduce new translations from the community until Step 0 is implemented.

4. If RC2/RC3 passes, we "release" the fragments to our update site.  We then call the release R-something. 


Does this preliminary process make sense?

Denis



Antoine Toulme wrote:

On Wed, Oct 15, 2008 at 4:20 PM, Denis Roy <denis.roy@xxxxxxxxxxx> wrote:

Team,

I think the Babel project has reached a level of 'maturity' and popularity where we need to investigate a Release strategy.  While I'm not overly concerned with the Babel server code [1], nor the plugin code, I am concerned about building a weekly language pack that goes largely untested.  Furthermore, we need to have a plan, and formal releases, to satisfy our duties as Eclipse project citizens.

Please witness this bug, where a single 'bad' translation caused errors in Eclipse: https://bugs.eclipse.org/250734

Fortunately, a bad translation only affects one language (German, in the case above) but it is still the equivalent of a major/stop-ship bug in code.

I envision a consistent, predictable release cycle similar to this:

0. [FUTURE]: We implement a lock-down function on the Babel server, allowing only language champions to alter translations -- no new translations.  This is similar to a code/API freeze.
1. We build a language pack from 'live'... Call this RC1
2. We build/use a testing framework to ensure the language packs are *functional*... If any 'bugs' are fixed, we rebuild, and this becomes RC2
3. We ask language champions (and the community at large) to review the language packs ... If any bad translations need correcting, they are fixed. 
    3.1 If the 'bad' translations are deemed stop-ship, we start over from step 1, rebuild and call this RC3.  We try to avoid this, as this will introduce new translations from the community until Step 0 is implemented.
4. If RC2/RC3 passes, we "release" the fragments to our update site.  We then call the release R-something.
5. [FUTURE] We unfreeze the Babel server and allow community translations until our next lock-down.

If we can repeat this cycle every 3 months or so (2.5 months open translations, .5 month lockdown & release), this could give our NL Packs much more stability and quality, while giving our community a consistent, predictable release cycle.

Thoughts?  Comments?

Denis, we need to define our language champions then. Ideally people could vote them in ? It would be great to have an exhaustive list of them.

We need to give language champions weapons:

I proposed a page to help make translations uniform: https://bugs.eclipse.org/bugs/show_bug.cgi?id=248570

I think we should add a field to the translations table to accept a translation. Language champions may review the translation and accept it. During freeze periods, people can still translate, but it is not possible to accept those translations anymore. I'm afraid of freeze of contributions might shy away people otherwise.

 

[1] I think the Babel server code is great, but the primary purpose of our project is not to build a server tool.  I'm happy to continue an informal, releaseless, agile process for improving the code incrementally.

OK with that too. 

--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
denis.roy@xxxxxxxxxxx

Register now for Eclipse Summit Europe, Nov. 19-20

_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev

--
http://www.lunar-ocean.com/blog

_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
  

--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
denis.roy@xxxxxxxxxxx

Register now for Eclipse Summit Europe, Nov. 19-20