Translation refresh

[Kim Quirk]

Bernie,
I'd like to make two points regarding your notes:

1 - OLPC cannot be responsible for activities. So it is really much better
that the activities are now separate from the base code to help get this
point across to the country. As a 'sales' type person, you need to convey
that activities are built, tested, translated by the community. OLPC will
not be qualifying or certifying them. The country needs to reserve time and
resources in its own schedule to help ensure testing and translation of the
activities that they want. And they can do this, because the activities are
not tied to our release schedule. If we can separate translations in a
similar fashion that seems like a good way to go.

2 - Rolling a build takes a week, not 10 minutes. A build that is ready for
release to the public, contains many steps: From check-ins, to packaging, to
build creation, to testing, to the signing of the build, to getting a build
properly into manufacturing... there are many steps and each step has many
points of failure. Some of these we can eliminate over time through
automation... but we aren't there yet.

Kim



On Sun, Apr 20, 2008 at 3:24 PM, Bernie Innocenti <bernie at codewiz.org>
wrote:

> On Sun, 2008-04-20 at 18:54 +0530, Sayamindu Dasgupta wrote:
>
> > I don't think it makes sense to make seperate releases _only_ for
> > translations.
>
> Why does rolling a release seem to be such a big thing?
> Generating a new OS image takes 10 minutes of machine time
> and this is as simple as it can get.
>
> All the other steps our release procedures that create overhead
> assume some amount of testing is necessary before a new OS hits
> users.
>
> But if the only thing you change is translations, it doesn't
> matter whether you're doing it with a new OS image or through a
> separate language pack.  The resulting system will in both cases
> be the old one plus these new strings.  And this is what you
> have to retest in both cases.
>
> What we need is a fastpath in our procedures for this case.
> I think we had something adequate for security updates.  Michael?
>
> <sidenote>
> Our friends here told me that we must urgently translate the word
> "Pippy" because apparently it has a very inappropriate meaning in
> Turkish :-)
> </sidenote>
>
> >  I am currently working on a language-pack builder for
> > deployers and testers, which would  generate language packs for
> > different releases (eg: Update-1, or Joyride), etc. This should
> > separate the release process substantially from the translations, and
> > deployers can add enhanced language packs for the deployed systems as
> > the translations evolve.
>
> This would add yet another degree of implicit dependencies to our
> system.
>
> The way I see it is that we already have a very dangerous situation
> where Sugar and the activities can freely vary with respect to each
> other with no robust dependency tracking.  If we also add translations
> to the equation, we're making it much worse.
>
> Then you get bug reports such as "I don't get a string translated to
> Turkish", you'd have to ask the user:
>
>  - what OS release?
>  - what activity version?
>  - what language pack?
>
> Unless we plan to switch to a true package manager, we can't modularize
> things too much.
>
>
> > However, to make this work we also need to follow some kind of
> > branching policy wrt the releases (eg: once Update-1 is released,
> > bugfixes targetted for subsequent minor releases f'd uor Update-1 should
> > be committed to the Update-1 branch only, while development for
> > Update-2 should continue in the devel branch). This has to be done for
> > _all_ activities (and of course, the components of Sugar as well).
>
> Yes, this is what is being done already for Sugar and many other
> packages hosted on dev.laptop.org (although there's no policy that
> mandates it).
>
> --
>  \___/
>  |___|  Bernie Innocenti - http://www.codewiz.org/
>   \___\ CTO OLPC Europe  - http://www.laptop.org/
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080420/bee4eebd/attachment.html>