Horde release cycle

• Horde 1.0.0: 1999
• Horde 2.0: 2002
• Horde 3.0: 2004

... and finally Horde4 in 2011.

The gap between 3.0 and 4.0 has been too large. The Horde team tries to keep backward compatibility within a major version. Probably nobody tried running a recent Kronolith from 2010 on Horde 3.0 from 2004. There'd probably be some issues and limitations but they should be minor.

While this kind of long term support may be useful for some edge cases it can also impede development progress. A good example are the Kolab drivers in the currently released version: Kolab support within Horde started to improve in 2006. At that time Horde3 was already the active branch and there was some very basic Kolab functionality in there. So the new code had to keep those interfaces stable. Which basically meant twisting and bending it into code that would do just that but otherwise be really problematic. That code is still a reality in the current stable release from Horde3.

This and similar problems did not pass unnoticed though and changes to the release cycle have been discussed internally for a while already. With the release of Horde4 approaching it now makes sense to discuss such changes with the Horde community. The envisioned target is a time based release cycle.

The discussion started today on the Horde development mailing list. Feel free to listen in or to add your own comments if you want to influence the direction of our future release mode.

Hudson Quickie

After my third Hudson repository using the same installation procedure it was definitely necessary to finally extract the whole Hudson specific part into its own repository.

It is nothing fancy as the installation procedure with Hudson is pretty straightforward anyhow. But maybe you want to get Hudson quickly running on your own Linux machine with a few standard plugins pre-installed. Then the repository might be exactly what you need.

Just clone the repository with

git clone git://github.com/wrobel/hudson-install.git

and follow the "Install" instructions in the README. Of course you can also just fork the repo in case you need your own predefined set of plugins installed into Hudson.

The Horde4 package mill for Debian

As mentioned before p@rdus intends to provide Horde4 packages for Debian beside the Kolab specific OpenPKG based build. The first steps of this process have been taken now and another Hudson based package mill has been created for the task. The new system bundles Horde4 packages for Debian after each upstream commit and lives here.

This is just considered a first step on the way to a full Debian release as there will be a fair amount of quality control required to get the packages fit for wider distribution. In addition the exact policy on how to handle PEAR packages on Debian is apparently still under debate. p@rdus will join this discussion now with a set of more than 50 PEAR based packages in tow.

The timing for this seems just right as there are still a few weeks left until Horde4 will see its first release. So there should be enough time to ensure that there are no major conflicts between PEAR based and Debian packaging.

An early Horde4 release for Kolab-Server-2.2.4

A while back p@rdus promised an early alpha of Horde4 for the Kolab Server for today. Which would have been followed by the release of the Horde4 mail client and the new mobile mail view in the following weeks. But as the Horde developer team has been quick to provide the new mobile view there is no need to delay the delivery of the mail client and the mobile portal any further. So you get a little bit more than promised today but as it is St Nicholas' Day that seems to be just fair.

Of course all the usual warnings apply. This is an extremely early packaging attempt. It is not well prepared and the installation procedure is flawed. There will be no upgrade path. Doing the following on your server has a high chance of damaging the system. Do not even think about installing the packages on a productive machine. In addition the packages just install the mail part of Horde and won't provide a lot of new functionality. And since there are tons of issues the stuff that is new is likely to be broken.

But those of you who have a spare machine with a throw-away Kolab Server 2.2.4 can try to install the packages using the following steps (this assumes your server is up and running):

wget http://files.pardus.de/horde4-20101206.sh
chmod u+x horde4-20101206.sh
./horde4-20101206.sh

You should be able to access the Horde4 installation at http://your-domain.com/client4.

Any kind of feedback is of course appreciated and will be used to improve the packages during the months to come. p@rdus will also continue testing and bug fixing of the packages while the final phases of the Horde4 development continue.

Now there are no December items of the roadmap left. So p@rdus will continue the next weeks with highlighting the new elements you can expect to find in Horde4. This should be accompanied with a few bug fix releases. In addition it is planned to provide you with a demo server in case you do not have a spare machine to test the new packages. So stay tuned!

PHP library release survey

Tobias Schlitt is asking PHP developers and users about their preferences concerning the release process of PHP libraries. I figured I spread the word and provide you with the link to the survey.

The survey itself originates from an ongoing discussion on how to release Zeta components. It will certainly not allow to extract a generic guideline on how to release your PHP code but I think that is also not what the survey intends to do.

The central question of the survey "What is your preferred way of installing PHP libraries?" does only have one correct answer after all. But that one varies depending on the person asked and on the installation target.

"Man, I clicked this cool button on my webhosters site and now I got this webmail installed in just one go. What a nice custom installer!"

