Release Process/lang-es

Traducción de Release_Process	original
english | español   +/-	cambios

Ahora, edita tu traducción, usando lo siguiente como guía: [[Original page]] [[Original page/lang-es]] (nombre de la página traducida) Borrando el texto traducido... (no muy recomendado) {{OLPC}} {{Translations}} == Some header == Some text blah... blah... [[#Another header]] ... blah == Another header == Some other text blah... blah... [[Another page]] and [[Another page#section|section]] ... blah {{OLPC}} {{Translation | lang = xx | source = Original page | version = yyyy}} {{Ongoing Translation}} {{anchor|Some header}} == Un titular == Algo de texto bla... bla... [[#Another header|Otro titular]] ... blah {{ Translated text | Some text blah... blah... [[#Another header]] ... blah | display = block}} {{anchor|Another header}} == Otro titular == Algo más de texto bla... bla... [[Another page/lang-xx|Otra página]] y [[Another page/lang-xx#section|sección]] ... bla {{ Translated text | Some other text blah... blah... [[Another page]] and [[Another page#section|section]] ... blah | display = block}} {{OLPC}} {{Translation | lang = xx | source = Original page | version = yyyy}} {{anchor|Some header}} == Un titular == Algo de texto bla... bla... [[#Another header|Otro titular]] ... blah {{anchor|Another header}} == Otro titular == Algo más de texto bla... bla... [[Another page/lang-xx|Otra página]] y [[Another page/lang-xx#section|sección]] ... bla Páginas de soporte: si hay un enlace rojo como el siguiente: [[Original page/translations]] [[Original page|english]] [[Original page/lang-es|Página original]] ... debes seguirlo y pegar "{{subst:requesttranslation}}" allí: [[Another page/lang-es]] [[Another page]] {{subst:requesttranslation}} Eso se sustituye con el template: ''{{Translation|lang=es|source=Another page|status=deseada}} some untranslated page... maybe the content is mutating rapidly, or is peripheric to the main corpus, etc.

  Para desarroladores

english | español

HowTo [ID# 257225]  +/-

  Esta página está supervisada por el equipo de OLPC.

Traducción de Original page	original
+/-	cambios

This is an on-going translation

This page describes OLPC's software release process.

Metas

The goals of the release process process are to:

1. Ensure high quality releases which meet the needs of users in a timely fashion.
2. Maximize the participation, productivity and enthusiasm of the open source community.
3. Create a predictable process which helps users and developers plan for the future.

El resultado

The output of this process is a generic software image suitable for installation on OLPC's XO laptop platform. The image is generic in the sense that it includes a rounded selection of activities, applications, and languages.

We do not expect established deployments to use this software image directly. Almost all deployments have needs or desires to customise the software image that they ship (e.g. with new languages, a different selection of activities, specific default settings, etc.). We expect that most established deployments will use the Build system to produce a variant of the release including their own customizations.

Nevertheless, the process of developing and stabilising the generic release is key, as it forms the base of all the deployment-customized software releases.

El proceso

Each release is planned in advance, and this process results in a slightly different development/release methodology for each release. However, certain guidelines and well-established principles are stuck to:

• The release planning documentation is made public from the start.
• Release development is divided into individual stages, separated by milestones (discussed below)
• Releases are coordinated according to a schedule of milestones, which is decided early on, and included in the release plan.
  • This is important so that our customers know when to expect the final release, when they should get involved with development and testing, and to allow them to plan their upgrade/rollout.
  • This is also a well-established practice in our neighbouring open source communities
• The release schedule is honored strictly. That is, the milestone dates are adhered to, even if some sacrifices (such as exclusion of planned features which didn't arrive in time) are made. Some flexibility can be allowed for, but these should be exceptional cases only.

The development process is divided into distinct stages, with milestones to mark the progression from each one to another. Each of the items below links to an extensive explanation (including technical and managerial procedures) of each stage, be sure to read them all if you want to become involved in the release process.

1. Release Process/Planning
2. Release Process/Development
3. Release Process/Stabilization
4. Release Process/Release

Major and minor releases

Major releases include large platform changes (such as updating to the latest versions of Fedora & Linux) and addition of new features.

Minor releases (a.k.a. point releases) are limited to the fixing of bugs which are affecting deployments, and occasionally include translation and locale updates (requested by deployments).

This was previously adhered to quite strictly, but the recent minor releases in the 10.1 series have seriously blurred the lines between major and minor releases. This degrade of practice started when OLPC's development resources were downsized, meaning that there were no resources in sight to allow for a future major release, resulting in the relaxing of criteria on what could go into the minor release. However, now that OLPC's software team has grown a bit again, it is my hope that this previous practice can be restored, so I've documented it that way. Time will tell... -DanielDrake 17:22, 9 February 2011 (UTC)

Mejoras

New major releases will include a set of new features, pioneered and developed by OLPC staff and community members. A feature is defined as a significant change or enhancement to the current version of XO software that may or may not include new packages. Our feature process should be driven by the needs and feedback of our customers (deployments) and our users (young children).

Features are usually considered to meet one or more of the following objectives:

1. Highly user visible changes
2. Improvements or changes that require non-trivial cross-package integration
3. Noteworthy enough to call out in the release notes
4. Exciting new capabilities we can trumpet.

Some examples might include:

• New educational tools that will be used by children
• New features from upstream that we are making available on the XO for the first time
• Improvements to tools and infrastructure used by activity developers

OLPC plans which features to develop for each release according to its key principles and based on feedback from customers. During planning stages, a discussion will usually be started on the devel mailing list in order to solicit input from the community, and to clearly communicate that the feature planning process is underway.

Features can also enter releases through upstream projects. For example, a new feature added to GNOME will automatically enter an OLPC release once a release is made including that specific GNOME version. Some of these features may have direct impact on OLPC and are good candidates to be discussed in the release notes.

Features outside of OLPC's feature plan are also welcome to be contributed by interested individuals and deployments, providing that they meet the normal code acceptance criteria (open source, good code quality, good documentation, appointed maintainer, ...), and provided that they are accepted and included within the acceptable stages of the release schedule. In many cases, development of such features does not belong at the OLPC level, but rather in the upstream projects (for example, development of a new Sugar feature would fall entirely within the SugarLabs community, and would not need acceptance or review by OLPC).

Mantenimiento y sostenibilidad

OLPC has historically made quite a few changes to standard open source software technologies (Linux, Fedora, etc) and this hurts us in every release cycle. We are now a small team and every release cycle we spend a lot of time bringing forward the the collection of OLPC-local changes.

In recent times, this "delta" from upstream software has been greatly reduced. We need to keep working in that direction, which means strict controls on any new non-upstream changes being added. The most effective way to approach this is to get your changes upstream first.

Nombre de lanzamientos

The release names are of the form "Y.H.NN"

• Y = target calendar year
• H = major release number representing first release or second release of the calendar year
• NN represents the Minor Release, starting with .0 at the availability of the first Major Release and going up by 1 for each publicly available minor release after that.

A Major Release and all its derivative Minor Releases can be referred to with a variable (or wildcard) in the third digit (e.g. 8.2.x refers to 8.2.0, 8.2.1 and 8.2.3).

Examples:

• 8.1.1: First Minor Release rebuild based on the first Major Release in 2008
• 8.2.0: Second Major Release in 2008

Idiomas soportados

In the interest of keeping the image size down, OLPC only ships certain locales/translations in its released builds. New locales can be requested by writing to the devel mailing list. The only criteria that must be met is that there is an active or soon-upcoming deployment (of any size) that will use this language.

On one hand, the selection of locales included in OLPC's official builds is somewhat irrelevant, because we expect all significant deployments to use the build system to produce a customized version of each official release that they ship; the supported locales can be modified at this time.

On the other hand, deployments should aim to become actively involved in the OLPC release process: updating, testing and refining their translations during the development stages of the release. This can't be done if OLPC's own releases don't include the locales/translations in question; asking deployments to regularly re-spin development builds is probably asking a bit much. So, deployments requesting inclusion of their specific locale makes a lot of sense, even if they will re-spin and customize the official release build when the time comes.

Como contribuir

Developing, Testing, Translating

Ver tambien

• Release Process Home/Historical - historical plans for parts of the release process