Inching towards the finish of his six-part series on the lessons the Eclipse team learnt form the Callisto Simultaneous Release, Bjorn Freeman-Benson posts the fourth installment. Here, he talks about why the team chose not to use mirror sites.

Mirror sites are volunteers with limited bandwidth and disk space budget that help in offloading bandwidth from other sites. In the Eclipse community, members help each other through the use of mirror sites, Bjorn says. However, in the Callisto simultaneous release, even their issues needed to be addressed.

“Early in the Callisto planning process, we considered creating zip distributions of different subsets of the ten Callisto projects. In the very worst case, this would be 1,023 different subsets and up to 17,000 zip files. We’re talking about 1.7Tbs of files we would be asking our mirror sites to handle. It was deemed too burdensome,” he says.

Bjorn also mentions that a corrupt Eclipse.org server seeded a bogus copy of an early Callisto release candidate to the mirrors. “It took the teams almost two weeks to solve this problem and during that period we were all losing faith in the mirrors, when it turned out not to be the mirrors fault at all,” Bjorn writes.

In the end, the lesson learnt was that distributing a working system is more than putting the zip file on the server. “There is a large infrastructure of people and machines that makes the distribution happen. Those people are part of the project even if they aren’t coders or even directly associated with the project, and they deserve their credit,” Bjorn writes.