The Javelin branch has been merged into master by Kelven Yang. Kelven has noted that developers should increase the amount of memory available to the JVM if running the management server under Maven:
For linux/Mac users
MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx2g"
export MAVEN_OPTSFor Windows users
Add similar settings to windows environment settings (via Windows control panel)
Following the Javelin merge, Chip Childers has created the 4.1 branch, and has asked committers "to respect the feature and improvement freeze in that branch. Bug fixes, doc updates and other release stabilization activities are obviously expected." Chip also says that committers should continue committing directly to the 4.1 branch until code freeze. (Code freeze, excepting fixes for blocker bugs and so forth, is on February 28th.)
If you're a non-committer and wish to send in a patch against 4.1.0, send in a patch built against the 4.1 branch. Chip says:
Committers taking these fixes should also consider applying them to master. If there are conflicts in master (which may happen, as there were a
couple of code-base refactoring activities, like switching packages from com.cloud to org.apache.cloudstack), apply the fix into 4.1 anyway, and inform the submitter that the patch has conflicts with master to get that sorted out (or you can fix it yourself).
With the feature freeze in place, it's time to get docs into shape and start getting things ready for translations. Sebastien Goasguen has created a new /pot directory with the .pot (portable object templates).
Sebastien notes that contributors need to remember the 50-character limit for XML filenames, as Transifex doesn't support longer file names. Contributors will also need to run publican update_pot when updating doc files and/or creating new files.
Hugo Trippaers sent out an update about the discussion on packaging for 4.1. Hugo says the main goal for redoing the current way of packaging CloudStack is to get "rid of ant and waf completely." The secondary goal "is to create a reference set of packages which in itself should be enough to get anyone going with CloudStack, but will hardly depend on the underlying distro. Real distro specific stuff should be handled by packagers from those distros. We just aim to provide a reference implementation."
Hugo also says that the plan is to rename the packages "to make it perfectly clear what somebody is installing." That's going to change the location of a number of files, but Hugo says "we intend to include symlinks for backwards compatibility."
The planned packages for now are cloudstack-management, cloudstack-agent, cloudstack-common, cloudstack-cli, cloudstack-docs, cloudstack-awsapi and
cloudstack-usage. You might already have seen these names in some of the checkins.
One of the side-effects of the new packaging plan is that CloudMonkey may not be installed with the RPMs, but instead require that admins use PIP to grab CloudMonkey.