Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Packaging Cassandra for Debian [was: Packaging Cassandra for
 Ubuntu]
From: Eric Evans <eevans@rackspace.com>
To: dev@cassandra.apache.org
In-Reply-To: <8EBF1776-A6E9-4FA5-B5F1-B6BE301F61B9@ubuntu.com>
References: <8EBF1776-A6E9-4FA5-B5F1-B6BE301F61B9@ubuntu.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 04 Jun 2010 14:21:27 -0500
Message-ID: <1275679287.17492.156.camel@erebus.lan>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2010-06-03 at 07:55 -0700, Clint Byrum wrote:
> So I am appealing to you, the Cassandra development community, to weigh in with your recommendations on making Cassandra and its dependencies available in Ubuntu.
> 
> Specifically I'd like to address:
> 
> * What is the perceived and real impact of Library versions diverging from Cassandra's shipped libraries over time.
> * We will most likely conflict with the Cassandra published debian packages. Is this acceptable? Suggested solutions?

So, the bigger problem here would seem to be one of long-term support.
In other words, trying to find common ground between release cycles.

I am (have been) interested in uploading Cassandra to the Debian
archives, so let's use that as an example:

Debian is in the run-up for Squeeze and Cassandra is working toward 0.7,
let's assume those coincide and that the next stable version of Debian
shipped with 0.7 (while 0.7 is still relevant/current).

It will be somewhere on the order of 18-24 months before a new Debian
stable release, and at the current rate, that would equate to at least 4
new major Cassandra releases (maybe as many as 6). We've been pretty
good about the upgrade path between consecutive majors, but can you
imagine trying to jump 6 versions? Not going to happen.

And, the situation isn't really that much better for other distros.
Ubuntu has a new release every 6 months, but their LTS is maintained for
*6* years.

I'm not suggesting that we purposefully slow development, or that we
extend the period between releases, but there is a reason that people
want Linux distros that are supported for 6 years, and the reasons apply
to our software as well.

I'm curious what others think:

* Do you see a point where the pace of development naturally slows,
(less low hanging fruit, etc)?
* If so, what do you see in terms of progression? What would the spacing
look like a year from now? Two years from now?
* Is this something we're eventually going to have to discipline
ourselves on?

-- 
Eric Evans
eevans@rackspace.com