DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
In this section we look at major discussions that have happened on the CloudStack mailing lists. This is by no means a full summary of all discussions on the lists, but we try to hit the highlights that are relevant to the larger CloudStack community.
...
Much of the work for Code Freeze in now in effect starting 6/28 and the 4.2 branch was created on 6/29. There is currently no motion in the community to extend this, and Animesh Chaturvedi is doing his best to keep us on schedule. If the feature or merge was unable to make it in, please start to move it to your JIRA tickets and additional documentation to 4.3 scheduled to release sometime in December.
Currently Animesh is underway, but there is still a lot of work to still be done. Code Freeze was on 6/28. Currently Animesh Chaturvedi is handling the release management for 4.2 has listed out our current state. He put together an e-mail on the current status of the release. If we don't quickly get these resolved further delays in the release and jeopardize future releases.
...
With 4.1 now released we are already beginning work on the 4.1.1 patch update. Ilya Musayev is the release manager for the 4.1.x branch, but Chip Childers will handle the 4.1.1 release as Ilya is unavailable during the timeframe we expect to finish 4.1.1 and call for a VOTE, and has asked work all merges to be completed. Once that is done, he will call for a VOTE.
As we seen in the past and now again in 4.2, it's important to focus on merging your features early and often. By breaking up large merge and code review requests it is possible to help keep releases on schedule, get features in before the freeze and avoid Veto votes. Alex Huang and Kelven Yang worked really hard on a new and large VMSync feature that many users need. Because it came in so close to freeze and was a large merge request with less than a week before freeze it immediately received Veto votes blocking the merge. Even with the help of several other committers the review couldn't be done in a timely fashion and miss the 4.2 cutoff.
When late requests come in like this it also puts undo stress on the testing of the release as well. Read through the merge thread to follow the discussion on how we can improve this in the future.
After complaints that the BVT environment was broken, Alex Huang did some investigating to identify the root cause and raise a suggest on how BVT testing should be dealt with in the future.
After Dave's complain in the vmsync MERGE thread about BVT in horrible shape on master, I went around to figure out what exactly happened. The best I can figure is that after a certain merge (I will leave out which merge as that's not important), BVT no longer runs automatically. It was promised to be fixed and there are people who are actively fixing it but it's been in this way for about two weeks. People running BVTs are working around the problem but it's not automated anymore and so it's no longer running on master. I understand people are nice and tried to be accommodating to other people by working around the problem but sometimes we just have to be an arse. So let me be that arse...
New Rule....
If BVT or automated regression tests break on master or any release branch, we revert all commits that broke it. It doesn't matter if they promise to fix it within the next hour. If it's broken, the release manager will revert the commits and developers must resubmit. It sounds mean but it's the only way this problem can be fixed.To avoid having a bunch of reverts and resubmits, the developers should be able to request that BVT run on their branch and don't merge until BVT on their branch is at 100%. We will work on figuring out how to do that.
On June 9th, Rohit Yadav asked about a problem with the 4.1.0-0 CloudMonkey release on PyPI lacking the failsafe fail safe API cache. Starting a discussion about the future of how to treat CloudMonkey and Marvin.
...