Re: [VOTE] Accept Cassandra into the Incubator

2008-12-27 Thread Jason van Zyl


On 26-Dec-08, at 3:31 PM, Torsten Curdt wrote:


[ ] +1 Accept Cassandra as a new podling
[ ] -1 Do not accept the new podling (provide reason, please)


-1 (binding).

I will even give reasons because it is Christmas;
a. See Martijn's concern.
b. Running vote over Christmas when *many* people are busy with  
other

things.
c. I would like to see a proposal with more meat in it. Some
history, more elaboration on the various topics that the template
provides...



Just a different perspective:

a) I agree with the concern but as Martijn expressed, I'm not sure it
should be a real concern for the vote. If the project dies, so be  
it. But
clearly a few individuals seem to care so why not giving them a  
chance?
b) +1 on this one, it could just be balanced by setting a longer  
than usual

voting time frame.
c) I agree although some feedback has been provided on the ML, it  
could be

nice to bring back some of that in the proposal.


Some thoughts from this end:

I also have the feeling that the proposal could benefit from some more
meat. The timing around Christmas indeed was not very helpful
either. But what really concerns me a bit is the question whether
people really want to/can work together. It seems like the fork /


The word fork does not appear in the proposal, but at the very top of  
the proposal it says it started at Facebook. I just read the proposal  
and a few emails today so I don't know anything about the project but  
that immediately says to me there is some disparity. If it's a fork  
that's fine, but that's something pretty important to leave out of the  
proposal.




non-fork debate already left some scars and I am not eager to invest
time when people can't get along even to begin with. Maybe my Avalon
alarm is set a little too sensitive but for now I only vote +0.

Ian, since you are the one driving this... would you mind working with
the project team on improving the proposal? ...and then consider a
re-submit?

cheers ...and Merry Christmas
--
Torsten

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [VOTE] Accept Cassandra into the Incubator

2008-12-27 Thread Brian McCallister
I consider this to be a high-risk project, and agree with Martjin's
concerns, but do not consider this a bar to entering incubation. The
*reason* Cassandra wants to enter incubation is to address these
weaknesses.

+1

-Brian

On Tue, Dec 23, 2008 at 2:01 PM, Ian Holsman li...@holsman.net wrote:

 Dear Incubator PMC,

 There has been some discussion around the Cassandra proposal,
 and we would now like to officially propose Cassandra to the Incubator
 for consideration..

 Please vote on accepting Cassandra project for incubation. The full
 Cassandra proposal is available at the end of this message and as a wiki
 page at http://wiki.apache.org/incubator/Cassandra. We ask the
 Incubator PMC to sponsor the Cassandra podling, with Brian as the Champion,
 and Torsten, Matthieu, and Ian volunteering to mentor as well.

 The vote is open for the next 72 hours and only votes from the
 Incubator PMC are binding.

 [ ] +1 Accept Cassandra as a new podling
 [ ] -1 Do not accept the new podling (provide reason, please)

 
 = Abstract =

 Cassandra is a distributed storage system for managing
 structured/unstructured data while providing reliability at a massive scale.

 = Background =

 Development of Cassandra started in Facebook in June 2007. It started of a
 system to solve the Inbox Search problem and since then has
 matured to solve various storage problems associated with
 structured/unstructured data.

 = Rationale =

 Cassandra is a distributed storage system for managing structured data that
 is designed to scale to a very large size across many commodity servers,
 with no single point of failure.
 The philosophy behind the design of the storage portion of Cassandra is that
 it be able to satisfy the requirements of applications that demand storage
 of large amounts of structured data. Reliability at massive scale is a very
 big challenge. Outages in the service can have significant negative impact.
 Hence Cassandra aims to run on top of an infrastructure of hundreds of nodes
  (possibly spread across different datacenters). At this scale, small and
 large components fail continuously; the way Cassandra manages the persistent
 state in the face of these failures drives the reliability and scalability
 of the software systems relying on this service.

 = Initial Source =

 Intial Source can be obtained from the following site -
 http://the-cassandra-project.googlecode.com/svn/branches/development/. The
 mailing list is currently maintained at the same site.
 We will move it over to Apache once this proposal has been accepted.

 = Source and Intellectual Property Submission Plan =

 = External Dependencies =
 * All dependencies have Apache compatible licenses. Dependencies are log4j,
 Thrift, Apache Commons.

 = Cryptography =
 * None
 = Committers =

 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan
 * Jiansheng Huang
 * Dan Dumitriu

 = Current Status =
 == Meritocracy ==

 * Though initial development was done at Facebook, Cassandra was intended to
 be released as an open source project from its inception. Environment will
 lend itself to support meritocracy at all times.

 == Community ==
 * Folks who are actively considering deploying/prototyping Cassandra in
 their respective organizations.

 == Core Developers ==
 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan

 == License ==
 * The Cassandra codebase is Apache 2.0 licensed, and currently hosted at
 Google Code.
 = Known Risks/Avoiding the Warning Signs =

 == Orphaned Products ==
 * Cassandra is already deployed within Facebook and many other organizations
 are actively moving to deploy this in production. Original developers
 are and will actively stay involved and hence there is no realistic chance
 of it getting orphaned.

 == Homogenous Developers ==
 * The current list of committers includes developers from different
 companies. The committers are geographically distributed across the U.S.

 == Reliance on Salaried Developers ==
 * Yes. But don't expect this to be a risk of any nature.

 == Relationships with Other Apache Products ==
 * The Cassandra project is 'similar' to hbase/HDFS in concept, but Cassandra
 is more geared for Online web site usage than batch. It also doesn't have a
 single point of failure, which makes it interesting as well.

 * Cassandra makes use of the Thrift project.

 == An excessive fascination with the Apache brand ==
 * Cassandra has already attracted a stable base of users. There are at least
 3 companies who are planning to use Cassandra in production as far as we
 know. The reasons for joining Apache are not to advertise the project, but
 rather to demonstrate the commitment to open source by divorcing the trunk
 from any one corporation and pursuing further integration with other Apache
 projects.

 = Required Resources =
 == Mailing lists ==

  Once the project is approved, the following mailing lists will be used for
 discussion.
  * cassandra-u...@incubator.apache.org
 

