Tags:
create new tag
, view all tags
Note: This is largely replaced by TWikiRelease04x01Process

How release contents are decided

How do we decide what gets into a release? There is general agreement that a decision will be made by "someone who knows" - either a release manager or a consensus in a release meeting (or maybe both). It's unfair to ask the decision makers to spend huge amounts of time researching changes, and it's unfair to ask developers to spend huge amounts of time coding changes that were going to get rejected from day one. This process seeks to strike a balance between these two needs.

Stuff that has already been coded

Often people code exciting improvements, and want to get them released. We need to decide if it is suitable for release, and if so, whether it should target a minor release, or wait for a major release.

The process for deciding this is:

  1. If the code is not adequately documented, or exhibits unacceptable behaviours (such as breaking existing content) it won't get in.
  2. If anyone thinks something should be in a minor release, make a written case for it in Codev, linked from the agenda of the next release meeting. Give as much warning as possible so it can be reviewed.
  3. The default (changes without a champion) is to wait for the next major release

New stuff

New stuff must have:

  1. A detailed explanatory topic in Codev. This should (try to) cover potential end user impacts as much as possible.
  2. If you have existing code, a demo will strengthen your case considerably. A scratch branch might be a good place for this; or you could use your own public TWiki demo site if it is possible.
  3. If you think something should be in 4.1, make a written case for it in Codev, linked from WhatIsIn04x01. Give as much warning as possible so it can be reviewed.
  4. Don't propose something unless you are sure you can code it (or get it coded) in time for the release. Be prepared to have it reverted if it isn't ready in time.

Trivial stuff / No brainers

Some changes are so trivial that there is more work in justifying them than in coding them. In this case it should be sufficient to provide a one-line description of the proposal in the release planning document (for example, WhatIsIn04x01). But if anyone challenges the change, asks a question, or it's unclear what is proposed, you will have to fall back to the processes described above.

-- Contributors: CrawfordCurrie, Attendees at EdinburghReleaseMeeting2006x06x26

Discussion

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2006-10-08 - KennethLavrsen
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.