Task Team for Software Releases

This topic describes the release task team. The process followed by this team is described in ReleaseProcess.

Goals

• Customer focused
• Easy and quick to get new features accepted
• Some way of control to make sure we stay focused on mission, quality and performance
• Scalable (not too much workload on a single person)

Tasks

• Coordinate build of release
• Freeze the release (before the first release candidate is built)
• Delegate responsibility when unavailable
• Monitor feature proposals.
  • Ensure that the proposal has a committed driver that will implement it if accepted.
  • Note if concern has been raised.
  • Follow the discussions and see if consensus is reached.
  • If discussion stops without a result decide try to trigger the community to end the discussion
  • If no consensus is reached bring forward features with proposals to release meeting
• Authorise fixes (patches, or inter-release update packages)
• Create the builds as required
  • When very severe bugs are found shortly after a release
  • When a level 1 or 2 security issue is found that requires a fast release
  • When the number of bugs has pilled up to a level that justifies a release
• Create upgrade package that can be applied to any previous release within same major/minor tree
  • Upgrade package containing all files changes since last minor/major release (last decimal 0 in release number)
    • Ensuring that upgrade package can be applied to a production site with almost no downtime to fix things.
    • Excluding files that may have been updated but changes are not necessary and would make the upgrade less easy.

Help Wanted

We need help from people with experience of:

• Releasing software products
• Integration testing
• Perl (and other script) coding
• Writing end-user documents
• Planning and tracking

Unknowns

There are a number of points of clarification that are required before the charter can be considered complete:

1. How long does the charter last? Suggest until the next major release, or 6 months (1st May 2009) depending on which is shorter.
2. What additional but currently undocumented powers are required in this team? For example:
   • Power to dictate release date
   • Power to select feature set for releases
   • At the moment, the rubric above states that this team controls the "theme" of releases. However it has not yet been effective in doing this. is this really something that should be vested in this team?
3. There's a lot of reading above (which is good, insofar as it covers a lot of detail) but I'd like a short summary at the top covering: Goals (bullet points), Powers (bullet points) and Members (drawn from the roles embedded, I guess)

---

Moved to "Running" as per decision at Community meeting 3/11/08. Would still appreciate answers to my questions above.

-- CrawfordCurrie - 04 Nov 2008 - 07:52

Is there an overlap with the DebianPackagingTaskTeam? How do you guys coordinate?

Kenneth, can we have a status update please?

-- CrawfordCurrie - 09 Dec 2009

Defacto - the release team is ME.

And I do not see myself having power. I am secretary that coordinate and suggests releases. Those releases that I have "dictated" have been security related patch releases and not planned releases.

I believe the right thing is to redefine this team again and I will take a stab at this trying to describe what we have and describe my own role (assuming that noone currently have a desire to do what I do).

I will gladly continue my role as release manager. I am not a great programmer. I am a project manager by skill. And I think I can best serve the project in this role. Some of the old description above is a lot about power. I do not see my role as a power role. I am a secretary that tries to keep an overview of the releases, does many practical things, and reminds people about "misc stuff" so everything gets done.

The specialized releases like debian etc are normally coordinated. But with the security initiated releases I do not have a good answer to how to coordinate this and at the same time keep things secret while developers are looking for a fix. Suggestions welcome. In practical life people have responded fast after I release but maybe a simple email notification to a short list of special release maintainers that I send 2 days before a security release is what is required. For regular releases the public release plan should be shouted out to everyone all the time.

Inputs for me are very welcome.

-- KennethLavrsen - 10 Dec 2009