Translation refresh

[Charles Merriam]

Just so I can get it into the wiki correctly, the primary release
steps you mention:

1.  Check-in:  Making sure all the relevant changes are checked into
GIT on proper branches, and that the result is only completed
functionality that seems to work together.

2.  Testing:  Building it, getting different people to run smoke
tests, running some (t.b.d.) more formal QA, iterating as tickets are
filed and closed.

3.  Sign the build:  in a dark room with secret commands, the build is signed.

4.  Transfer the build image to manufacturing, make sure they pick it
up, make sure it gets into the production queue for new units.


Am I missing anything?

Charles Merriam

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
> >
>
>
> _______________________________________________
>  Devel mailing list
>  Devel at lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>
>