mRFC 0047: SVN reorganization to stable and devel versions of each branch

1. Changes
2. Introduction
3. Discussion
4. Proposal
1. Merge process

Changes

• 2009.07.02 rambo: Initial version

Introduction

This is related to the problem mRFC 0046 tries to address but will propose approach that is usable for the older generations as well (for various reasons it's practical impossibility to require unit tests in pre-Vinland MidCOM).

Discussion

In the dev list

Proposal

See this discussion for background and details.

1. Split each generation branch to branchname-stable and branchname-devel
2. Stable branch commit rights will be severely limited
3. All changes are made to devel branch, they're merged to stable upon request confirming to a set process (see below)
4. Official channel packages are built from stable branch
5. Nice-to-have: unofficial devel channel with autobuilt packages for
   • Testing
   • Those who like to live dangerously

Merge process

1. Requester makes a task ticket to trac with the info on which exact revisions and paths to merge, in format usable directly as arguments to svn merge and the reason for merge (security fix, new feature) and links to all tickets related.
2. Requester gets someone else to test the changes as well (all tests against the stable branch merged with the provided revisions), that someone will add their test results to the trac ticket, in some cases (critical components) 3 test reports from different people may be required.
3. Requester informs the VCS tyrant that this is ready for merge
4. VCS tyrant reviews the request and determines whether to proceed (for example in some branches we may only accept bug fixes, or even more strictly only security fixes)