Re: [VOTE] Accept Cassandra into the Incubator

2008-12-27 Thread Martijn Dashorst
I'd like to see some plan on dealing with the fork/community stuff. We
*know* it is a problem, and I'd like to see how this is being
addressed in the proposal. In my opinion that is the crux to this
proposal. Just going Apache is not going to solve problems. The
feather is not a magic wand you can wave around and make problems
disappear.

What will happen when the original coders won't come with the project?
What when they do and then disappear *again*? How will you get the
folks on board that don't want to come over?

Martijn

On Sat, Dec 27, 2008 at 6:13 PM, Brian McCallister bri...@skife.org wrote:
 I consider this to be a high-risk project, and agree with Martjin's
 concerns, but do not consider this a bar to entering incubation. The
 *reason* Cassandra wants to enter incubation is to address these
 weaknesses.

 +1

 -Brian

 On Tue, Dec 23, 2008 at 2:01 PM, Ian Holsman li...@holsman.net wrote:

 Dear Incubator PMC,

 There has been some discussion around the Cassandra proposal,
 and we would now like to officially propose Cassandra to the Incubator
 for consideration..

 Please vote on accepting Cassandra project for incubation. The full
 Cassandra proposal is available at the end of this message and as a wiki
 page at http://wiki.apache.org/incubator/Cassandra. We ask the
 Incubator PMC to sponsor the Cassandra podling, with Brian as the Champion,
 and Torsten, Matthieu, and Ian volunteering to mentor as well.

 The vote is open for the next 72 hours and only votes from the
 Incubator PMC are binding.

 [ ] +1 Accept Cassandra as a new podling
 [ ] -1 Do not accept the new podling (provide reason, please)

 
 = Abstract =

 Cassandra is a distributed storage system for managing
 structured/unstructured data while providing reliability at a massive scale.

 = Background =

 Development of Cassandra started in Facebook in June 2007. It started of a
 system to solve the Inbox Search problem and since then has
 matured to solve various storage problems associated with
 structured/unstructured data.

 = Rationale =

 Cassandra is a distributed storage system for managing structured data that
 is designed to scale to a very large size across many commodity servers,
 with no single point of failure.
 The philosophy behind the design of the storage portion of Cassandra is that
 it be able to satisfy the requirements of applications that demand storage
 of large amounts of structured data. Reliability at massive scale is a very
 big challenge. Outages in the service can have significant negative impact.
 Hence Cassandra aims to run on top of an infrastructure of hundreds of nodes
  (possibly spread across different datacenters). At this scale, small and
 large components fail continuously; the way Cassandra manages the persistent
 state in the face of these failures drives the reliability and scalability
 of the software systems relying on this service.

 = Initial Source =

 Intial Source can be obtained from the following site -
 http://the-cassandra-project.googlecode.com/svn/branches/development/. The
 mailing list is currently maintained at the same site.
 We will move it over to Apache once this proposal has been accepted.

 = Source and Intellectual Property Submission Plan =

 = External Dependencies =
 * All dependencies have Apache compatible licenses. Dependencies are log4j,
 Thrift, Apache Commons.

 = Cryptography =
 * None
 = Committers =

 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan
 * Jiansheng Huang
 * Dan Dumitriu

 = Current Status =
 == Meritocracy ==

 * Though initial development was done at Facebook, Cassandra was intended to
 be released as an open source project from its inception. Environment will
 lend itself to support meritocracy at all times.

 == Community ==
 * Folks who are actively considering deploying/prototyping Cassandra in
 their respective organizations.

 == Core Developers ==
 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan

 == License ==
 * The Cassandra codebase is Apache 2.0 licensed, and currently hosted at
 Google Code.
 = Known Risks/Avoiding the Warning Signs =

 == Orphaned Products ==
 * Cassandra is already deployed within Facebook and many other organizations
 are actively moving to deploy this in production. Original developers
 are and will actively stay involved and hence there is no realistic chance
 of it getting orphaned.

 == Homogenous Developers ==
 * The current list of committers includes developers from different
 companies. The committers are geographically distributed across the U.S.

 == Reliance on Salaried Developers ==
 * Yes. But don't expect this to be a risk of any nature.

 == Relationships with Other Apache Products ==
 * The Cassandra project is 'similar' to hbase/HDFS in concept, but Cassandra
 is more geared for Online web site usage than batch. It also doesn't have a
 single point of failure, which makes it interesting as well.

 * Cassandra makes use of the Thrift project.

 == An excessive 

