Page History

...

Introduction

• Plan is to complete the training in three 50-minutes weekly sessions
• David introduced the training outline and who the audience is.
  • David explains the context of release management from the framework of open-source projects
  • In his explanation, he refers to "Projects of Projects" and that this term can become a bit confusing.  It is important to understand the context of the discussion.  CAMARA is a Project, but we also have "sub-projects" that, for the uninitiated, can introduce confusion.
  • David noted that during the training he may refer to "PTL" or Project Team Lead.  While the community does not have PTLs, "codeowners" is similar enough for a reference to the prepared material. 
    • JOSE ANTONIO ORDOÑEZ LUCENA noted that there are API families in CAMARA can be considered their own categories that could be "Projects of Projects of Projects" How do we handle this?
    • David noted that the goal is that we have a simultaneous release.  There will be a general cadence for CAMARA overall.  Sub-projects may have their own release cycle, but there should be a unified release as well.  It will be a question of what of those intermittent releases for sub-projects to be a part of the simultaneous release.   You can think of this as a release of release or meta release, as you prefer.
  • Another consideration is the interdependencies between sub-projects.
    • Herbert Damker Commonalities sub project deals with the overlap between projects that define guidelines for the projects.
    • David noted that if common release artefacts that every sub-projects is supposed to release as a part of the meta release, it will greatly simplify the release process overall. 
    • A key interdependency that we would point out would be documentation.
    • Herbert Damker noted that the project does not currently have a CI or Documentation project, but noted that it is something currently under consideration. 
  • Simultaneous release
    • David noted that by "Simultaneous release," we mean that the sub-0projects coordinate the release on a regular cadence.
  • Periodic Release
    • Regular, predictable releases are the lifeblood of open source projects.  I may be difficult to maintain for projects who have infrequent or irregular contributions.
  • Roles and responsibilities 
    • LF Staff will provide general assistance with training and development of the release process and schedule.  They will also help with specific issues that arise and release retrospectives and help identify and recommend improvements to the process.
    • Community release managers
      • LF recommends at least 2 community release manages for a variety of reasons.
        • They will help provide periodic updates on the release status to the community and TSC and make recommendations on improving the release process.  They will track the completion of release tasks and lead the community in the retrospectives at the end of the release.
        • Codeowners will be responsible for updating the release milestone tracker for each sub-project.  They can also alert the release manager and the TSC to issues to risks of the release schedule or issues.  They will also complete their release plan for each release for their sub-project.  They should also participate in the retrospective.
      • TSC may review and approve release process, schedule, milestone exceptions and other similar functions.
  • Adapting the training to the community
    • David noted that there is more than one valid way to do release management
    • The LF is sharing our best practices that we have learned from other open-source projects. 
    • The LF does not impose processes on the release; these are only recommendations. 
    • Core principals include:
      • A transparent release process
      • Indipented of any individual or group
      • Feasible, efficient, and not burdensome
  • Developing the release process
    • List of work products that will be produced
    • A documented workflow that shows the steps and dependcies for each work process
    • set of milestones with allocated workflow steps
    • set of tasks to meet the requirements for each milestone
    • A defined release cadence and schedule template with the milestones
    • TSC approval
  • Overview
    • Identify the work products
      • This may be obvious, but the work products are expected to be a critical first step
      • It may be that you intend for only a portion of  the work products to be produced during a particular release process
        • Some work products may need a different process or cadence that could be referred to as "unmanaged."
      • Work products will evolve over time.
      • Each sub-project should assert their participation at the start of a release cycle and provide a release plan that documents their work products.
    • Document the process steps and dependencies for each work project
    • Identify logical checkpoints that may be used as release milestones
      • May want to include end users in this
    • Document the tasks that must be completed for each milestone
    • Prepare a schedule them plate with the identified milestones
    • socialize the proposed release process
    • TSC approval
  • Completed through slide 28 in the release management training deck.  Will resume on slide 29 in the next session.
  • Team agreed to continue training with two more 50-minute sessions, as planned.
  • Next training session will be Nov 28.

Action items