On Mon, Jun 30, 2008 at 6:13 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > On Fri, Jun 27, 2008 at 8:31 AM, Greg Smith <[EMAIL PROTECTED]> wrote: >> I posted a first pass Release Process Overview. > > We don't seem to have any process for translating textbooks and > content. There are teacher training materials in Spanish and Nepali > that we need in English, and a variety of other content in many > languages.
In general, I think this is the fundamental weakness of the first draft: it mentions that a "release" consists of core OS + "other stuff" but really only talks about dates & deadlines & names for the "core OS". I don't think the solution is expanding our scope so that OLPC is responsible for releasing every country's "other stuff" along with 8.2 at a single release date. I think the solution is to be more explicit about where the hand offs are, what the limits of our development/support are, and what processes are used to support local development. We should write into our release process when we gives bits to local translation, activity, and content teams, and when we need bits back from them, esp. for localization of "reference" activities and content (library-core, Write, Words) and for "reference" activities which are not maintained by OLPC (Tam Tam, Etoys, Squeak). There may be a separate "release" document that outlines the steps we will take to support a planned large-scale deployment, including basic QA of their "activities + core OS" image, converting it to an image suitable for Quanta and shepherding it through their QA process, QA of keyboards and manufacturing data on local SKUs, etc. This timetable is driven by the deployment, but we should set reasonable expectations for what steps are required, in what order, and how much time is needed for each. I'd also like to see quality expectations set, since the success and reputation of OLPC may depend on the success of these large-scale deployments. This is both technical (their release should work) and aesthetic (icons for local activities should conform to Sugar guidelines, the ordering should be logical, etc). For the bits of non-core OS "other stuff" we do, we should commit to a schedule. When is the first draft of the release notes available? Are the final versions of the reference activities synchronized with the core OS, or can/do they lag it by a week (or two, or three)? After how long does a release candidate become a release? What happens if there is a critical bug discovered in a "not maintained here" reference activity? Our biggest weakness to date is "not knowing when we're done" because the core OS is "good enough" but the other stuff isn't getting done. --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