Re: [VOTE] Accept Cassandra into the Incubator

2008-12-27 Thread Brian McCallister
On Sat, Dec 27, 2008 at 11:26 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 I'd like to see some plan on dealing with the fork/community stuff. We
 *know* it is a problem, and I'd like to see how this is being
 addressed in the proposal. In my opinion that is the crux to this
 proposal. Just going Apache is not going to solve problems. The
 feather is not a magic wand you can wave around and make problems
 disappear.

 What will happen when the original coders won't come with the project?
 What when they do and then disappear *again*? How will you get the
 folks on board that don't want to come over?

The fork was something proposed by Ian because there was no clear
path for folks to become involved with Cassandra. The folks working on
it at Facebook didn't want to see a fork, and proposed entering
incubation in order to structure opening up development. Avinash and
the others on the proposal *are* the core contributors, there is no
fork, and hopefully there will be no need to.

No one expects to wave a feather over the code and have a vibrant
developer community appear, but you *can* wave a wand and have a set
of expectations appear, which is what Cassandra is trying to do.

The plan: follow the normal apache process. Folks contribute good
stuff, the folks involved recognize this and make the contributor a
committer, useful code continues to come into existence, rinse-repeat.

The plan is no different than any apache project.

-Brian


 Martijn

 On Sat, Dec 27, 2008 at 6:13 PM, Brian McCallister bri...@skife.org wrote:
 I consider this to be a high-risk project, and agree with Martjin's
 concerns, but do not consider this a bar to entering incubation. The
 *reason* Cassandra wants to enter incubation is to address these
 weaknesses.

 +1

 -Brian

 On Tue, Dec 23, 2008 at 2:01 PM, Ian Holsman li...@holsman.net wrote:

 Dear Incubator PMC,

 There has been some discussion around the Cassandra proposal,
 and we would now like to officially propose Cassandra to the Incubator
 for consideration..

 Please vote on accepting Cassandra project for incubation. The full
 Cassandra proposal is available at the end of this message and as a wiki
 page at http://wiki.apache.org/incubator/Cassandra. We ask the
 Incubator PMC to sponsor the Cassandra podling, with Brian as the Champion,
 and Torsten, Matthieu, and Ian volunteering to mentor as well.

 The vote is open for the next 72 hours and only votes from the
 Incubator PMC are binding.

 [ ] +1 Accept Cassandra as a new podling
 [ ] -1 Do not accept the new podling (provide reason, please)

 
 = Abstract =

 Cassandra is a distributed storage system for managing
 structured/unstructured data while providing reliability at a massive scale.

 = Background =

 Development of Cassandra started in Facebook in June 2007. It started of a
 system to solve the Inbox Search problem and since then has
 matured to solve various storage problems associated with
 structured/unstructured data.

 = Rationale =

 Cassandra is a distributed storage system for managing structured data that
 is designed to scale to a very large size across many commodity servers,
 with no single point of failure.
 The philosophy behind the design of the storage portion of Cassandra is that
 it be able to satisfy the requirements of applications that demand storage
 of large amounts of structured data. Reliability at massive scale is a very
 big challenge. Outages in the service can have significant negative impact.
 Hence Cassandra aims to run on top of an infrastructure of hundreds of nodes
  (possibly spread across different datacenters). At this scale, small and
 large components fail continuously; the way Cassandra manages the persistent
 state in the face of these failures drives the reliability and scalability
 of the software systems relying on this service.

 = Initial Source =

 Intial Source can be obtained from the following site -
 http://the-cassandra-project.googlecode.com/svn/branches/development/. The
 mailing list is currently maintained at the same site.
 We will move it over to Apache once this proposal has been accepted.

 = Source and Intellectual Property Submission Plan =

 = External Dependencies =
 * All dependencies have Apache compatible licenses. Dependencies are log4j,
 Thrift, Apache Commons.

 = Cryptography =
 * None
 = Committers =

 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan
 * Jiansheng Huang
 * Dan Dumitriu

 = Current Status =
 == Meritocracy ==

 * Though initial development was done at Facebook, Cassandra was intended to
 be released as an open source project from its inception. Environment will
 lend itself to support meritocracy at all times.

 == Community ==
 * Folks who are actively considering deploying/prototyping Cassandra in
 their respective organizations.

 == Core Developers ==
 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan

 == License ==
 * The Cassandra codebase is Apache 2.0 licensed, and 

