Release process

In an effort to stop a long going ping-pong again, let's concentrate on figuring out what was wrong with the old release, and trying to improve it in the future. I'll start by saying that generally, overall, the last release was pretty good. Ok, so COM didn't work, but only a very small number of people is actually affected by this. Overall, the QA process *worked*. To get to fix the bugs in the QA process, we need to look at the exceptions to the rule, i.e., the things that didn't work out right. The first and obvious example then, would be the COM module. I believe that the main difference in the COM module patches, when compared to other patches, is that it was mainly to implement new functionality, or to rewrite code in a better way. We should probably have a guideline that new code/code rewrite patches should not be submitted to RC branches. Another issue was the inability of people to deliver patches on time. I.e., there were quite a few patches that were important to put in the release (i.e., fixed bugs) but came in after 'the last RC' was announced. That's one of the reasons we had so many 'last RCs' in this RC round. Whether there's a good solution here is not very clear; My guess is that there isn't. The question is whether we should be more aggressive about dates (i.e., if you didn't submit your patch on time, it's your problem) or not. There's no good answer here IMHO, comments welcome... Those were the two main broken things about the last release. Let's concentrate on fixing them instead of rethinking the whole architecture, because it *worked*. Zeev