The above is just a suggestion of how we could handle a more predicatable process.
Other suggestions are of course welcome.
I think this sounds good, if we can demonstrate that we release on the day we say we will release users can be confident when the fix they require will be available. We can also prioritise the tasks so that the scheduled items are based on the current demand.
In general I think defining what is going to be in the release early is good so people can see what is going to be included but I don't think it should completely prevent additional tasks being added in weeks 3 to 6.
Items should only be added in weeks 3 to 6 on the condition that they will not impact any other scheduled tasks and it can be comfortably be delivered by the end of week 6 if these two can not be guaranteed then they need to go into the next release.
Yes, we should see the above more like guide lines that help us to achieve predictability. We don't want strict rules that do not allow exceptions.
Development continues in trunk until we reach code freeze. Then we branch and do the remaining QA related work in that branch. Finally we tag from the QA branch.