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 [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
