Replacing ivy with maven-ant-tasks
Is this something that people are OK with? It will result in the version details being specified from the build.xml and not a separate ivy.xml Which branch shall I target first... My preference is to target 0.7 and then when the modularization takes place in trunk/0.8 it will be on top of the maven-ant-tasks changes. If everyone is OK I'll create a JIRA against Core with fixVersion 0.7 and add my patch there. -Stephen
Re: Replacing ivy with maven-ant-tasks
On 18 January 2011 14:30, Eric Evans eev...@rackspace.com wrote: On Tue, 2011-01-18 at 13:13 +, Stephen Connolly wrote: Is this something that people are OK with? Why? What are the advantages? 1. It will make deploying to central easier (as ivy does not deploy correct poms, and maven-ant-tasks can generate correct poms) 2. _You_ seemed to think it would be better keeping all the version information in build.xml rather than in a separate file 3. You seemed to think it might be a good idea when you saw the mavebn-ant-tasks stuff for deploying to central There's probably some more but those are the main drivers from my perspective. Note Maven-Ant-Tasks is not Maven... it provides essentially the same functionality as ivy only targetted exclusively at Maven repositories... (which are the only really repository format (other than p2) to take off) -Stephen
Re: Avro in the Cassandra core
On Jan 17, 2011, at 9:01 PM, Eric Evans wrote: On Mon, 2011-01-17 at 12:12 -0500, Jake Luciani wrote: Some context: We have begun the process of removing Avro from the service layer CASSANDRA-926. We currently use Avro for schema migrations internally, and we have two open items that are using Avro for our internal file storage. CASSANDRA-1472 and CASSANDRA-674. FWIW, this should be done (removing the RPC interface). Anything missed is deserving of a bug report My opinion is we need to control the lowest layers of the code and not rely on a third party library. By using a third party library like Avro, it becomes a black box that we need to deeply understand and work around. Also, since Avro is developed separately we have another core dependency that could disrupt releases (say a bug in Avro). +1 The Avro RPC interface was an experiment, and it was always the case that if it didn't supplant the Thrift interface as status quo, that it'd be removed. However, as I remember it, part of the justification for using it in migrations was that it was already there. In hindsight that was probably a mistake. Anyway, we have too many dependencies as it is, I'd rather move toward eliminating it entirely unless there is a very compelling reason not to (I don't think there is). Just saw Stu's comment on CASSANDRA-1472: I think that implementing a compressible block based file format is a non-trivial task, and that before we commit to re-implementing Avro's (in a bounded timeframe especially), we should review our requirements. This decision needs to be made for technical reasons and not grounded in NIH. Is that a compelling reason to use avro for some of the internals or is that something that someone is willing to implement/maintain? Just trying to bridge discussion here with comments on the ticket. -- Eric Evans eev...@rackspace.com
Re: Proposal: fixed release schedule
On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote: Everyone on chrome commits to trunk first. I think the important change we could make is to keep everyone closer to trunk. We spend a good deal of effort back-porting patches between major versions. I think we should make the major versions less different. This would mean letting them live for shorter amounts of time and possibly making them bugfix only. Currently we add new features in stable branches, but I think if we made the major release schedule more predictable people would be more comfortable with letting their new feature wait until the next major version. I'll call your keep-close-to-trunk, and raise you a: * branch as soon as all planned features land in trunk * iteratively release betas w/ bug-fixes only * release candidates are actual candidates for the final (not releases) The time between creating the branch and making the release should be as short as practical, and there should be no backward incompatible changes between the first beta, and final release. The discussion seems to be petering out and I wonder if that means folks are still trying to wrap their heads around everything, or if we have consensus. If we're in agreement on 4 months between releases, and feature-freezing branches in the run-up, then that would leave us with say 7 weeks (give or take) to land everything in trunk that we expect in the next release (and I would think that at this point we'd at least have a good idea what that'd be). -- Eric Evans eev...@rackspace.com
