You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

1. Roadmap and Feature Planning

Purpose

  • To create the initial time-line for the release: the roadmap.
  • To define/update the platform functional requirement.
  • To identify the main technical goals for the new release.

Entry Criteria

  • E1.1 Previous release version of the distribution was released.

Tasks

  • T1.1 Create the roadmap and platform functional requirement description. 

A detailed description about the rules used to build the roadmap and platform functional requirement is in [xx]. These document need to be written in AGL confluence.

  • T1.2 

AAAA


  • T1.1 Create the roadmap description. This task is done taking the last roadmap as a template and working around the holidays in China, Germany, Czech Republic and USA. A detailed description about the rules used to build the roadmap is in [15]. The final roadmap need to be written in XML using the schema from [4]. This roadmap contains all the information from T1.1 and T1.2. This XML is published using the SIMILE JavaScript program [5] to create a time line web page as the official reference. In parallel with this, the roadmap is published in the wiki from the project [1], and maintained during the release process, linking the new milestones when they are released. The important dates (roadmap and freezes) are made explicit and easy to consult for users and developers.
  • T1.2 Feature freeze calendar. Together with the roadmap calendar is the associated feature freeze calendar [1]. There are three stages of freezing: toolchain freeze after M3, base system freeze after M4 and full feature freeze after B1. After that the maintenance process starts. Freezes are scheduled at the end of milestone development periods to give time for development after a milestone release. They should not be placed too close to the next release as the frozen components should get a little testing before the milestone is out.
  • T1.3 Determine the new features. On the mailing list (as the primary channel for discussing ideas and features) and through other community communication channels the new features expected for this release are discussed and defined. Some of those features can be documented on openFATE [6] (not widely used) or the wiki [3]. The features can be decided inside the community (in this moment this is done only by a really small number of contributors) or internally in SUSE when there is a relation between SLE and openSUSE: a developer can create a feature in FATE for SLE and then add openSUSE afterward (this kind of feature is not visible outside) At this moment we do not have a strict policy on using openFATE. Some features are also decided later without planning and documentation. If the feature is implemented after the freeze calendar, an explicit approval from the Factory Maintainer is needed for the integration.

Verification

  • V1.1 Review the roadmap. The roadmap needs to be approved by the Product Manager and the Release Manager.
  • V1.2 Roadmap maintenance. Small changes in the roadmap are not communicated, just executed. But if a delay threatens the release day, an announcement is expected, and if the delay is serious we need to communicate it widely [17] [18]. In every case T5 is involved, update the wiki.

Exit Criteria

  • X1.1 The roadmap and the freeze calendar are published in the mailing list

Deliverables

  • D1.1 XML Document where the roadmap is described [4]
  • D1.2 The features documented in openFATE [6] and in the wiki [3]



  • No labels