Possible compromise on releasing architectures

[Blars Blarson <blarson@blars.org>]

The Vancouver meeting concluded that more of the burden of supporting
the various architectures needs to be on the port teams, but did not
supply a workable way for releases to be made on less popular
architectures.

Here's a proposal that will hopefully both meet the main desires of
the release managers and the port teams.

Release architecture:

* All FTBFS and architecture specific bugs are release critical
* packages must be built on all to propagate to testing

Release candidate architecture:

* testing managed by port release manager(s)
* testing consists of packages that built on the candidate and
  are in release architecture testing with the same version
* testing proposed updates may be needed more often due to changes
  in dependencies
* need a way to propagate architecture specific packages (such as 
  boot loaders) to testing
* FTBFS and other architecture specific bugs are release critical 
  if a reasonable[0] patch is in the BTS
* Will release if testing is in good shape at release time, or at 
  point release time
* stable security team may decide not to provide security support

Non-release architecture:

* no testing, unstable only

[0] When there is a difference on what is reasonable, the technical
    committee will decide.


-- 
Blars Blarson			blarson@blars.org
				http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.