"I just love Ubuntu. I even have that on my server. If I need a PEAR IMAP library I can just apt-get install pear-horde-IMAP_Client. If I need Horde I run apt-get install horde4. And I get all the security updates automatically! Using your distribution or OS is really the only choice there is."

"I downloaded Horde and installed it on my dedicated server. Set it to run on lighty and it's blazing fast. I connected it to our LDAP user DB. Now I still need to get the Facebook and Twitter API keys so our users can connect to their accounts there. Unpacking and installing the tarballs was no major deal."

"I'm a PHP developer and I want to code a small application that needs to handle IMAP. It needs to be better than the IMAP stuff from PHP. But I don't want to code the protocol handling myself and I don't want to pull something totally unstable from a repo. And please don't give me a full framework. I just need IMAP. Oh, and in a year I might want to upgrade in case there were fixes to the package. Can I get Horde_Imap_Client via PEAR please?"

"Huh? I code Horde, I do some PEAR. Sometimes I pull stuff via the OS. For customers the tarballs are great. But at the end of the day: There is only git."

Screenshots of the new Horde4 mobile portal

As mentioned before p@rdus currently sponsors development of draft mobile mail and mobile calendar portals for Android, iPad and iPhone. These portals are based on Horde4 and the recently released jQuery mobile framework.

The Horde developers have been far quicker than they promised themselves and so without further ado here are some early screenshots of the projects:

• Login screen
• Portal
• List of folders
• Mailbox view
• Message view
• Month view
• Day view
• Event view

Now p@rdus still needs to ensure that these screens go live on a Kolab server near you. Packaging is progressing well and chances are high that you can try the alpha version very soon.

Resizing an EBS volume

If you run into size limitations with an EBS (Elastic block storage) volume attached to your EC2 instance it just takes a few minutes to expand the storage space.

• Unmount the small volume (assumed to be /dev/sda here).

unmount /dev/sda

• Detach the unmounted partition from the instance.
• Take a snapshot of the detached volume.
• Recreate an EBS partition from the snapshot.
• Attach the EBS disk to your instance.
• Resize and remount the larger volume with:

e2fsck -f /dev/sda
resize2fs -p /dev/sda
e2fsck -f /dev/sda
tune2fs -l /dev/sda
mount /dev/sda /somewhere

Installing the Kolab Server on Ubuntu 10.04

Just a quick note on the required steps to get the Kolab server installed on an Ubuntu 10.04 server. The first step pulls the required dependencies to be able to compile the Kolab sources:

sudo apt-get update
sudo apt-get install bison flex gcc automake libtool autoconf tcl

And subsequently the server code gets downloaded and installed via the standard commands from the Kolab wiki:

mkdir /tmp/kolabtemp
cd /tmp/kolabtemp
wget -r -l1 -nd --no-parent http://files.kolab.org/server/release/kolab-server-2.2.4/sources/
gpg --keyserver wwwkeys.pgp.net --recv-key 5816791A
gpg --verify SHA1SUMS.sig
sha1sum -c SHA1SUMS
sudo sh install-kolab.sh 2>&1 | tee /root/kolab-install.log

The Horde4/Kolab package mill

p@rdus established another Hudson based continuous integration setup in preparation of the first experimental Horde4 packages in two weeks. The new system bundles Horde4 packages for the Kolab-Server-2.2.4/OpenPKG and lives here.

Packaging the Horde4 source code for a distribution is nearly trivial as the basic Horde packages are already continously integrated and packaged as PEAR modules. Because of that it is likely that p@rdus will establish a similar process for the native Kolab-Server/Debian.

With Kolab currently planning to move away from OpenPKG it is also possible that p@rdus makes the native Debian port the primary supported platform for Horde4 on Kolab in the future.

Horde continuous integration

With the increasing complexity of a huge codebase such as provided by Horde there is a significant need for quality control. As p@rdus accumulated a decent amount of experience with a variety of PHP QA tools during the past years it was only natural to apply this knowledge to the Horde codebase.

Many modules - including the Kolab_* packages - are now under constant surveillance of a continous integration server. The system is available for your inspection at ci.horde.org.

The service itself is run by Hudson - the standard CI server these days. The tools deployed on the server are a collection of the latest and greatest in the arena of quality control for PHP. PHPUnit certainly being the most important one as it delivers the framework for unit testing and code coverage analysis. In addition Hudson runs PEAR CodeSniffer (style check), PHP Depend (structural analysis), PHP Mess Detector, and the PHP Copy Paste Detector. On top of this the brand new PHP Code Browser integrates the analysis results into a view of the code.

With this system in place Horde is probably the only PHP based groupware client that can claim to validate its code base against current commercial grade software standards for PHP with each and every commit.