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

Compare with Current View Page History

« Previous Version 8 Next »


This is just a draft version put together to capture the feedback provided during the meeting and present my point of view based on my experience in other open source projects

Current state

  • Patches are submitted via gerrit
  • Architecture is described on a wiki and (sometimes) later migrated to read the docs
  • We have a waterfall-ish development model with clearly distinguish planning, designing, implementation and testing phases
  • There is a lot of paper work to be done at every milestone
  • Features for every release are described globally (per release) and approved by TSC in the beginning of each release
  • We have 2-3 releases per year


Proposal

Development

  • Keep 3 releases in a year:
    • W8
    • W24
    • W43
  • Divide the release in 3 sections:
    • R - 16 Release kickoff
      • Start estimating what we can do within the release
      • Start socializing global requirements (for example S3P)
    • R - 14 Global requirements defined
      • TSC approves a list of global requirements that has to be address by the teams in this release
    • R - 10 Spec freeze
      • All features that are going to be implemented in this release should be approved by Arch and impacted PTLs
    • R - 5 Feature freeze
      • End of accepting patches containing new features for this release
      • Start of bugfixing period
      • Release branch is being created for all participating projects
    • R - 3 Beginning of RC-phase
      • RC every end of week
      • Bugfixes submitted for both master and release branch
      • Feature development may continue for approved specs in the master branch
    • R - 0 - final testing, release notes and Sign-off
  • Assumptions:
    • Architecture (spec) work is being done continuously
    • Every spec has below stages in its life cycle:
      • Proposed
        • The spec has been proposed by the author for a review by affected parties
      • Approved
        • The spec has been reviewed by interested parties and approved
        • In this point we agree that the design is good and if we find the resources it can be implemented
      • Scoped for the release
        • There is a volunteer to work on this particular spec within this release
        • The work may be continued in next release with PTL and TSC consent.
      • Implemented
        • The spec has been fully implemented and should be mentioned in the release notes
      • Dropped
        • The spec has been dropped because no one is willing to work on it or it became out of the date
  • No labels