Re: [VOTE] Accept Cassandra into the Incubator

2008-12-27 Thread Brian McCallister
On Sat, Dec 27, 2008 at 11:26 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 I'd like to see some plan on dealing with the fork/community stuff. We
 *know* it is a problem, and I'd like to see how this is being
 addressed in the proposal. In my opinion that is the crux to this
 proposal. Just going Apache is not going to solve problems.

Actually, it is a huge first step. Right now there is no path for
non-FB employees to contribute.

Second step is to encourage non-FB (or other FB folks) folks to contribute.

Third step is to make them committers.

Fourth step is to have the whole crowd get beers together at the next apachecon.

Fifth step is GOTO 2.

:-)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [PROPOSAL] Apache Maestro

2008-12-27 Thread Niclas Hedhman
On Sat, Dec 27, 2008 at 8:13 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote:

 The AutoDeploy scope is not the same as the Lokahi one.
 AutoDeploy is an whole environment updater, covering JEE resources
 (JDBC DataSource, JMS queue/topic, JMS connection factory, JNDI name
 space binding, share lib support, EAR/WAR deployment with classloader
 policy, configuration files, etc), and this, in the same manner whatever the 
 underlying
 application server used (JBoss, Weblogic, Websphere).
 AutoDeploy can use Lokahi to support Tomcat for exemple.

Ok, I would still be very positive to folding those into a single
project, if at all possible (stretch your imagination)...


Cheers
Niclas

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [PROPOSAL] Apache Maestro

2008-12-27 Thread Jean-Baptiste Onofré
For sure, AutoDeploy will use Lokahi to support Tomcat but, for now,
I think it's better to have to different project as the usage and
scope are not the same at all.
For exemple, ServiceMix heavily uses Geronimo parts and ActiveMQ but it's
not the same project.

I will discuss with Lokahi people to understand what is exactly the roadmap 
and define is interaction are possible between AutoDeploy and Lokahi.

Regards
JB

On Sunday 28 December 2008 - 14:58, Niclas Hedhman wrote:
 On Sat, Dec 27, 2008 at 8:13 PM, Jean-Baptiste Onofré j...@nanthrax.net 
 wrote:
 
  The AutoDeploy scope is not the same as the Lokahi one.
  AutoDeploy is an whole environment updater, covering JEE resources
  (JDBC DataSource, JMS queue/topic, JMS connection factory, JNDI name
  space binding, share lib support, EAR/WAR deployment with classloader
  policy, configuration files, etc), and this, in the same manner whatever 
  the underlying
  application server used (JBoss, Weblogic, Websphere).
  AutoDeploy can use Lokahi to support Tomcat for exemple.
 
 Ok, I would still be very positive to folding those into a single
 project, if at all possible (stretch your imagination)...
 
 
 Cheers
 Niclas

-- 
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
j...@nanthrax.net
PGP : 17D4F086

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org