Re: Subversion vs other source control systems
No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. I would assume though that if there is enough interest among the community, the subject of supporting something like Git could be opened up with the Board, yes? /Janne, who does not really know how this bit of ASF works... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] as to Thrift Proposal
+1 On Feb 7, 2008, at 7:27 PM, Ted Husted wrote: Here's my binding +1 on the Thrift proposal. On Jan 23, 2008 9:07 PM, Mark Slee <[EMAIL PROTECTED]> wrote: Hi all, We've just posted the Apache Incubator proposal for Thrift onto the Wiki: http://wiki.apache.org/incubator/ThriftProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept CouchDB for incubation
+1 On Feb 9, 2008, at 11:09 AM, Sam Ruby wrote: We've had an initial discussion, which attracted a number of messages of encouragement, and identified no issues or concerns. Then we proceeded onto a proposal, which attracted three excellent mentors. Now it is time to vote on the proposal which can be found on the Apache Wiki, and reproduced below. I would like to proudly start this off with my +1. - Sam Ruby http://wiki.apache.org/incubator/CouchDBProposal Project Name: CouchDB - == Proposal == The goal is to create either an Apache top level project around the existing CouchDB open source project. Key Features: * a REST API using JSON for data transport, * a JavaScript view engine based on Mozilla Spidermonkey, * a GNU Autotools build system supporting most POSIX systems * a built-in administration interface * experimental fulltext search with Lucene === Rationale === The goals of the project are aligned with the goals of the ASF, namely there is interest in (continuing to) foster a collaborative, consensus based development process, using an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. === Initial goals === * Features for next release * Incremental reduce support, for full map/reduce support. * Document validation model (validate live and replicated changes) * Documentation, Documentation, Documentation * Fulltext Search * Priority feature work * Live compaction * Extensible security model * LDAP authentication * More query capabilities exposed to HTTP, e.g. multi-key view lookups * Future feature work * Server storage partioning * Server failover clustering * Requested Features * hierarchical structure in documents == Current Status == === Meritocracy === The project has recently transformed from being primarily a single person led (and funded) project to one with a number of diverse participants. Development has been coordinated primarily through a mailing list, with some IRC. === Community === The community consists of a set of independent developers, one of which recently joined IBM === Initial Developers === * William Beh * Damien Katz * Jan Lehnardt * Christopher Lenz * Dirk Schalge * Noah Slater === Alignment === A database server with a strong focus on HTTP and REST principles. === Known Risks === * Dependency on Erlang * Including some modifications to the HTTP server stack. The plan is to convert over to [http://code.google.com/p/mochiweb/ MochiWeb] (MIT licenced) * Dependency on Mozilla SpiderMonkey * Including small modifications, to be sent back to Mozilla === Orphaned Products === * This is a new effort, and is far from being orphaned. === Inexperience with Open Source === All participants are active users and contributors to open source. One of them (Christopher Lenz) has experience as committer on other Apache projects. === Homogenous Developers === The exiting committers are spread over a number of countries and employers. === Reliance on Salaried Developers === Only one developer is being paid to work on CouchDB. Read [http://damienkatz.net/2008/01/faq_about_couch.html his views] on the relationship he has with his employer. === Relationships with Other Apache Products === Experimental usage of Lucene === An excessive fascination with the Apache brand === This product started out independent of Apache and under a GPL license. After discussions with a number of people within IBM, Damien Katz agreed to pursue both incubation at the ASF, and employment at IBM == Documentation == === Initial Source === Resides on [http://code.google.com/p/couchdb/ Google Code]. The code has been recently relicensed from GPL to the Apache License, Version 2.0, in anticipation of this submission. === Source and Intellectual Property Submission Plan === The bulk of the core code was written by Damien Katz. Major contributions include: a GNU Autotools build system supporting most POSIX systems contributed by Noah Slater, a built-in administration interface provided by Christopher Lenz, and experimental fulltext search with Lucene by Jan Lehnardt. ICLAs either have been, or are in the process of being, submitted for all code involved in this submission. ICLA's are already on file for: * Jan Lehnardt * Christopher Lenz ICLA's in progress: * William Beh * Damien Katz * Dirk Schalge * Noah Slater There are a few (as in single digit) number of files that we are continuing to sort through the licenses. These include Public Domain, X Consortium, and MITish licenses. === External Dependencies === * [http://www.icu-project.org/ ICU] (MIT) * [http://www.erlang.org/ Erlang] (Erlang Public License) * [http://www.mozilla.org/js/spidermonkey/ SpiderMonkey] (Mozilla Public License) === Cryptography === Not applicable === Required Resources === * Mailing lists: * couchdb-pmc for private PMC discussions (with moderated subscriptions) * couchdb-dev * couchdb-
Subversion vs other source control systems
J Aaron Farr wrote: > J Aaron Farr wrote: >>> git could be an issue. > > Can you explain what the issue is with Git? > Leo already gave a decent explanation. > Basically, it comes down to two aspects: > 1) infrastructure support > 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: > > 1. You have to use subversion. > Why? Has been a vote done? where? I vote +1 for git if a vote is still open. No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. No project was allowed to stay with CVS. No project will be allowed to use another source control system unless it is adopted at the ASF level. Source code is a critical, shared, public resource maintained by the Foundation, not something whose storage is managed on a project by project basis. The Infrastructure Team maintains and protects that shared resource on behalf of the Foundation. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Re-election of podling committers before graduation
On Feb 13, 2008, at 1:38 PM, Bertrand Delacretaz wrote: On Feb 13, 2008 1:09 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: ... In projects where commit is handed out with ease, and that commit is never used, at some point it should be reviewed (and this should happen BEFORE graduation, as a precondition of graduation, not as a trigger upon graduation) Agree with this, and this is similar to what I was initially suggesting. Several of us in this thread think that this review of commit rights should not be a re-election as initially suggested, but rather a process that the podling mentors can run as they see fit: maybe not at all if all committers are obviously active, by election if desired, or in any suitable way. Do people agree on leaving this up to podling mentors, and requiring that they report on this commit rights review in the podling's graduation request? I definitely think it's a mentor-driven process that deserves a sentence in the graduation request, right along side "meritocracy" and "independent committers". Craig -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [DISCUSS] Re-election of podling committers before graduation
On Feb 13, 2008 1:09 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >... In projects where commit is handed out with ease, and that commit is > never used, at some point it should be reviewed (and this should happen > BEFORE graduation, as a precondition of graduation, not as a trigger > upon graduation) Agree with this, and this is similar to what I was initially suggesting. Several of us in this thread think that this review of commit rights should not be a re-election as initially suggested, but rather a process that the podling mentors can run as they see fit: maybe not at all if all committers are obviously active, by election if desired, or in any suitable way. Do people agree on leaving this up to podling mentors, and requiring that they report on this commit rights review in the podling's graduation request? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Proposal] NoNameYet : Link Error - please use this link
I'd like to add a few words hopefully to clarify a few things: The base code BEA is donating to this project is an implementation started from scratch by me, Radu and Wing Yew as the only contributors, it has nothing to do with Tuscany, so there is no way this code can be interpreted as a fork from Tuscany. Also, to my best knowledge, BEA was not involved with Tuscany SDO. I think the best way to go forward would be to unite both the JSR235 and Tuscany SDO communities under an SDO oriented project. From a code standpoint I don't know how easy/hard would be to unite the two, but we will not know until we'll work together. How the two code bases will evolve should be driven by the community. Kelvin sent a message about this on Tuscany mailing lists a couple of days ago, until now there were only a few but encouraging responses. Cezar Andrei -- Forwarded message -- From: kelvin goodson <[EMAIL PROTECTED]> Date: 31 Jan 2008 09:47 Subject: Re: [Proposal] NoNameYet : Link Error - please use this link To: general@incubator.apache.org http://wiki.apache.org/incubator/NoNameYetProposal That's what you get for employing reuse tactics -- gmail remembers the original URL. I've been caught by this before, so I thought I had taken appropriate action to avoid this behaviour, but sadly not so, apologies. Kelvin On 31/01/2008, kelvin goodson <[EMAIL PROTECTED]> wrote: Hi all, We've posted an Apache Incubator proposal onto the incubator wiki http://wiki.apache.org/incubator/NoNameYetProposal We haven't got a good name yet, SandStorm is a contender, as is Snowdon Suggestions and comments welcome, Kelvin. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Re-election of podling committers before graduation
Hi Bill, On Feb 13, 2008, at 4:09 AM, William A. Rowe, Jr. wrote: In projects where commit is handed out with ease, and that commit is never used, at some point it should be reviewed (and this should happen BEFORE graduation, as a precondition of graduation, not as a trigger upon graduation). Thanks for the clarification. That's exactly what I've been saying all along. Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [DISCUSS] Re-election of podling committers before graduation
Niclas Hedhman wrote: On Tuesday 12 February 2008 02:35, Craig L Russell wrote: The difference is that committers in a TLP have been granted this privilege based on their merit, not just by updating a wiki page saying that they're interested. Actually, if/where this is the case, it is not proper. I want to only see past contributors on initial committer lists. Therefore incubator policy should be to accept no proposals that do not consist of existing code written by three or more authors. This whole thread has fallen off-track. My point was that different podlings, different TLPs have different considerations for how commit access is handed out (and reaped at some point in the future based on actual contribution). My further point is that we are fitting square pegs in round holes. In projects where commit is handed out with ease, and that commit is never used, at some point it should be reviewed (and this should happen BEFORE graduation, as a precondition of graduation, not as a trigger upon graduation). Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] as to Thrift Proposal
On Feb 10, 2008 10:54 PM, Leo Simons <[EMAIL PROTECTED]> wrote: > On Feb 8, 2008, at 1:27 AM, Ted Husted wrote: > > Here's my binding +1 on the Thrift proposal. > > +1! +1 > > On Jan 23, 2008 9:07 PM, Mark Slee <[EMAIL PROTECTED]> wrote: > >> Hi all, > >> > >> We've just posted the Apache Incubator proposal for Thrift onto the > >> Wiki: > >> http://wiki.apache.org/incubator/ThriftProposal > > Proposal also pasted below for mail archive purposes... 8-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Re-election of podling committers before graduation
On Tuesday 12 February 2008 02:35, Craig L Russell wrote: > The difference is that committers in a TLP have been granted this > privilege based on their merit, not just by updating a wiki page > saying that they're interested. Actually, if/where this is the case, it is not proper. I want to only see past contributors on initial committer lists. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
