We are half way through the year and a lot of work is done, and lot more is yet to be done. This week we look back at some of the CloudStack Collaboration Conference, work continues on 4.1.1 and 4.2.0, and we have some interesting discussions on how we should release the CloudMonkey and Marvin tools used with CloudStack. There's a by-laws vote underway to look at how and where we decide non-technical issues, and some discussion on the best way to to discuss and do code reviews.
To help get information out a little more timely to key discussions and information that is going on in the community we are going to move the publishing of the weekly news to Wednesdays starting July 10th!
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.
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 the freeze date, and Animesh Chaturvedi is keep the release on schedule. If the feature or merge you are working on 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 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.
We are now just two days away from feature freeze, but still there are many open tickets. If the feature or improvement is unlikely to be wrapped up by 6/28 it should be moved out of 4.2
As for bugs here is a summary for this week:
Bugs
This Week
Two Week Ago
Blocker
Critical
Major
Total
Blocker
Critical
Major
Total
Incoming
4
19
37
68
8
20
29
60
Outgoing
19
42
34
102
18
10
42
76
Open Unassigned
4
27
116
184
7
35
93
166
Open Total
17
62
223
365
19
74
192
345
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, 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 fail safe API cache. Starting a discussion about the future of how to treat CloudMonkey and Marvin.
Follow-up - Rohit and David Nalley have since moved CloudStack CloudMonkey out to it's own Git Repository and version based off the continuing conversation through last week. No decisions have been made yet in regards to Marvin and if community members have an opinion are encouraged to join the discussion.
A Vote on final adoption of the move of CloudMonkey is now underway. Please join in the Vote thread.
As we continue to work on improving CloudStack, there are additional upgrades to the tools that we use to bring CloudStack to life. Hugo Trippaers started the discussion on support for Java 1.7 and Tomcat 7. Please join in the discussion as it will have affect development of future versions of CloudStack.
In previous discussion about publishing books about CloudStack on the CloudStack.Apache.Org page, Sebastien Goasguen noted that there's a question about voting on a list that isn't dev@:
...
Our bylaws (1) do not cover votes on non-technical matters, so while we have
lazy majority on this vote it seems that this situation is not covered by the
bylaws. Moreover section 3.1.1 of bylaws says that decisions on the project
happen on dev@, so it seems that votes even on marketing@ are not allowed
(unsure about this).
...
Based off this, Noah Slater has proposed new language to the by-laws to help improve our ability to manage such decisions.
...
Summary of changes:
- Addition of "3.4.2. Non-Technical Decisions" section. This specifies that
non-technical decisions can be made on any appropriate list (i.e. marketing@)
and also allows us to vote on them with lazy 2/3 majority.- Changed "The vote must occur on a project development mailing list." to
"The vote must occur on the project development mailing list." in several
places. This makes it explicit that these decisions must be made on
the dev@list.- Minor rewordings, typographical changes, corrections, section
renumbering, etc.
...
We now enter the work period and get going on these proposals. Please help them as they try to help improve Apache CloudStack.
Please let your voice and your organization be heard in this short survey. We would like to have both users of the Apache CloudStack source and Commercial derivatives, "We will be using the data in aggregate to get to know more about how it's being deployed out there." Chip Childers commented. Click Here to take the short survey.
In a heavily discussed topic throughout the community to allow the publishing of outside books about CloudStack on the CloudStack.Apache.Org website or wiki, it was finally voted on and decided to allow outside publications to be published. Right now Sebastien Goasguen has setup a wiki page and will work on where to have the permanent placement for this page.
Gregg Witkin and Jessica Tomechak are working together on videos this summer, including one that aims to show some of the most interesting real-world applications of CloudStack. They're asking for participation on this video, and suggestions for other videos you'd like to see. Check out these videos Gregg did with CloudStack just last year. Link 1, Link 2
If you're not able to join, all sessions are being recorded and will be available after the conference for viewing.