Re: [PROPOSAL][VOTE] Subversion
+1 Ralph On Nov 4, 2009, at 12:12 PM, Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at
Re: Two other issues to discuss for Subversion
On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. I am fine with doing everything as if this was a TLP with the two exceptions that 1) the main page should say it is still in incubation 2) it is still under the umbrella of the IPMC until graduation. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Nov 10, 2009, at 7:17 PM, Greg Stein wrote: On Tue, Nov 10, 2009 at 21:09, Ralph Goers ralph.go...@dslextreme.com wrote: On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. I am fine with doing everything as if this was a TLP with the two exceptions that 1) the main page should say it is still in incubation 2) it is still under the umbrella of the IPMC until graduation. the main page ... are you referring to http://subversion.tigris.org/ ? Regardless, yeah.. that thing should be updated to reflect the project's new status. If a different page, then please let me know, and I'll make it happen. No. http://subversion.apache.org. I saw the comment about keeping the main page at subversion.tigris.org but i see no reason it shouldn't move to apache during incubation. The tigris page can stay up as long as they want but should eventually redirect to Apache. Regarding oversight: absolutely. No matter where the assets may reside, the IPMC is responsible for them. And regarding my previous aside: I do think that, in the future, we (the IPMC) may want to go ahead and place projects in their intended location to start with, to avoid that graduation-move. Something for a separate discussion. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Serf vs Neon (was Re: [PROPOSAL][VOTE] Subversion)
Is this topic really appropriate for incubator general? I'm having trouble following along with all the noise. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Serf vs Neon (was Re: [PROPOSAL][VOTE] Subversion)
On Nov 11, 2009, at 7:27 PM, Greg Stein wrote: On Wed, Nov 11, 2009 at 20:48, Ralph Goers ralph.go...@dslextreme.com wrote: Is this topic really appropriate for incubator general? I'm having trouble following along with all the noise. At the root, it is a discussion about LGPL dependencies in an incoming podling. Neon is LGPL. Serf is ALv2. Both are optional, though you really want to choose one for a broadly-useful svn build. In the past, Neon was the default. For 1.7, serf is going to be the default, although a few people in the community are wary of that choice. yes, I got that. But all the discussion about whether serf is an acceptable replacement or whether eclipse will use it doesn't belong here. I got the impression with the first post on the topic that the Subversion community already understood the issue. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Discussion] Graduation of Pivot Podling
I have been following Pivot's dev list since August. My only concern involves an incident where I posted a suggestion and was slapped down very hard by one of the committers. If this had been my first exposure to the ASF I never would have come back. That being said, I quickly got an offline apology from another committer. Niclas and I also chatted offline about the incident and I don't believe he would be in support of graduation if he didn't believe the situation was still the same. Since then I have been silently following the dev list. I have not seen a repeat of this incident since then and the community has been progressing with good participation from several individuals. In short, when this comes to a vote I will vote in favor of graduation. Ralph On Nov 15, 2009, at 7:10 PM, Todd Volkert wrote: Gang, The feeling among the members of the Pivot podling (mentors included) is that it is ready for graduation. We think that the following issues remain in good order: - No licensing issues. - Active community from 3 employers. - Good communications in public. - Consensus-driven and positive attitude decision making. - 3 releases under the belt, the last two of which were without issues. In addition, it has been almost four months since our last attempt at graduation, and we believe that the issues brought up during the previous graduation vote [1] [2] have been resolved. Specifically, since our last graduation vote: - Noel Grandin has 31 commits [3] - Sandro Martini has 157 commits [4] - Chris Brind has 7 commits [5] - Greg Brown left VMware, and committer activity didn't suffer - We received a number of patch submissions from non-committers [6] [7] [8] We would like to receive feedback if someone feels that Pivot is not ready to graduate. In the meantime, we will polish up our Board resolution proposal to be included in a vote thread later in the week. Thanks, -T [1] http://wiki.apache.org/incubator/November2009#Pivot [2] http://mail-archives.apache.org/mod_mbox/incubator-general/200908.mbox/browser [3] http://svnsearch.org/svnsearch/repos/ASF/search?from=799941to=836127author=noelgrandin [4] http://svnsearch.org/svnsearch/repos/ASF/search?from=799941to=836127author=smartini [5] http://svnsearch.org/svnsearch/repos/ASF/search?from=799941to=836127author=brindy [6] https://issues.apache.org/jira/browse/PIVOT-314 [7] https://issues.apache.org/jira/browse/PIVOT-333 [8] https://issues.apache.org/jira/browse/PIVOT-313 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
In general, Java code at Apache should reside under a package of org.apache. In this case, I would expect org.apache.subversion.javahl. Of course, this will create compatibility problems. I don't know if it is completely possible to create a separate jar containing the necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort. Ralph On Nov 16, 2009, at 11:00 AM, Greg Stein wrote: Dunno. Lots of java packages have had to deal with the issue as they migrate to the ASF. I'm sure that gene...@incubator (cc'd) has some prior knowledge and precedent. Cheers, -g On Mon, Nov 16, 2009 at 11:47, C. Michael Pilato cmpil...@collab.net wrote: What does the migration mean for JavaHL's package namespace and our version compatibility? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
On Nov 17, 2009, at 1:25 AM, Niclas Hedhman wrote: Java coding standard(s) makes very strong assertions that package names should be 'owned' domain names, to ensure avoidance of name collisions. Apache has maintained such for practically all projects, incl all incoming projects, and I am somewhat confident that some of these projects have more dependent developers than Subversion. The indirection overhead would be optional. Do a s/org.tigris/org.apache/g replace and you are good to go without the overhead. There is a more practical reason for this. If I have a need to debug a package or get further documentation, the package name gives me a pointer as to where to look. If tigris.org disappeared users would get very confused. IMO, whether the package names are changed in 1.7 or in some future release is up to the project to decide. But they should change sooner or later. You asked for our input and this is it. Ralph
Re: JavaHL package namespace / migration / compatability
On Nov 17, 2009, at 6:27 AM, Hyrum K. Wright wrote: On Nov 17, 2009, at 3:11 AM, Branko Čibej wrote: Ralph Goers wrote: In general, Java code at Apache should reside under a package of org.apache. In this case, I would expect org.apache.subversion.javahl. Of course, this will create compatibility problems. I don't know if it is completely possible to create a separate jar containing the necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort. I don't quite understand the point of this. Here we are with a Java wrapper library for the Subversion APIs. The versioning rules that apply to it are the same as for the rest of Subversion -- in other words, we *must* keep the same package names in the JavaHL public API. Is there a specific reason for doing a bunch of extra work that does not add any value to JavaHL but only adds a layer of indirection for /all/ users of the library? Subversion's versioning guidelines say that the old APIs (and implicitly the package names) need to stay stable in future 1.x releases. That does not, however, preclude us from creating an up-to-date interface in the org.apache namespace, and only adding new and future features to that interface, effectively deprecating the old one. Makes sense to me. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation of Apache Pivot
On Nov 17, 2009, at 9:47 AM, Todd Volkert wrote: Hi all, The Apache Pivot community feels that it is ready to graduate into the Apache Pivot top-level project. Please place your votes within the next 72 hours -- to serve as recommendations to the Board at the December Board meeting. [ ] +1, Graduate Apache Pivot [ ] 0, I don't care [ ] -1, Apache Pivot is not ready to graduate, because... +1 Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
On Nov 17, 2009, at 8:40 PM, Niclas Hedhman wrote: On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz jus...@erenkrantz.com wrote: As Hyrum suggests, we can use org.apache.subversion.* if we want to create a new (better) Java interface within our versioning rules - but that isn't necessary nor should it be a pre-req for graduation. IMNSHO, either Subversion address this issue pre-graduation, OR we remove the package name change requirement for ALL incubating projects, leaving it up to the project post-graduation to address it. It has been a contentious issue in the past, and will be so in the future, and I am not going to defend ASF's position if it doesn't apply to everyone. I would actually like to hear from more Java-centric developers of Board and IPMC what they think about this... I've already weighed in, but here is my answer again. I have mixed feelings, as I suspect the folks who asked this question in the first place do. Our package naming requirements aren't really out of the norm. But to expect the subversion project to break backward compatibility just to graduate is a bit much. That would be like redhat insisting that all the JBoss packages be renamed from org.jboss to org.redhat. There has to be a middle ground that is acceptable and won't cause chaos with the project's customers. One solution that was mentioned was to do the rename but allow a compatibility jar with the old names. Another solution was to create a jar with the new names that refers to the existing jar. Presumably all new functionality would go there. I'm even OK with leaving as it is and creating a new jar with correct package names for new functionality and just having a concrete plan on how to do it. To me, any of these is acceptable. What I'm personally not OK with is leaving it as it is for years unless tigris.org is owned by Apache, which I'm pretty sure isn't going to happen. Ralph
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote: As I said, we do not have a hard and fast rule on length of time, but this nebulous notion is what makes the ASF work. If that were true the incubator would need to be completely reworked, because the process we use here is basically a filter on those that offer to participate- graduating projects select from their committer rosters who they'd like to carry on as committers or add to the PMC when they go top-level. And the incubator is not your typical ASF project. By design, getting the right to commit is fairly easy. It is necessary to aid projects get off the ground. The point of having a version control system in place is that we can be lax in how we dish out permissions to it *because* it's easy to fix mistakes *after* they happen. The overriding goal is to weed out people who consume more collective energy than they give back, not to bestow an honorific title on those that clear the bar. No, you have it backwards. Merit is earned and with it comes influence. You don't get it instantly and then lose it. I don't think weeding out those who consume more than they contribute as an organizing principle would work. It is certainly not the way we have been operating up to now at the ASF. You have conflated the symbols of authority with true authority- merit has nothing to do with one's committer status. Being a committer doesn't confer instant credibility any more than being a non-committer means one is clueless. If a committer doesn't know how to work productively with his/her peers, his/her work won't have any recogizable merit to those people, which in the end is what matters most. Just because someone has commit doesn't mean they have any control over the direction of a project, or even their own fate- that rests with the PMC. In every ASF community I have been involved in some amount of community participation has had to take place before being granted commit rights. No one wants to find out that a person can't work productively with his/her peers after they have been granted commit rights. This varies from community to community but never have I experienced commit rights being given without some vetting. The closest to that was Commons, which is fairly lenient for people who already have commit rights elsewhere or are a member. But even there some level of commitment has to be demonstrated. On the other hand, in these communities once granted commit rights are rarely taken away unless the person asks to become emeritus or for some fairly extreme reason - which in my experience has been rare. Some projects delay granting commit rights because they also make the person a PMC member at the same time. In others, commit rights are handed out a little more freely but PMC membership takes quite a bit more time. Each project is free to handle it in the way they feel is best for their community. In all these communities anyone who has commit access has more influence then someone who doesn't, if for no other reason than they can take a patch from a Jira issue and commit it while everyone else can't. In most projects even though a committers vote won't officially count their vote on an issue still carries more weight than someone without that right. So to claim that being granted commit rights doesn't have anything to do with one's authority is incorrect. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Dec 31, 2009, at 7:20 PM, Joe Schaefer wrote: Getting back to the subject, my primary objection to what's being proposed is that commons should handle this as an ip clearance, not as a project incubation. If commons insists that the individuals in question have to submit patches to their own work product for a while, that is a suboptimal choice but I can respect it. I disagree that it should just be about ip clearance. If the Commons PMC has a history with the committers that come with the code then they surely can judge whether those people would be good members of the community. If they don't have any track record to go on then it is unreasonable to expect them to immediately accept them. The Commons PMC doesn't even do that for Members, except to grant them commit rights to the sandbox. However, IMO it would not be unreasonable to allow the code into the sandbox and give them only commit rights to their component. However, I'm not on the Commons PMC so my opinion is just that. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Copyright issue (ESME-47)
On Jan 19, 2010, at 8:51 AM, Robert Burrell Donkin wrote: On Tue, Jan 19, 2010 at 11:10 AM, Anne Kathrine Petterøe yoji...@gmail.com wrote: PPMC and IPMC, please re-vote on the following regarding copyright issue ESME-47. snip 2. The Apache License block will be followed by a legacy comment (Only in files where the WorldWide Conferencing notice currently exists, except any files where user dpp has not made any contribution): /* * Portions Copyright 2009 WorldWide Conferencing, LLC */ ipmc-hatlegal-hatianal if this language has not been cleared with our lawyers on legal-private then : * i'm -1 on this phrasing * please raise a legal JIRA for appropriate language As others have said, this has been discussed at length on legal-discuss. The lawyers have expressed their opinion (that it mostly doesn't matter). I think requesting a Jira issue for this is a bad idea because a) it is highly unlikely that the result will be different and b) legal Jira issues aren't noted for being resolved quickly and c) Jira issues are resolved by lawyers. I suggest you review the thread that was provided and then see if you want to reconsider your veto. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Subversion podling for graduation
+1 Ralph On Feb 11, 2010, at 8:08 PM, Greg Stein wrote: Hello all, I started a discussion thread a week-ish ago to seek out issues for Subversion's graduation. The couple bits that were raised[1] have been handled, I believe. So with that said, I am unaware of any potential showstoppers, and would like to request a vote for graduating the Subversion podling. Should this result in a successful vote, I will put a resolution before the Board (for its Feb 17 mtg) to construct a new Subversion PMC. Please vote: [ ] +1 Graduation [ ] -1 Hold, and continue incubating Thanks! Cheers, -g [1] incubator status page, and java bindings package name - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] - Graduate Log4PHP as a subproject of Logging project
+1 Ralph On Mar 4, 2010, at 1:18 AM, Gav... wrote: Hi All, The Log4PHP community has voted [1] with 5 +1 votes and no other votes as follows, to graduate to become a sub-project of the Logging Project. * Gavin McDonald * Christian Hammers * Jim Jagielski * Jesus Christian (non binding) * Christian Grobmeier The Logging PMC has voted [2] with 7 +1 votes and no other votes as follows, to accept Log4PHP as a sub-project. * Ceki Gülcü * Niclas Hedhman * Curt Arnold * Scott Deboy * Paul Smith * Ron Grabowski * Christian Grobmeier The Log4PHP community feels it has fulfilled all graduation requirements to become a sub-project. This vote is to ask that the IPMC approve the graduation of Log4PHP as a sub-project of Apache Logging. The vote starts now and will run for a minimum of 72 hours. [ ] - +1 - Graduate Log4PHP as a sub-project of Apache Logging. [ ] - +/-0 - Don't care, whatever the majority decides. [ ] - -1 - Strongly object to this graduation (because ... Thanks All, Gav... [1] - Message-ID: ded132f11003032357v5f4edbb2k7579ffbb3be22...@mail.gmail.com [2] - Message-ID: ded132f11003032352h5d11607ene1811d34b9670...@mail.gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Termination of WSRP4J podling
+1 Ralph On Apr 13, 2010, at 5:37 PM, Ate Douma wrote: The Portals PMC as Sponsor of the WSRP4J podling as well as the project community itself has voted [1,2] positive [3] to terminate the podling due to lack of interest to continue the project. I would like to call the Incubator PMC to ratify this decision. Please vote on terminating the WSRP4J podling: [ ] +1, terminate WSRP4J [ ] -1, do not terminate WSRP4J Here's my +1 Regards, Ate [1] http://mail-archives.apache.org/mod_mbox/portals-general/201004.mbox/%3c4bbe524b.4090...@douma.nu%3e [2] http://mail-archives.apache.org/mod_mbox/portals-wsrp4j-user/201004.mbox/%3c4bbe524b.4090...@douma.nu%3e [3] http://mail-archives.apache.org/mod_mbox/portals-general/201004.mbox/%3c4bc500fa.6060...@douma.nu%3e - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New project proposal
This project is definitely of interest to me as my employer does Saas via multi-tenancy (in our case multi-tenacny means all the clients share the same code deployment, not the way it is described at wikipedia). Ralph On Jul 14, 2010, at 1:37 AM, Grégoire Rolland wrote: Hi Otis and all others, I will list here current and planned functionality of jSpirit. * Architecture - Multi-tiered Architecture out-of-the-box : Implementation of Integration Layer, Business Layer, Client Layer - Java 5 annotation and auto-injection based lookup of services - Classpath scanning for auto-discovering components - Modular and plugable architecture : automatic activation of modules in the classpath, ready for seamless integration - Implementation of Long-Conversation pattern, with JTA 2PC support (with Geronimo Transaction Manager), and implicit demarcation (explicit demarcation is always possible) - [in progress] AOP interceptor on top of each layer * Integration Layer - Implementation of abstract integration services and abstract persister based on JPA technology - Maven plugins for code generation of integration layer from xml description of component business model : generate persistent class, access services, queries, constraints, JPA annotation, lucene indexation of business model - bean validation integration - Full Multi-tenancy integration on EntityManager and Caches - Multi-tenant Postgresql support - [Planned] Maven Plugin for code generation supporting Apache Cassandra without interface modification * Business Layer - Implementation of abstract business services and infrastructure - Annotation discovering and injection of dependents services - Multi-tenant replacement of services at runtime - Simple Asynchronous and distributed business services with Apache ActiveMQ : this is annotation driven * Client Layer - JSF 2.0 predefined integration - Abstract Managed Bean for simple developpement of list and forms - Integration of restful url for JSF 2 - Multi-tenant interceptor for determining tenant context based on full qualified domain name - [Planned] Make others interceptor based on other methods * Scheduling - Distributed and load adaptative voting peer-to-peer scheduler - voting task execution with Condorcet Method - [Planned] support others algorithms for scheduling * Security - Simple security integration : form login, http basic security - Multi-tenant support for authentications and authorizations - peer-to-peer sessions id replications for support max session per user in a cluster - Regexp filters on urls - [Planned] Services Access Authorization - JSF function and bean to manage security on pages * i18n - Full i18n support - Multi-tenacy i18n : overriding label per tenant - JSF function for accessing labels and locale - JSF bean for controlling user locale on web page *Data Import/Export - XML data importer/exporter customizable by tenant with scripting services - ready for open-SaaS to guarantee application users data integration and recuperation * Web Services --- - Simple export of business services to Soap Web Services with Apache CXF - [in progress] REstfull web services with Apache Abdera integration (and XStream) - Atom 1.0 support with Apache Abdera (only GET method now) * Search --- - Indexation of data model - Simple Query interface for searching in the data model - Multi-tenant support of the Lucene Indexes * JCR --- - Multi-tenant integration of Apache JackRabbit : workspaces based - Implementation of injectable service for JackRabbit access - JTA transaction participation * Mail -- - Injectable mail services out-of-box * Reporting -- - Report module on top of the business layer - based on Castor XML and Apache FOP - Pluggable Reporting Provider architecture - Multi-tenant report replacement at runtime * Tools - Set of Maven archetype mapped on architecture to create one project by layer - [planned] eclipse plugins for MDA enablement, XML schema recognition, * Planned functionnality - Integration of Business Rules Engine with multi-tenancy -
Re: New project proposal
How much of the code at sourceforge represents what you have listed below? In other words, how much of this is currently implemented? Ralph On Jul 14, 2010, at 9:03 AM, Grégoire Rolland wrote: Hi Ralph, Multi-tenancy in jSpirit is as you describe, plus the ability to replace business service implementation per tenant. Thanks for your interest. Grégoire Le 14/07/2010 17:06, Ralph Goers a écrit : This project is definitely of interest to me as my employer does Saas via multi-tenancy (in our case multi-tenacny means all the clients share the same code deployment, not the way it is described at wikipedia). Ralph On Jul 14, 2010, at 1:37 AM, Grégoire Rolland wrote: Hi Otis and all others, I will list here current and planned functionality of jSpirit. * Architecture - Multi-tiered Architecture out-of-the-box : Implementation of Integration Layer, Business Layer, Client Layer - Java 5 annotation and auto-injection based lookup of services - Classpath scanning for auto-discovering components - Modular and plugable architecture : automatic activation of modules in the classpath, ready for seamless integration - Implementation of Long-Conversation pattern, with JTA 2PC support (with Geronimo Transaction Manager), and implicit demarcation (explicit demarcation is always possible) - [in progress] AOP interceptor on top of each layer * Integration Layer - Implementation of abstract integration services and abstract persister based on JPA technology - Maven plugins for code generation of integration layer from xml description of component business model : generate persistent class, access services, queries, constraints, JPA annotation, lucene indexation of business model - bean validation integration - Full Multi-tenancy integration on EntityManager and Caches - Multi-tenant Postgresql support - [Planned] Maven Plugin for code generation supporting Apache Cassandra without interface modification * Business Layer - Implementation of abstract business services and infrastructure - Annotation discovering and injection of dependents services - Multi-tenant replacement of services at runtime - Simple Asynchronous and distributed business services with Apache ActiveMQ : this is annotation driven * Client Layer - JSF 2.0 predefined integration - Abstract Managed Bean for simple developpement of list and forms - Integration of restful url for JSF 2 - Multi-tenant interceptor for determining tenant context based on full qualified domain name - [Planned] Make others interceptor based on other methods * Scheduling - Distributed and load adaptative voting peer-to-peer scheduler - voting task execution with Condorcet Method - [Planned] support others algorithms for scheduling * Security - Simple security integration : form login, http basic security - Multi-tenant support for authentications and authorizations - peer-to-peer sessions id replications for support max session per user in a cluster - Regexp filters on urls - [Planned] Services Access Authorization - JSF function and bean to manage security on pages * i18n - Full i18n support - Multi-tenacy i18n : overriding label per tenant - JSF function for accessing labels and locale - JSF bean for controlling user locale on web page *Data Import/Export - XML data importer/exporter customizable by tenant with scripting services - ready for open-SaaS to guarantee application users data integration and recuperation * Web Services --- - Simple export of business services to Soap Web Services with Apache CXF - [in progress] REstfull web services with Apache Abdera integration (and XStream) - Atom 1.0 support with Apache Abdera (only GET method now) * Search --- - Indexation of data model - Simple Query interface for searching in the data model - Multi-tenant support of the Lucene Indexes * JCR --- - Multi-tenant integration of Apache JackRabbit : workspaces based - Implementation of injectable service for JackRabbit access - JTA transaction participation * Mail -- - Injectable mail services out-of-box * Reporting -- - Report module on top of the business layer - based on Castor XML and Apache FOP - Pluggable Reporting
Re: New project proposal
I will try to find some time this weekend to take a look at what is available on sourceforge. I am incredibly busy at work and don't find as much time as I would like to participate on the projects I am already involved in. But if I like what I see I might try to see if I can get some of my colleagues to participate. Ralph On Jul 16, 2010, at 7:59 AM, Grégoire Rolland wrote: Hi Ralph, I'm just posting the proposal of jSpirit Project, could I add you as Interrested developper ? Regards, Gregoire On 14/07/2010 23:37, Ralph Goers wrote: How much of the code at sourceforge represents what you have listed below? In other words, how much of this is currently implemented? Ralph On Jul 14, 2010, at 9:03 AM, Grégoire Rolland wrote: Hi Ralph, Multi-tenancy in jSpirit is as you describe, plus the ability to replace business service implementation per tenant. Thanks for your interest. Grégoire Le 14/07/2010 17:06, Ralph Goers a écrit : This project is definitely of interest to me as my employer does Saas via multi-tenancy (in our case multi-tenacny means all the clients share the same code deployment, not the way it is described at wikipedia). Ralph On Jul 14, 2010, at 1:37 AM, Grégoire Rolland wrote: Hi Otis and all others, I will list here current and planned functionality of jSpirit. * Architecture - Multi-tiered Architecture out-of-the-box : Implementation of Integration Layer, Business Layer, Client Layer - Java 5 annotation and auto-injection based lookup of services - Classpath scanning for auto-discovering components - Modular and plugable architecture : automatic activation of modules in the classpath, ready for seamless integration - Implementation of Long-Conversation pattern, with JTA 2PC support (with Geronimo Transaction Manager), and implicit demarcation (explicit demarcation is always possible) - [in progress] AOP interceptor on top of each layer * Integration Layer - Implementation of abstract integration services and abstract persister based on JPA technology - Maven plugins for code generation of integration layer from xml description of component business model : generate persistent class, access services, queries, constraints, JPA annotation, lucene indexation of business model - bean validation integration - Full Multi-tenancy integration on EntityManager and Caches - Multi-tenant Postgresql support - [Planned] Maven Plugin for code generation supporting Apache Cassandra without interface modification * Business Layer - Implementation of abstract business services and infrastructure - Annotation discovering and injection of dependents services - Multi-tenant replacement of services at runtime - Simple Asynchronous and distributed business services with Apache ActiveMQ : this is annotation driven * Client Layer - JSF 2.0 predefined integration - Abstract Managed Bean for simple developpement of list and forms - Integration of restful url for JSF 2 - Multi-tenant interceptor for determining tenant context based on full qualified domain name - [Planned] Make others interceptor based on other methods * Scheduling - Distributed and load adaptative voting peer-to-peer scheduler - voting task execution with Condorcet Method - [Planned] support others algorithms for scheduling * Security - Simple security integration : form login, http basic security - Multi-tenant support for authentications and authorizations - peer-to-peer sessions id replications for support max session per user in a cluster - Regexp filters on urls - [Planned] Services Access Authorization - JSF function and bean to manage security on pages * i18n - Full i18n support - Multi-tenacy i18n : overriding label per tenant - JSF function for accessing labels and locale - JSF bean for controlling user locale on web page *Data Import/Export - XML data importer/exporter customizable by tenant with scripting services - ready for open-SaaS to guarantee application users data integration and recuperation * Web Services --- - Simple export of business services to Soap Web Services with Apache CXF - [in progress] REstfull web services with Apache Abdera integration (and XStream) - Atom 1.0 support with Apache Abdera (only GET method now) * Search --- - Indexation of data model - Simple Query
Re: Subversion full/partial committer (was: Re: an experiment)
On Aug 18, 2010, at 5:19 PM, Greg Stein wrote: identifying the project with the ASF. Similarly on many occasions we have asked projects to pick a new name as part of the incubation process. We have made exceptions for well established brands (ServiceMix ActiveMQ were the first I remember but there probably were others) and so we do have precedent for that (and I *totally* agree changing the name would accomplish nothing here). IIRC even ServiceMix and ActiveMQ changed their package names to org.apache.*. It seems somewhere that we disconnected from some conceptual terminology into an area of product/package naming. This seems really simple to me. If I move from Korea to the United States I'd better start learning to speak English if I want to interact with the population at large. If I just want to stay within my little Korean community then I can continue to speak my native language all that I want. Even an American living in the south needs to learn proper English if they want to run for a national office and be effective. That said, American English is constantly evolving. If the ASF as a whole wants to adopt terms like Full Committer and Partial Committer than I'd expect to see a definition somewhere. As it stands, I must have missed the email where they were defined. Without that context I'm left to assume a Partial Committer is somehow handicapped or missing a few body parts, or a Full Committer is someone like me with a little too much weight on their torso. The cost here is that a decently large project integrated with a larger organization and in doing so simply needs to be able to communicate effectively. That means a) getting the organization to recognize and accept the different terminology being used or b) stop using that terminology when speaking to the larger audience. Option a isn't accomplished by simply using the terminology and expecting everyone else to conform. Ralph
Re: Subversion full/partial committer (was: Re: an experiment)
On Aug 19, 2010, at 11:25 AM, Greg Stein wrote: ** Community Since our last report, in May, we have added two more committers. These are partial committers, meaning they are restricted to certain portions of the tree. The first, artagnon, is a GSoC student for Git(!) and is adding a new svnrdump client-side tool to produce or load Subversion dump files remotely (eg. for fast-loading into Git). The second, stefan2, is working on a branch with a broad set of performance improvements across the system. No new PMC Members (full committers) have been added. As you can see, we aren't trying to foist new terminology on anybody. I continue to believe that the terminology used in our report is fine. The Board showed no concern during the meeting. This ruckus seems quite overblown. Cheers, -g This seems fair enough. In practice what you are doing is not much different than commons restricting committers to the sandbox, or when I got access to logging I was restricted to Log4j 2.0, not the current trunk. so I have no problem with the practice of granting restricted or partial access. I've just never seen the term partial committer before and certainly never used full committer to be analogous to a PMC member. Cocoon follows the same practice of making someone a PMC member when they are offered commit access, but we have still always announced them as a new committer and then invited them to also be on the PMC. We've also run into a couple of cases where we invited someone to be on the PMC due to their contribution to the community but they didn't really need commit access. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Nov 23, 2010, at 12:16 PM, Dan Peterson wrote: Hello all, We'd like to propose Wave for entry into the ASF incubator. Did Google have any trademarks on Wave and are they allowing them to be transferred to the ASF? Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Nov 23, 2010, at 3:57 PM, Leif Hedstrom wrote: On 11/23/2010 04:44 PM, Ralph Goers wrote: On Nov 23, 2010, at 12:16 PM, Dan Peterson wrote: Hello all, We'd like to propose Wave for entry into the ASF incubator. Did Google have any trademarks on Wave and are they allowing them to be transferred to the ASF? Certainly looks like they do have a trademark on Google Wave, I don't know if that affects this project though, since as far as I can tell, it's changing names to Wave in a Box ? The proposal says the project is Apache Wave and the main product is Wave in a Box. In either case, it would be good to get confirmation that Google is giving up the rights to Wave. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Nov 23, 2010, at 6:06 PM, Greg Stein wrote: On Tue, Nov 23, 2010 at 20:47, Ralph Goers ralph.go...@dslextreme.com wrote: ... OK - Have they explicitly OK'd Apache Wave? While Apache Wave would certainly be unique to Apache, if Google intends to keep using Google Wave (and Wave as a shorthand) this would get very confusing. Don't you think that by proposing Wave to the Incubator that Google has OK'd this? I don't work for Google and don't know the people proposing this so no, I have no idea whether Google has OK'd this. This is no different than someone taking an Apache project out of the Attic and starting it somewhere else using the same name without Apache on the front. IIRC we don't allow that. I don't think this is paranoia but just approaching this from the same set of rules that we use for our own projects. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
Thanks. That answers my only concern. I think this would be a great addition. Sent from my iPhone On Nov 23, 2010, at 7:56 PM, Soren Lassen so...@google.com wrote: I work for Google and I speak on the behalf of the Google Wave team. I can assure you that Google supports the Apache Wave proposal. We always wanted to transfer ownership of the open source code to the developer community and, with the discontinuation of development of Google Wave as a standalone product, we accelerated our efforts to spin this out in order to bring certainty to the developer community. Apache Wave should stand on its own without concern for Google's product strategies or priorities. Nonetheless, please note that Google is looking at ways to continue and extend wave technology in other Google products, specifically ways for users to access waves through Google Docs. But Google only retains the rights to the trademark GOOGLE WAVE and the wave design logo. Hopefully, Google will become one of many happy customers of Apache Wave. Soren On Wed, Nov 24, 2010 at 2:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On Nov 23, 2010, at 6:06 PM, Greg Stein wrote: On Tue, Nov 23, 2010 at 20:47, Ralph Goers ralph.go...@dslextreme.com wrote: ... OK - Have they explicitly OK'd Apache Wave? While Apache Wave would certainly be unique to Apache, if Google intends to keep using Google Wave (and Wave as a shorthand) this would get very confusing. Don't you think that by proposing Wave to the Incubator that Google has OK'd this? I don't work for Google and don't know the people proposing this so no, I have no idea whether Google has OK'd this. This is no different than someone taking an Apache project out of the Attic and starting it somewhere else using the same name without Apache on the front. IIRC we don't allow that. I don't think this is paranoia but just approaching this from the same set of rules that we use for our own projects. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Nov 26, 2010, at 7:05 AM, Joe Schaefer wrote: - Original Message From: Tad Glines tad.gli...@gmail.com To: general@incubator.apache.org Sent: Fri, November 26, 2010 9:47:33 AM Subject: Re: [PROPOSAL] Accept Wave for incubation The word Wave is far more generic than TrafficServer, Lucene or Hadoop. When I did a search through the trademark database I found 62 trademarks on the word wave. There are others that contain the word wave one of which is Google's Google Wave trademark. While I am neither a lawyer nor a trademark expert, it seems logical to conclude that given the many Wave trademarks and the fact that Google was granted a Google Wave trademark that Apache would have no problem obtaining a trademark on Apache Wave if they wished to. I think it's also fairly safe to conclude that Google is never going to assign a trademark with the word Google in it to another entity. If Google had a trademark on the plain word Wave in the communication/collaboration space, then I would expect that to be a problem. But, since they don't, I don't think this is an issue. Perhaps Google could issue some sort of official We promise not to sue Apache Foundation over the use of the name 'Apache Wave' just to make everyone happy. Welcome to the Incubator. Yes trademarks are taken seriously, and yes you've made some good points that the situation with Wave is relatively unique. While these sorts of discussions can be frustrating and annoying at times, everyone here at Apache is basically just trying to be fair to both all ASF projects and past incubation efforts, and somewhat consistent in what we tell others about Incubation. Different people have different perspectives and they are able to openly disagree without disrupting progress. Happens all the time here. FWIW I can easily foresee the Incubator accepting this proposal as written and kicking around the trademark issue for a while longer post acceptance. This is just how we work. Personally I'd be fine with an Apache Wave project graduating from the incubator, even without asking Google to abandon its interest in the Google Wave trademark (just as we haven't asked NCSU to abandon its interest in VCL). We just want to avoid any potential confusion about the marks and the software they refer to. If we need a legal opinion from the org about the propriety of that solution I'd be happy to go fetch one, but for now let's please just move on to any other remaining issues with the proposal. I completely agree with everything you said. Furthermore, I am quite satisfied based on the responses I got to my questions that Google has already given us permission to use Apache Wave. The real question is whether the ASF is comfortable in having a project with that name. For example, since Google is retaining the rights to Google Wave they could at any time ship a version of Apache Wave under that name - which, I believe, is something not currently allowed for any other ASF project. OTOH, Wave in a Box (or WIAB) sounds like it is probably quite unique. Personally, I am torn between being consistent and the fact that a project named Apache Wave is going to have instant market appeal. But a decision on what the formal project name will be should not preclude entrance to the incubator. However, the project participants should be aware that there is likely to be more discussion on the issue. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Wave into the incubator
On Nov 29, 2010, at 10:52 PM, Dan Peterson wrote: Hi everyone, Please vote on the acceptance of Wave into the Apache incubator. The proposal is available at: http://wiki.apache.org/incubator/WaveProposal (for your convenience, a snapshot is also copied below) The earlier discussion thread can be found at: http://apache.markmail.org/message/3ebtccdxvipp2732?q=general%40incubator.apache.org+list:org.apache.incubator.general+order:date-backwardpage=2 The vote options: [ ] +1 Accept Wave for incubation [ ] +0 Don't care [ ] -1 Reject for the following reason: +1 Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULTS][VOTE] Wave accepted into the ASF incubator
On Dec 4, 2010, at 4:39 AM, Ian Boston wrote: On 4 Dec 2010, at 01:50, Tad Glines wrote: 2010/12/3 Dan Peterson dpeter...@google.com The 18 binding votes: Andrus Adamchik, Ant Elder, Bernd Fondermann, Bertrand Delacretaz, Chris A. Mattmann, Christian Grobmeier, Davanum Srinivas, Dave Johnson, Doug Cutting, Emmanuel Lecharny, Jim Jagielski, Kevan Miller, Luciano Resende, Mark Struberg, Michael McCandless, Ralph Goers, Tim Williams, and Upayavira The 8 non-IMPC members who are ASF members: Ate Douma, Brett Porter, Leif Hedstrom, Marcel Offermans, Niklas Gustavsson, Richard Hall, Santiago Gala, and Vincent Siveton Wow! Did we set some sort of record? I didn't realize that so many ASF people had voted. Congrats lots of support from all corners. Just incase it is a record, long may it stand but it may be even more than that, I see Paul Lindner name in the list of non members, I thought as Shindig PMC Chair he was a member, with me that makes 10, there may be others. ? (well done, I thought it was painful counting just ten on a release votes) PMC chairs are not automatically ASF members. The easy way to tell is to look at http://people.apache.org/committer-index.html. If the person's name is in bold then they are an ASF member. It appears Paul is not. Ralph
Re: [RESULTS][VOTE] Wave accepted into the ASF incubator
On Dec 4, 2010, at 8:50 AM, Ralph Goers wrote: On Dec 4, 2010, at 4:39 AM, Ian Boston wrote: On 4 Dec 2010, at 01:50, Tad Glines wrote: 2010/12/3 Dan Peterson dpeter...@google.com The 18 binding votes: Andrus Adamchik, Ant Elder, Bernd Fondermann, Bertrand Delacretaz, Chris A. Mattmann, Christian Grobmeier, Davanum Srinivas, Dave Johnson, Doug Cutting, Emmanuel Lecharny, Jim Jagielski, Kevan Miller, Luciano Resende, Mark Struberg, Michael McCandless, Ralph Goers, Tim Williams, and Upayavira The 8 non-IMPC members who are ASF members: Ate Douma, Brett Porter, Leif Hedstrom, Marcel Offermans, Niklas Gustavsson, Richard Hall, Santiago Gala, and Vincent Siveton Wow! Did we set some sort of record? I didn't realize that so many ASF people had voted. Congrats lots of support from all corners. Just incase it is a record, long may it stand but it may be even more than that, I see Paul Lindner name in the list of non members, I thought as Shindig PMC Chair he was a member, with me that makes 10, there may be others. ? (well done, I thought it was painful counting just ten on a release votes) PMC chairs are not automatically ASF members. The easy way to tell is to look at http://people.apache.org/committer-index.html. If the person's name is in bold then they are an ASF member. It appears Paul is not. However, I do see Isabel Drost, who is a member, in the list. So your assertion that there are probably more is correct. Ralph
Re: Wave Incubator Next Steps
On Dec 4, 2010, at 9:13 AM, Tad Glines wrote: On Sat, Dec 4, 2010 at 8:39 AM, Leif Hedstrom zw...@apache.org wrote: On 12/04/2010 09:22 AM, Tad Glines wrote: Also, committers will not be issued accounts until their CLA (either ICLA or CCLA) has been received and recorded. Here's the new committers guide: http://www.apache.org/dev/new-committers-guide.html. I'm fairly certain all committers needs to fill out the ICLA, no? Yes, I see. Reading this http://www.apache.org/licenses/#clas further I see that all have to sign an ICLA, but for some their employer will need to submit a CCLA. It is usually the case that some will want their employer to submit a CCLA rather than need to. The ICLA is the way an individual states that they have the right to commit the software they contribute. If during the course of their employment they are called upon to enhance or fix bugs in an Apache project the ICLA is sufficient for them to do that provided they have permission to do so from their employer. The CCLA protects the individual in that case by explicitly stating the listed individuals have that right. The CCLA is also one way a company can donate software directly to the ASF. There are quite a few companies that don't want to submit a CCLA but will allow their employees to contribute. In those cases it is up to the individual to make sure they are protected should management changes occur, etc. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wave Incubator Next Steps
On Dec 4, 2010, at 2:35 PM, Michael MacFadden wrote: Ralph, If I understand correctly, an individual could submit an ICLA first and then later submit the CCLA if the employer or situation requires it. Meaning that previously submitting an ICLA would not be in conflict with a subsequent CCLA. If that is the case I would recommend all of the initial committees for Wave get those in as soon as possible. Thanks. That is correct. Wave Committers should submit their ICLAs as soon as possible. They cannot be given access to svn until that is done. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ManifoldCF 0.1
On Jan 8, 2011, at 7:24 AM, Karl Wright wrote: I've made the 2011 change already. But I'm having trouble reconciling your instructions with this part of the Apache license: (d) If the Work includes a NOTICE text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. To the best of my knowledge, both remaining proposed NOTICE clauses come from a NOTICE file or the equivalent in the source work. The meaning of Derivative Work is obviously what the question is - does inclusion imply derivation? Because, we are including it. The confusion is understandable. The Free Software Foundation's definition of derivative work would probably apply to anything that is included to create the larger work. We aren't the Free Software Foundation. IAround here you will find the definition of derivative work to mean that you have taken the original work and made changes to it - regardless of any other code that might use the included work. So if you are just including a jar and using the interfaces it exposes then yours is not a derivative work of the first. At the beginning of the Apache License you will find the definition of derivative work Derivative Works shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
Re: [VOTE] Accept Howl as an Incubator Project
+1 Ralph On Feb 22, 2011, at 4:20 PM, Alan Gates wrote: I would like to call a vote on accepting Howl as an Incubator project. The proposal is available at http://wiki.apache.org/incubator/HowlProposal. You can see the discussion from the proposal thread at http://tinyurl.com/5w7y9p9. Alan. -- Abstract Howl is a table and storage management service for data created using Apache Hadoop. Proposal The vision of Howl is to provide table management and storage management layers for Apache Hadoop. This includes: • Providing a shared schema and data type mechanism. • Providing a table abstraction so that users need not be concerned with where or how their data is stored. • Providing interoperability across data processing tools such as Pig, Map Reduce, Streaming, and Hive. Background Data processors using Apache Hadoop have a common need for table management services. The goal of a table management service is to track data that exists in a Hadoop grid and present that data to users in a tabular format. Such a table management service needs to provide a single input and output format to users so that individual users need not be concerned with the storage formats that are chosen for particular data sets. As part of having a single format, the data will need to be described by one type of schema and have a single datatype system. Additionally, users should be free to choose the best tools for their use cases. The Hadoop project includes Map Reduce, Streaming, Pig, and Hive, and additional tools exist such as Cascading. Each of these tools has users who prefer it, and there are use cases best addressed by each of these tools. Two users on the same grid who need to share data should not be constrained to use the same tool but rather should be free to choose the best tool for their use case. A table management service that presents data in the same way to all of the tools can alleviate this problem by providing interfaces to each of the data processing tools. There are also a few other features a table management service should provide, such as notification of when data arrives. A couple of developers at Yahoo! started the project. It is based on the Hive MetaStore component. There is good amount of interest in such a service expressed from Yahoo!, Facebook, LinkedIn, and, others. We are therefore proposing to place Howl in the Apache incubator and to build an open source community around it. Rationale There is a strong need for a table management service, especially for large grids with petabytes of data, and where the data volume is increasing by the day. Hadoop users need to find data to read and have a place to store their data. Currently users must understand the location of data to read, the storage format, compression techniques used, etc. To write data they need to understand where on HDFS their data belongs, the best compression format to use, how their data should be serialized, etc. Most users do not want to be concerned with these issues. They want these managed for them. Having it as an Apache Open Source project will highly benefit Howl from the point of view of getting a large community that currently uses Hadoop and the other products built around Hadoop (like Pig, Hive, etc.). Users of the Hadoop ecosystem can influence Howl’s roadmap, and contribute to it. Looking at it in another way, we believe having Howl as part of the Hadoop ecosystem will be a great benefit to the current Hadoop/Pig/Hive community too. Current Status Meritocracy Our intent with this incubator proposal is to start building a diverse developer community around Howl following the Apache meritocracy model. We have wanted to make the project open source and encourage contributors from multiple organizations from the start. We plan to provide plenty of support to new developers and to quickly recruit those who make solid contributions to committer status. Community Howl is currently being used by developers at Yahoo! and there has been an expressed interest from LinkedIn and Facebook. Yahoo! also plans to deploy the current version of Howl in production soon. We hope to extend the user and developer base further in the future. The current developers and users are all interested in building a solid open source community around Howl. To work towards an open source community, we have started using the GitHub issue tracker and mailing lists at Yahoo! for development discussions within our group. Core Developers Howl is currently being developed by four engineers from Yahoo! - Devaraj Das, Ashutosh Chauhan, Sushanth Sowmyan, and Mac Yang. All the engineers have deep expertise in Hadoop and the Hadoop Ecosystem in general. Alignment The ASF is a natural host for Howl given that it is already the home of Hadoop, Pig,
Re: [VOTE] Accept Rave into the Incubator
+1 Ralph On Feb 24, 2011, at 4:08 PM, Ate Douma wrote: Given the feedback received so far I think the Rave proposal is in good shape so I'd like to bring up the vote for accepting Rave into the Incubator. The proposal is at: http://wiki.apache.org/incubator/RaveProposal and also copied as text below. Please vote. [ ] +1 Accept Rave into the incubator [ ] +0 Don't care' [ ] -1 Reject for the following reason: I'll close the vote at Tuesday morning 1st March CET to accommodate for the coming weekend. That's a little over 5 days from now. Regards, Ate - COPY OF PROPOSAL FROM http://wiki.apache.org/incubator/RaveProposal - = Apache Rave Proposal = == Abstract == Apache Rave is A new WEb And SOcial Mashup Engine. It will provide an out-of-the-box as well as an extendible lightweight Java platform to host, serve and aggregate (Open)Social Gadgets and services through a highly customizable and Web 2.0 friendly front-end. Rave is targeted as engine for internet and intranet portals and as building block to provide context-aware personalization and collaboration features for multi-site/multi-channel (mobile) oriented and content driven websites and (social) network oriented services and platforms. For the [[http://www.opensocial.org/|OpenSocial]] container and services the (Java) [[http://shindig.apache.org|Apache Shindig]] will be integrated. At a later stage further generalization is envisioned to also transparently support [[http://www.w3.org/TR/widgets/|W3C Widgets]] using [[http://incubator.apache.org/wookie/|Apache Wookie]]. == Proposal == The reason for starting Rave is to bring together and combine several existing projects and teams currently working towards more or less the same or overlapping goals but each in their own small(er) target audience and community. The goal for Rave is to become a lightweight and open-standards based extendible platform for using, integrating and hosting !OpenSocial and W3C Widget related features, technologies and services. It will also provide strong context-aware personalization, collaboration and content integration capabilities and a high quality out-of-the-box installation as well as be easy to integrate in other platforms and solutions. The initial features for Rave will at least be based on the current capabilities from the contributing external projects, for which they will provide the necessary code contributions. However, the code base for Rave will be built anew with strong focus on generalization, customization and extendibility to support the intended multi-purpose adoption and integration. The contributing external projects will start using and switch to the new Rave based solution as soon as the initial features become available to ensure the continued participation and interest from their side as well as their own communities. The intended initial features include: '''Core Features''' 1. Advanced !OpenSocial compliance and optional features support 1. !OpenSocial persistence and SPI (Service Provider Interface) implementation 1. Self-service application administration including security, gadget management and page templates 1. User and group management with full privacy model 1. Gadget repository with life-cycle management (install/update/remove) and extended meta data (categories, comments, ratings, etc.) 1. Dynamic and highly customizable front-end engine (skins, pages, tabs, layouts, navigation) 1. Full OAuth support 1. Support for security restrictions on both Gadgets and page/tag/layout customizations 1. Set of common and general purpose Gadgets to be usable out-of-the-box 1. Support for inter-gadget messaging with examples '''Extensible Features''' 1. Pluggable persistence 1. Pluggable security model with example modules for authentication and authorization 1. Support for !OpenSocial extensions not (yet) defined in the specification 1. Support for other (non-standard, yet) pluggable container services and extensions Beyond these initial features the vision and scope for Rave goes much further and includes integrating and providing other highly desired/needed features like: * native W3C Widgets support through [[http://incubator.apache.org/wookie|Apache Wookie]] * pluggable and extendible content integration and management services * space extensions and management features, like http://wiki.opensocial.org/index.php?title=Space_extension * context aware features and extensions integration for personalized and social network and (mobile) device oriented sites and channels * enhanced client-side widget messaging, coordination and co-location support like using [[http://www.openajax.org|OpenAjax]] Hub and Registry * space, page and Gadget based linking, navigation, coordination and collaboration * inline widget rendering, like
Re: [VOTE] Accept Howl as an Incubator Project
On Mar 8, 2011, at 12:01 PM, Alex Karasulu wrote: Hi Alan, On Tue, Mar 8, 2011 at 8:26 PM, Alan Gates ga...@yahoo-inc.com wrote: We are taking it seriously. We (Howl mentors and committers) discussed this and the consensus seemed to be we wanted to stay with the name if possible. The feedback on this list was mixed, with many for changing it and some not worried about it. So we wanted to stick with it for now and see how it went. I'm not here to create a problem for y'all. Keep in mind I +1'd the proposal even though I had some reservations about all of you being Yahoo'ers. You can work on that in the incubator - no problem to diversify while incubating. I think the majority of those voting +1 for incubation wanted the name changed based on the concerns that were raised. I would be concerned about a release being done as howl while in the incubator and would certainly vote -1 to leaving it unless a) it is definitely determined that no trademark conflicts exist (this may require contacting the other parties and getting their permission) or b) the name is changed to something that doesn't have similar conflicts. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache OGNL
I don't recall the Commons PMC saying the project needs to be renamed when it voted to sponsor this project. If that is necessary I'm sure they will let the project know. Ralph On Apr 8, 2011, at 6:37 AM, Martin Cooper wrote: On Fri, Apr 8, 2011 at 12:57 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I'm sorry that I can't help out but when reading this I thought that using the spec name as the project name is probably not ideal. How about calling it Apache (Commons) Ogranal? Hopefully, this doesn't have any strange meaning in some language. Just a thought. Commons has a policy of using descriptive names. Yes, there are a few existing projects that don't fit this - ones that were grandfathered in when the policy was introduced - but it would be better to start incubation with a name that would meet Commons' criteria rather than one that will need changing yet again on graduation. A lot of people both within and outwith the ASF know the name OGNL, so unless there's a pressing need, it would make sense to keep it. -- Martin Cooper On 08.04.2011 09:26:43 Simone Tripodi wrote: Hi all guys, I'm almost ready to submit a new proposal I'm preparing on Wiki[1] for Apache OGNL. The idea is importing the OGNL project under the Apache umbrella and, once/if ready, be promoted in Apache Commons - the Commons PMC already voted to be the Sponsor. All legal issues have been resolved, we have the Champion - Lukasz Lenart - and a great Mentor - Olivier Lamy - what we miss are 2 more mentors... any volunteer? :) It would be nice also if you can provide your feedbacks, once raw the proposal. Many thanks in advance, have a nice day!!! Simo [1] http://wiki.apache.org/incubator/OGNLProposal http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][PROPOSAL] OGNL join the Incubator
+1 binding Ralph On Apr 23, 2011, at 4:57 AM, Simone Tripodi wrote: Hi all ASF mates, I'm writing to submit a new incubator proposal, Apache OGNL. Follows below the proposal; this vote will be open for 72 hours and will be closed on April 26th (Tue) at 12:00 am CET. Many thanks in advance to everyone will take pat to the vote! Have a nice weekend, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Apache OGNL Abstract The following proposal is about Apache OGNL, a Java development framework for Object-Graph Navigation Language, plus other extras such as list projection[1], selection[2] and lambda expressions[3]. Proposal OGNL started out as a way to set up associations between UI components and controllers using property names. As the desire for more complicated associations grew, Drew Davidson created what he called KVCL, for Key-Value Coding Language, egged on by Luke Blanshard. Luke then reimplemented the language using ANTLR, came up with the new name, and, egged on by Drew, filled it out to its current state. Later on Luke again reimplemented the language using JavaCC. Further maintenance on all the code is done by Drew (with spiritual guidance from Luke). Today OGNL is maintained by Lukasz Lenart. Background OGNL is a long living project born in the 1997 thanks to Drew Davidson initial effort, moved under the OpenSymphony[4] umbrella in June 2005 or thereabouts, then moved on its own domain on ognl.org[5] that's no more maintained, then finally found place on GitHub[6], maintained by Lukasz Lenart. Rationale OGNL stands for Object Graph Navigation Language. It is an expression and binding language for getting and setting properties of Java objects. Normally the same expression is used for both getting and setting the value of a property. Many people have asked exactly what OGNL is good for. Several of the uses to which OGNL has been applied are: * A binding language between GUI elements (textfield, combobox, etc.) to model objects. Transformations are made easier by OGNL's TypeConverter mechanism to convert values from one type to another (String to numeric types, for example). * A data source language to map between table columns and a Swing TableModel. * A binding language between web components and the underlying model objects (WebOGNL, Tapestry, WebWork, WebObjects). * A more expressive replacement for the property-getting language used by the Apache Commons BeanUtils package or JSTL's EL (which only allow simple property navigation and rudimentary indexed properties). Most of what you can do in Java is possible in OGNL, plus other extras such as list projection and selection and lambda expressions. Current Status Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Core Developers In alphabetical order: * Antonio Petrelli apetrelli at apache dot org * Christian Grobmeier grobmeier at apache dot org * Jesse Kuhnert jkuhnert at apache dot org * Jochen Wiedmann jochen at apache dot org * Lukasz Lenart lukaszlenart at apache dot org * Olivier Lamy olamy at apache dot org * Marc Andrew Davidson drewd at apple dot com * Maurizio Cucchiara mcucchiara at apache dot org * Simone Tripodi simonetripodi at apache dot org * Upayavira upayavira at apache dot org Alignment The purpose of the project is to develop and maintain OGNL implementation that can be used by other Apache projects. Known Risks Orphaned Products Being OGNL widely adopted we believe there is minimal risks of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Moreover, OGNL has been already used by the following projects for years: * Apache Struts; * Apache Tapestry; * Apache Camel; * Apache Tiles; * MyBatis (formerly Apache iBATIS); * Spring WebFlow. Inexperience with Open Source All of the committers have experience working in one or more open source projects inside and outside ASF. Homogeneous Developers The list of initial committers are geographically distributed across the USA and Europe with no one company being associated with a majority of the developers. Many of these initial developers are experienced Apache committers already and all are experienced with working in distributed development communities. Reliance on Salaried Developers To the best of our knowledge, none of the initial committers are being paid to develop code for this project. Relationships with Other Apache Products A number of existing ASF projects already benefit from OGNL
Re: [PROPOSAL] Flume for the Apache Incubator
A hearty +1 from me. Do you need another mentor? Ralph On May 27, 2011, at 7:18 AM, Jonathan Hsieh wrote: Howdy! I would like to propose Flume to be an Apache Incubator project. Flume is a distributed, reliable, and available system for efficiently collecting, aggregating, and moving large amounts of log data to scalable data storage systems such as Apache Hadoop's HDFS. Here's a link to the proposal in the Incubator wiki http://wiki.apache.org/incubator/FlumeProposal I've also pasted the initial contents below. Thanks! Jon. = Flume - A Distributed Log Collection System = == Abstract == Flume is a distributed, reliable, and available system for efficiently collecting, aggregating, and moving large amounts of log data to scalable data storage systems such as Apache Hadoop's HDFS. == Proposal == Flume is a distributed, reliable, and available system for efficiently collecting, aggregating, and moving large amounts of log data from many different sources to a centralized data store. Its main goal is to deliver data from applications to Hadoop’s HDFS. It has a simple and flexible architecture for transporting streaming event data via flume nodes to the data store. It is robust and fault-tolerant with tunable reliability mechanisms that rely upon many failover and recovery mechanisms. The system is centrally configured and allows for intelligent dynamic management. It uses a simple extensible data model that allows for lightweight online analytic applications. It provides a pluggable mechanism by which new sources, destinations, and analytic functions which can be integrated within a Flume pipeline. == Background == Flume was initially developed by Cloudera to enable reliable and simplified collection of log information from many distributed sources. It was later open-sourced by Cloudera on GitHub as an Apache 2.0 licensed project in June 2010. During this time Flume has been formally released five times as versions 0.9.0 (June 2010), 0.9.1 (Aug 2010), 0.9.1u1 (Oct 2010), 0.9.2 (Nov 2010), and 0.9.3 (Feb 2011). These releases are also distributed by Cloudera as source and binaries along with enhancements as part of Cloudera Distribution including Apache Hadoop (CDH). == Rationale == Collecting log information in a data center in a timely, reliable, and efficient manner is a difficult challenge but important because when aggregated and analyzed, log information can yield valuable business insights. We believe that users and operators need a manageable systematic approach for log collection that simplifies the creation, the monitoring, and the administration of reliable log data pipelines. Oftentimes today, this collection is attempted by periodically shipping data in batches and by using potentially unreliable and inefficient ad-hoc methods. Log data is typically generated in various systems running within a data center that can range from a few machines to hundreds of machines. In aggregate, the data acts like a large-volume continuous stream with contents that can have highly-varied format and highly-varied content. The volume and variety of raw log data makes Apache Hadoop's HDFS file system an ideal storage location before the eventual analysis. Unfortunately, HDFS has limitations with regards to durability as well as scaling limitations when handling a large number of low-bandwidth connections or small files. Similar technical challenges are also suffered when attempting to write data to other data storage services. Flume addresses these challenges by providing a reliable, scalable, manageable, and extensible solution. It uses a streaming design for capturing and aggregating log information from varied sources in a distributed environment and has centralized management features for minimal configuration and management overhead. == Initial Goals == Flume is currently in its first major release with a considerable number of enhancement requests, tasks, and issues recorded towards its future development. The initial goal of this project will be to continue to build community in the spirit of the Apache Way, and to address the highly requested features and bug-fixes towards the next dot release. Some goals include: * To stand up a sustaining Apache-based community around the Flume codebase. * Implementing core functionality of a usable highly-available Flume master. * Performance, usability, and robustness improvements. * Improving the ability to monitor and diagnose problems as data is transported. * Providing a centralized place for contributed connectors and related projects. = Current Status = == Meritocracy == Flume was initially developed by Jonathan Hsieh in July 2009 along with development team at Cloudera. Developers external to Cloudera provided feedback, suggested features and fixes and implemented extensions of Flume. Cloudera engineering team has since
Re: OpenOffice.org Apache Incubator Proposal
Multiple threads would be welcome. Ralph On Jun 1, 2011, at 10:25 PM, robert_w...@us.ibm.com wrote: Dumb question. Are we obligated to converse like this, in a single email thread, for the duration of the proposal review process? Is this an organizing principle? Would I break anything if I created threads, perhaps prefixed in a consistent way, like OpenOffice Proposal: Topic Foo? -Rob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice.org Apache Incubator Proposal: Meritocracy and Committers for non-coders?
Every Apache project's PMC has a duty and responsibility to award commit privileges to individuals who contribute to the project and, when warranted, invite those people to participate in the project management committee. The conditions the PMC chooses to use to base their decisions on who to invite are completely in their control. In the Cocoon project one of the people we granted commit rights to was solely on the basis of his contributions to the community in organizing our get-togethers and other promotional work he was doing. He is now a member of the ASF. If the project has people who enjoy doing QA or marketing work, etc. the PMC should jump for joy and invite them to be a committer. Ralph On Jun 2, 2011, at 6:43 AM, robert_w...@us.ibm.com wrote: Simon Brouwer simon.o...@xs4all.nl wrote on 06/02/2011 09:21:53 AM: Should we add ourselfs as commiters? If you would like to contribute here (possibly instead of, or in addition, to your work at TDF), then yes! Please add yourself into the proposal on the wiki. I had already been so bold as to adding myself to the list, expressing my support to the proposal. I was wondering though. In the OpenOffice.org project, many community members contribute in other ways than committing code, for example by writing or translating documentation, being active in the marketing project, taking part in QA. Some concern has been expressed that, if the meritocratic system in Apache is based on code contribution only, those community members are not able to fully become part of the OpenOffice.org Apache project or the Apache community. Excellent question, Simon! I've certainly seen QA committers. I assume translators would be similar. If you are contributing assets to the project, asserts that are checked in, and which should be peer reviewed and maintained, then the project needs a way to identify the project members are have the authority to check in these assets, but also the responsibility to review and check in the assets contributed by others. Please someone correct me if I'm wrong, but I don't think Apache makes a distinction between someone who contributes C++ code versus Java code versus translations versus test cases versus help and documentation. They all need to be contributed and reviewed and checked in. What isn't clear to me are things like the following: 1) A strong QA member, who does manual testing, enters defect reports, does smoke tests, etc. How do they advance in the meritocracy? Is there any opportunity for them to be recognized as a committer and eventually as a PMC member? 2) Ditto for someone working on marketing oriented aspects of the project, helping to arrange conferences, working on logos, etc.? 3) Ditto for someone on the build/release management side, for example, liaising with Linux distros to get them to include OpenOffice releases. All of these roles (and others which I've surely missed) are critical to the project's success. How does a project typically recognize the lead contributors in these areas? Is it a case of If it is not checked into the repository, it doesn't count ?? I hope note. -Rob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache BeanShell in the Incubator
+1 (binding) Ralph On May 24, 2013, at 12:23 AM, Simone Tripodi wrote: Dear ASF members, We would like to propose BeanShell for the incubator. The proposal draft is available at: https://wiki.apache.org/incubator/BeanShellProposal, follows below the proposal Open is open for at least 72h and closes approximately on May 27th at 8:20am GMT [ ] +1 accept BeanShell in the Incubator [ ] +/-0 [ ] -1 because (provide a reason) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ ~~~ = BeanShell = == Abstract == The following proposal is about BeanShell, see JSR-274: The BeanShell Scripting Language implementation. == Proposal == BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. Users can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so users can call BeanShell from Java applications to execute Java code dynamically at run-time or to provide extensibility in applications. Alternatively, users can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as application, users can freely pass references to live objects into scripts and return them as results. == Background == BeanShell is a long living project born in the 2000 thanks to Patrick Niemeyer initial effort, who is still maintaining the project, with the help of Daniel Leuck and contributions voluntarily sent by users. == Rationale == Currently there are no projects hosted by the ASF focused on providing JSR-274 implementation, moving the existing BeanShell project under the Apache umbrella would mean the ASF provides the JSR-274 reference implementation. = Current Status = == Meritocracy == The historical BeanShell team believes in meritocracy and always acted as a community. Mailing list, open issue tracker and other communication channels have always been adopted since its first release. The adoption in a larger community, such as Apache, is the natural evolution for BeanShell. Moreover, the Apache standards will enforce the existing BeanShell community practices and will be a foundation for future committers involvement. == Core Developers == In alphabetical order: * Daniel Leuck dan at ikayzo dot com, * Patrick Niemeyer pat at ikayzo dot com * Pedro Giffuni pfg at apache dot org * Simone Tripodi simonetripodi at apache dot org == Alignment == Main aim of the project is to develop and maintain a fully flavored JSR-274 implementation that can be used by other Apache projects that need a Java Scripting Language. = Known Risks = == Orphaned Products == The increasing number of BeanShell adopters and the raising interest for the JSR-274 technology let us believe that there is a minimal risk for this work to being abandoned from the community. Moreover, BeanShell has been already used by the following projects for years: * Apache OpenOffice * Apache Maven * Apache JMeter == Inexperience with Open Source == All of the committers have experience working in one or more open source projects inside and outside ASF. == Homogeneous Developers == The list of initial committers are geographically distributed across the world with no one company being associated with a majority of the developers. Many of these initial developers are experienced Apache committers already and all are experienced with working in distributed development communities. == Reliance on Salaried Developers == To the best of our knowledge, none of the initial committers are being paid to develop code for this project. BeanShell has already proven its capability to attract external developers. == Relationships with Other Apache Products == A number of existing ASF projects already benefit from BeanShell implementation, including Apache OpenOffice, Apache Maven and Apache JMeter. It is hoped that members of those projects will be interested in contributing to and adopting this implementation. == An Excessive Fascination with the Apache Brand == Even if the BeanShell community recognizes the power and the attractiveness of the ASF brand, we are
Re: [VOTE] Accept Apache BeanShell in the Incubator
+1 (binding) Ralph On Jun 3, 2013, at 6:02 AM, Mattmann, Chris A (398J) wrote: +1 (binding). Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Simone Tripodi simonetrip...@apache.org Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, May 24, 2013 12:23 AM To: general@incubator.apache.org general@incubator.apache.org Subject: [VOTE] Accept Apache BeanShell in the Incubator Dear ASF members, We would like to propose BeanShell for the incubator. The proposal draft is available at: https://wiki.apache.org/incubator/BeanShellProposal, follows below the proposal Open is open for at least 72h and closes approximately on May 27th at 8:20am GMT [ ] +1 accept BeanShell in the Incubator [ ] +/-0 [ ] -1 because (provide a reason) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ ~~ ~ = BeanShell = == Abstract == The following proposal is about BeanShell, see JSR-274: The BeanShell Scripting Language implementation. == Proposal == BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. Users can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so users can call BeanShell from Java applications to execute Java code dynamically at run-time or to provide extensibility in applications. Alternatively, users can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as application, users can freely pass references to live objects into scripts and return them as results. == Background == BeanShell is a long living project born in the 2000 thanks to Patrick Niemeyer initial effort, who is still maintaining the project, with the help of Daniel Leuck and contributions voluntarily sent by users. == Rationale == Currently there are no projects hosted by the ASF focused on providing JSR-274 implementation, moving the existing BeanShell project under the Apache umbrella would mean the ASF provides the JSR-274 reference implementation. = Current Status = == Meritocracy == The historical BeanShell team believes in meritocracy and always acted as a community. Mailing list, open issue tracker and other communication channels have always been adopted since its first release. The adoption in a larger community, such as Apache, is the natural evolution for BeanShell. Moreover, the Apache standards will enforce the existing BeanShell community practices and will be a foundation for future committers involvement. == Core Developers == In alphabetical order: * Daniel Leuck dan at ikayzo dot com, * Patrick Niemeyer pat at ikayzo dot com * Pedro Giffuni pfg at apache dot org * Simone Tripodi simonetripodi at apache dot org == Alignment == Main aim of the project is to develop and maintain a fully flavored JSR-274 implementation that can be used by other Apache projects that need a Java Scripting Language. = Known Risks = == Orphaned Products == The increasing number of BeanShell adopters and the raising interest for the JSR-274 technology let us believe that there is a minimal risk for this work to being abandoned from the community. Moreover, BeanShell has been already used by the following projects for years: * Apache OpenOffice * Apache Maven * Apache JMeter == Inexperience with Open Source == All of the committers have experience working in one or more open source projects inside and outside ASF. == Homogeneous Developers == The list of initial committers are geographically distributed across the world with no one company being associated
Re: [VOTE] Apache Spark for the Incubator
+1 (binding) Ralph On Jun 7, 2013, at 10:34 PM, Mattmann, Chris A (398J) wrote: Hi Folks, OK discussion has died down, time to VOTE to accept Spark into the Apache Incubator. I'll let the VOTE run for at least a week. So far I've heard +1s from the following folks, so no need for them to VOTE again unless they want to change their VOTE: +1 Chris Mattmann* Konstantin Boudnik Henry Saputra* Reynold Xin Pei Chen Roman Shaposhnik* Suresh Marru* * -indicates IPMC [ ] +1 Accept Spark into the Apache Incubator. [ ] +0 Don't care. [ ] -1 Don't accept Spark into the Apache Incubator because.. Proposal text is below. === Abstract === Spark is an open source system for large-scale data analysis on clusters. === Proposal === Spark is an open source system for fast and flexible large-scale data analysis. Spark provides a general purpose runtime that supports low-latency execution in several forms. These include interactive exploration of very large datasets, near real-time stream processing, and ad-hoc SQL analytics (through higher layer extensions). Spark interfaces with HDFS, HBase, Cassandra and several other storage storage layers, and exposes APIs in Scala, Java and Python. Background Spark started as U.C. Berkeley research project, designed to efficiently run machine learning algorithms on large datasets. Over time, it has evolved into a general computing engine as outlined above. Spark¹s developer community has also grown to include additional institutions, such as universities, research labs, and corporations. Funding has been provided by various institutions including the U.S. National Science Foundation, DARPA, and a number of industry sponsors. See: https://amplab.cs.berkeley.edu/sponsors/ for full details. === Rationale === As the number of contributors to Spark has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Spark is a natural fit for the Apache foundation: Spark already interoperates with several existing Apache projects (HDFS, HBase, Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar with the Apache process and and subscribes to the Apache mission - the team includes multiple Apache committers already. Finally, joining Apache will help coordinate the development effort of the growing number of organizations which contribute to Spark. == Initial Goals == The initial goals will most likely be to move the existing codebase to Apache and integrate with the Apache development process. Furthermore, we plan for incremental development, and releases along with the Apache guidelines. === Current Status === == Meritocracy == The Spark project already operates on meritocratic principles. Today, Spark has several developers and has accepted multiple major patches from outside of U.C. Berkeley. While this process has remained mostly informal (we do not have an official committer list), an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Spark project would include several of these participants as committers from the onset. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. === Community === Acceptance into the Apache foundation would bolster the already strong user and developer community around Spark. That community includes dozens of contributors from several institutions, a meetup group with several hundred members, and an active mailing list composed of hundreds of users. Core Developers The core developers of our project are listed in our contributors and initial PPMC below. Though many exist at UC Berkeley, there is a representative cross sampling of other organizations including Quantifind, Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends. === Alignment === Our proposed effort aligns with several ongoing BIGDATA and U.S. National priority funding interests including the NSF and its Expeditions program, and the DARPA XDATA project. Our industry partners and collaborators are well aligned with our code base. There are also a number of related Apache projects and dependencies, that will be mentioned in the Relationships with Other Apache products section. == Known Risks == === Orphaned Products === Given the current level of investment in Spark - the risk of the project being abandoned is minimal. There are several constituents who are highly incentivized to continue development. The U.C. Berkeley AMPLab relies on Spark as a platform for a large number of long-term research projects. Several companies have build verticalized products which are tightly dependent on Spark. Other companies have devoted significant internal infrastructure investment in Spark. === Inexperience with Open Source === Spark has
Consideration of OpenOffice.org as a podling
I've just managed to wade through some 400+ emails to this list in the last 2 days and I would estimate that less than 10 were particularly relevant to what my vote will ultimately be on this proposal. It seems pretty clear to me that there is a lot of emotional reaction to this but a lot of that is from people who don't really seem to grasp what the incubator process, and perhaps the ASF itself, are about. First and foremost reading [1] followed by [2] and [3] should be a requirement before posting to this list. As I read all these posts I found myself wondering what the authors thought they were accomplishing. Many of the conversations here seem to be focused on whether OpenOffice belongs at the ASF because TDF is already in place and/or suggested that the proposal be evaluated while ignoring the licensing. Frankly, I believe most of the people who will vote on this proposal won't find these arguments very persuasive. We have admitted many projects in the past that seemingly duplicated other projects that already existed, in some cases right here at the ASF. Some were because they were choosing to achieve the same goals in a different way and some simply because the other alternative(s) were under a license that isn't equivalent to the Apache License. As a PMC member who will be voting on this I find the question of collaboration between this project and the TDF to be somewhat interesting but not a requirement for entry into the incubator. It is primarily something that should continue to be discussed on the project's development list once it is created. If this issue is relevant than I would expect it to manifest itself by having the proposal fail to gain enough initial committers, not by having some consensus reached before the project enters the incubator. I understand the desire of those who favor other alternatives to see those promoted, but at the ASF the way that is accomplished is by joining the project and working within the community to achieve your goals. The purpose of admitting projects to the incubator is not about having a fully functioning project upon admission. Rather it is to provide guidance, encouragement and support to projects that the incubator PMC believes have a reasonable chance at graduation into an Apache top level project. Discussions on whether the project will be able to perform builds, keep the documentation up to date, or even address all the Jira issues raised upon entry to the incubator simply aren't relevant at this time. These are all the things a project must be able to do to exit the incubator, not enter it. The primary factors I consider when voting on a project are: 1. Does the project have value that isn't already being fulfilled by some other project under a license equivalent to the Apache License (For example, Apache Harmony), or does the project try to achieve its goal in a way that is fundamentally different than another project? (We have several NoSQL variants here) 2. Will the project be able to have a fully functioning code base under the Apache License upon graduation? A project that requires a huge amount of code rewritten is going to have problems exiting the incubator in a reasonable amount of time. 3 Does the project have a significant number of dependencies on components with licenses that are incompatible with Apache software? Again, a project that requires a ton of rework is going to have problems. 4. Does the project have enough initial committers to a) effectively start to work on the tasks to get the project moving forward and b) attract other committers? 5. Has the project attracted a sufficient number of mentors who will have sufficient time to give to the project? There are many cases where mentors have signed up with good intentions but have not been effective due to time commitments. I am not trying to cut off discussion with this post. I am just pointing out that a lot of this is just noise and if this volume keeps up at some point I'll probably have to stop following OOo posts until I see a thread with [VOTE] in it. If the intent is to provide information the Incubator PMC members can use to cast a vote then I would recommend focusing on the list of items above, not discussions about LGPL vs ALv2, Oracle, IBM, Lotus Symphony, hardware, etc. Ralph [1] http://theapacheway.com/ [2] https://blogs.apache.org/foundation/entry/incubation_at_apache_what_s [3] http://www.apache.org/foundation/how-it-works.html#incubator
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 8:43 AM, Ralph Goers wrote: I posted a similar statement yesterday. Personally, I think the traffic on this list has settled down a lot in the last 24 hours and is now focusing in on topics more relevant to this list. But maybe that is just because it was Saturday :-) What I am still waiting to hear on are: 1. The amount of code in the project that the grant didn't give to us under the Apache License. 2. The amount of work that will be required to rework dependencies. 3. Whether the number of initial committers will be sufficient to start the project (this is probably going to be very subjective). 4. Whether there are enough mentors who have the time to devote to this. Since this is a very large undertaking I'd appreciate a bit more than just their name on the wiki but perhaps an actual estimate of how much time they have to devote to the project. Well, now maybe I don't care so much about number 4. There are now 7 mentors listed in the proposal. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 11:24 AM, Simon Phipps wrote: On 5 Jun 2011, at 19:15, Greg Stein wrote: On Sun, Jun 5, 2011 at 14:05, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/5/2011 10:43 AM, Ralph Goers wrote: I posted a similar statement yesterday. Personally, I think the traffic on this list has settled down a lot in the last 24 hours and is now focusing in on topics more relevant to this list. But maybe that is just because it was Saturday :-) Agreed, just some quick thoughts... What I am still waiting to hear on are: 1. The amount of code in the project that the grant didn't give to us under the Apache License. List published by Sam, and Christian suggests this reflects the OOo repo... http://people.apache.org/~rubys/openoffice.files.txt Actually tearing into that repo for files differently-copyrighted might be a task for RAT :) I doubt that you'll find anything differently-copyrighted in that list. My understanding is that Oracle created the list with something like grep '(C) Oracle' :-) I'm more interested in the list of files from the Hg repository that are NOT in that list. I gotta believe it is non-zero, so what are they, and how much of a problem will that be? I've been discussing this privately with some folk, and while we've not done an exhaustive analysis between us we're fairly sure that list doesn't include any of the (numerous) work-in-progress branches that are not merged into the actual release. Is it crucial to get a comprehensive list before the podlet is established, or can ASF still sort this out with Oracle in incubation? I personally don't need anything sorted out before the project enters incubation. All I care about is whether the community will be able to effectively deal with it or be blocked by it. That just requires some idea of how big a problem it is. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 3:30 PM, Niall Pemberton wrote: I agree with you - in this case I think it would be better if IBM collaborated with LibreOffice, rather than seeking to compete. But I could be wrong. I don't work for IBM but I do work for a corporation that uses a similar business model. I would guess that building a product that builds upon a work that is primarily under the LGPL is simply not an option. There are many companies that are comfortable in building a business model where all their products are open source. I don't believe IBM is one of them. So this is not even an option. However, I suspect IBM would be willing to collaborate in other ways - just not in any way that forces them to move from releasing proprietary software products. Since Oracle has put the code under the Apache license I would imagine that IBM would be free to take that code and move it internal should the Incubator PMC not approve the podling. Personally, I would much rather have IBM participate here than see them do that. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice LibreOffice
On Jun 5, 2011, at 3:51 PM, Keith Curtis wrote: On Sun, Jun 5, 2011 at 3:42 PM, Gavin McDonald ga...@16degrees.com.au wrote: It provides over 150 other projects, all of them are useless to you ? Yes, almost all of them are Java, and I don't have Java installed on my laptop or server. http://projects.apache.org/indexes/language.html Apache is clearly useful to lots of other people, but by picking Java it has hurt its situation in the Linux community with people like me. Please, before you post here could you get some understanding of the ASF? The Apache Software Foundation doesn't pick anything. If you want to code in SNOBOL, Pascal, Fortran, Mumps, APL, C/C++, Assembly or any other language we really don't care. All we care about is that you can build a community and that your code is released under the Apache license. Obviously, there are a ton of people who disagree with you because they all proposed Java-based projects and attracted developers. As for the support of IBM you mentioned in another email, I almost fell over laughing. First, the ASF is made up entirely of individuals, both as committers and members. No corporations allowed. We do accept sponsorships both from individuals and corporations. What that buys you is what is documented at http://www.apache.org/foundation/sponsorship.html. Primarily the benefit consists entirely of what you see on http://www.apache.org/foundation/thanks.html. I posted these in a prior post but you either didn't read them or just skimmed them. Please read them again. [1] http://theapacheway.com/ [2] https://blogs.apache.org/foundation/entry/incubation_at_apache_what_s [3] http://www.apache.org/foundation/how-it-works.html#incubator Ralph
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 3:45 PM, Niall Pemberton wrote: On Sun, Jun 5, 2011 at 10:30 PM, Richard S. Hall he...@ungoverned.org wrote: On 6/5/11 16:50, Jochen Wiedmann wrote: On Sun, Jun 5, 2011 at 8:21 PM, Niall Pemberton niall.pember...@gmail.com wrote: IMO the only negative thing then about LibreOffice is the copyleft license - everything else about them is great. When deciding whether to accept OO we should consider whether that and facilitating BigCos interests is worth splitting the FOSS community. I am considering voting -1 to this proposal for those reasons. Thanks for expressing my feelings so well, Niall! I'll lend a voice to the contrary. I can't see why splitting a community should be a factor in entry to the incubator. Just about every new open source community is trying to pull away developers from another community doing similar stuff. That's the nature of the beast. True, but when its essentially the same software, rather than different software solving the same problem? If I proposed a new project that was a fork of the HTTP project, how would that go down? If you proposed a new project to implement the HTTP server in Java and got a community around it I'd vote +1. I wouldn't join because it wouldn't scratch any itch I have but I wouldn't stand in the way. For me, getting the OOo code fully available under AL is reason enough to +1 it as far as I'm concerned...if I were on the IPMC... :-) License is important, but thats not all the ASF is about. Community is important too. I respect you're right to vote however you wish but if all its down to is license then I'm not sure. I care about end users. If my employer wanted to build a product that required ODF and was going to be delivered to a desktop I am 100% sure I would not be able to use LibreOffice. They would happily consume Apache Office. Community is important to me, but only in the sense that a successful community can be built here. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 4:02 PM, Niall Pemberton wrote: On Sun, Jun 5, 2011 at 11:51 PM, robert_w...@us.ibm.com wrote: Niall Pemberton niall.pember...@gmail.com wrote on 06/05/2011 06:30:06 PM: I agree with you - in this case I think it would be better if IBM collaborated with LibreOffice, rather than seeking to compete. But I could be wrong. And I support 100% your right to have that opinion and to support whatever open source project or projects you want, to worship your own God and to drink the beer of your choice. But if there are a sufficient number of people (as determined subjectively by the IPMC) who have a different opinion, and who would like to do an open source project at Apache, and they have a proposal acceptable in other ways, then I think it should be allowed. Otherwise this is like the Baptists telling the Methodists that they cannot have a church of their own in town, because the Baptists want to recruit a larger choir. It is clear from IBM switching its efforts from Harmony to OpenJDK that there are no religious reasons over license. Other ASF people have expressed in this thread that in their opinion that is reason enough (and I respect that view) - but IBM can't claim that. So I think my point still stands. I seriously doubt IBM switched to the license OpenJDK is under. Instead, I'd guess they got a proprietary license from Oracle so they could continue to ship their JDK on AIX. They cannot do that in many other cases. Of course, if you can find the source for IBM's JDK implementation then that would prove me wrong. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 4:24 PM, Niall Pemberton wrote: It could be argued either way. I am sure if IBM put its efforts to LibreOffice then I'm sure it would be a great success. So why doesn't IBM want to take part when theres a great FOSS community already in existence? Did you not read my post in reply to you an hour ago? The answer is obvious. IBM is not an Open Source company but a proprietary software company. Those are two separate business models. That is like asking Microsoft why you can't have the source code for Windows. Expecting a Leopard to change into a Lion is simply not going to happen - at least not quickly. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice LibreOffice
On Jun 5, 2011, at 4:28 PM, Keith Curtis wrote: On Sun, Jun 5, 2011 at 4:13 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Please, before you post here could you get some understanding of the ASF? The Apache Software Foundation doesn't pick anything. I realize that everyone makes their own choice, it just seems that Java is the dominant language. Whereas it is being phased out of LibreOffice. All we care about is that you can build a community and that your code is released under the Apache license. It seems some want more than that, because they also don't want it to be relicensed and made GPL later. The Apache license doesn't say anything about it, so saying you just want the Apache license does not seem totally true. We don't care what users do with our software. Those who are smart and create proprietary products with it contribute back because they don't want to maintain a proprietary fork, but we don't care if they don't.. They are happy to extend it with their own proprietary stuff and we are fine with that. As for the support of IBM you mentioned in another email, I almost fell over laughing. There are a number of people being paid by IBM on this list who are involved with this OO effort. So what? They are here as individuals. I get paid by an employer too. Although I take their interests into account I am not bound by them. I read your stuff. I find it paradoxical that the Apache org claims to be pragmatic, yet insists on the Apache license + no relicensing. What are you talking about? You can relicense to your hearts content. You just can't contribute it back under some other license otherwise user's couldn't use it and then relicense it. If you can't grasp that concept then there really is no point to further discussion. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 4:33 PM, Niall Pemberton wrote: On Mon, Jun 6, 2011 at 12:30 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jun 5, 2011, at 4:24 PM, Niall Pemberton wrote: It could be argued either way. I am sure if IBM put its efforts to LibreOffice then I'm sure it would be a great success. So why doesn't IBM want to take part when theres a great FOSS community already in existence? Did you not read my post in reply to you an hour ago? The answer is obvious. IBM is not an Open Source company but a proprietary software company. Those are two separate business models. That is like asking Microsoft why you can't have the source code for Windows. Expecting a Leopard to change into a Lion is simply not going to happen - at least not quickly. I did read it - but IBM has decided to happily contribute to the GPL'd OpenJDK - so I don't believe it has to change any spots. Yes, it does. IBM doesn't have to operate under the GPL because Oracle has given them permission to use some other license. With LibreOffice that is not an option. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 4:33 PM, Niall Pemberton wrote: On Mon, Jun 6, 2011 at 12:30 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jun 5, 2011, at 4:24 PM, Niall Pemberton wrote: It could be argued either way. I am sure if IBM put its efforts to LibreOffice then I'm sure it would be a great success. So why doesn't IBM want to take part when theres a great FOSS community already in existence? Did you not read my post in reply to you an hour ago? The answer is obvious. IBM is not an Open Source company but a proprietary software company. Those are two separate business models. That is like asking Microsoft why you can't have the source code for Windows. Expecting a Leopard to change into a Lion is simply not going to happen - at least not quickly. I did read it - but IBM has decided to happily contribute to the GPL'd OpenJDK - so I don't believe it has to change any spots. Here is another great example - and hopefully makes it obvious. Look at http://svnkit.com/licensing.html. For all the copyleft folks SVNKit is great. It is also great if you want to pay TMate money and ship your proprietary product. IBM can't do the first so it does the second. Not everyone who does dual licensing makes it so obvious but it happens all the time. I actually think it is kind of funny because it totally subverts the whole copyleft freedoms. Ralph
Re: OpenOffice LibreOffice
On Jun 5, 2011, at 4:40 PM, Keith Curtis wrote: What are you talking about? You can relicense to your hearts content. You just can't contribute it back under some other license otherwise user's couldn't use it and then relicense it. If you can't grasp that concept then there really is no point to further discussion. Joe Shafer wrote this: -- I don't feel the need to debate software licensing with a GPL fan on an apache.org list. Suffice it to say that I expect downstream projects to respect the license, and sublicense it if necessary in a way that doesn't invalidate our license. Seems like he is saying he doesn't want people to change the license of Apache software. Then you haven't read and comprehended the Apache license. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice or OpenOffice.org
There is a pending trademark application for OpenOffice by Tightrope Interactive so I am not sure that Apache OpenOffice would be acceptable unless the pending application is turned down. Ralph On Jun 5, 2011, at 5:01 PM, Alexandro Colorado wrote: Hi I want to know if there is any formal clearance on the way OpenOffice.org ought to be reffered as. Since the adquisition of Sun by Oracle, they start re-inciting misquotations of OpenOffice.org as OpenOffice even later they modified StarOffice as Oracle Open Office As OpenOffice.org was transfered to Apache, the proposal is quoted as Apache OpenOffice. And now new mailing lists are generated as oo instead of ooo. I understand there could be missconception as the beginning but lacking to address these issues they could become more structural as time goes by (ie. wikipage is easy to change, a mailing list is not as easy). I would want some clarification on this topic so that the apache people could make a decision. Also for reasons regarding trademark is important to avoid legal issues as time goes by. -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice or OpenOffice.org
On Jun 5, 2011, at 5:01 PM, Alexandro Colorado wrote: Hi I want to know if there is any formal clearance on the way OpenOffice.org ought to be reffered as. Since the adquisition of Sun by Oracle, they start re-inciting misquotations of OpenOffice.org as OpenOffice even later they modified StarOffice as Oracle Open Office As OpenOffice.org was transfered to Apache, the proposal is quoted as Apache OpenOffice. And now new mailing lists are generated as oo instead of ooo. I understand there could be missconception as the beginning but lacking to address these issues they could become more structural as time goes by (ie. wikipage is easy to change, a mailing list is not as easy). I would want some clarification on this topic so that the apache people could make a decision. Also for reasons regarding trademark is important to avoid legal issues as time goes by. For reference, the OpenOffice trademark application can be found at http://tarr.uspto.gov/servlet/tarr?regser=serialentry=85298190 Ralph
Re: OpenOffice or OpenOffice.org
On Jun 5, 2011, at 5:12 PM, Alexandro Colorado wrote: On Sun, Jun 5, 2011 at 7:08 PM, Ralph Goers ralph.go...@dslextreme.comwrote: There is a pending trademark application for OpenOffice by Tightrope Interactive so I am not sure that Apache OpenOffice would be acceptable unless the pending application is turned down. I will still enoucrage that play safe according to OOo guidelines. Some information here: http://wiki.services.openoffice.org/wiki/Art/Logo/License and http://about.openoffice.org/index.html#logo OpenOffice.org holds all rights to be used, so why not use it like that? Sorry, I misread your message. I don't disagree with this. However, Apache OpenOffice.org is a bit of a mouthful. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice or OpenOffice.org
On Jun 5, 2011, at 5:19 PM, Alexandro Colorado wrote: On Sun, Jun 5, 2011 at 7:16 PM, Ralph Goers ralph.go...@dslextreme.comwrote: On Jun 5, 2011, at 5:12 PM, Alexandro Colorado wrote: On Sun, Jun 5, 2011 at 7:08 PM, Ralph Goers ralph.go...@dslextreme.com wrote: There is a pending trademark application for OpenOffice by Tightrope Interactive so I am not sure that Apache OpenOffice would be acceptable unless the pending application is turned down. I will still enoucrage that play safe according to OOo guidelines. Some information here: http://wiki.services.openoffice.org/wiki/Art/Logo/License and http://about.openoffice.org/index.html#logo OpenOffice.org holds all rights to be used, so why not use it like that? Sorry, I misread your message. I don't disagree with this. However, Apache OpenOffice.org is a bit of a mouthful. Well the actual request is for the mailing list to be added an extra 'o' I doubt many people will pronouce 'ooo-user' or 'oo-user'. I just have an issue when is registered on the systems as 'oo' Got it. Feel free to update the wiki. If someone disagrees they will change it to something else. Ralph
Re: OpenOffice LibreOffice
On Jun 5, 2011, at 6:01 PM, Keith Curtis wrote: On Sun, Jun 5, 2011 at 5:56 PM, Sam Ruby ru...@intertwingly.net wrote: Fully disagree. I encourage you to read the terms. -Keith - Sam Ruby This is what the Wikipedia page on the Apache License says: The Apache License, like most other permissive licenses, does not require modified versions of the software to be distributed using the same license. You are confusing copyright and software licensing. You can modify software that is under the Apache license and use it in a proprietary product but you have to do it in a way that complies with the license and copyright law. You can use also use software that is under the LGPL in a proprietary product. The purpose of this list is not to explain how to do either of these. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 5, 2011, at 11:34 PM, Phil Steitz wrote: On 6/5/11 11:02 PM, William A. Rowe Jr. wrote: On 6/6/2011 12:47 AM, Phil Steitz wrote: On 6/5/11 10:16 PM, William A. Rowe Jr. wrote: ASF members wish to devote considerable time and energy to this project, so exactly who the hell are you to decide what they should and shouldn't devote that time and energy to? I am just a volunteer who has seen the ASF struggle with growth-related issues for several years now. I think it is a fair question to ask whether we should think about different / more selective criteria for entrance to the incubator. Sorry if asking that question offends you. To clarify this, because we have so many guests and observers trying to figure out the ASF... Sufficient numbers of board members, ASF members and even incubator team members have signed up as mentors. But more to the point, the central premise of the ASF is to facilitate developers to scratch their own itch. If improving particular processes, code or documentation interests you, by all means, do it. If some part of the code holds no interest to you, let someone else. And if you come to the ASF (even as a user) complaining about a particular piece of code, bring a patch, not a complaint, if you expect it to be fixed. The mentor list suggests to me that there are enough volunteers for this particular itch to accept it for graduation. Phil, you are not responsible and should not feel responsible to follow the activities of this project if it truly isn't your itch. Sorry, Bill, but as an ASF member I am in fact responsible for everything that the foundation does, including what we decide to accept into the Incubator. Of course, I am just one member, and we make these decisions by consensus. If the consensus is to accept this podling, I will welcome the project and accept the responsibility that we all will share having made that decision. Phil, I understand what your concern is but I just don't see a way to prevent exploitation other than what we already do. If you look at the Flume proposal made just a couple of days prior to this you will notice that most of the initial committers have the same employer. Is this exploitation? I don't think so. You probably don't either since you made no comment to that effect. Would it be exploitation if IBM convinced Oracle to propose it here and then provided no developers to work on the project but just used the source? Probably, but thousands of companies do that with all of our software. I just don't see how you can prevent what you are trying to without violating the spirit of what Apache is here for. To address your concern, we should raise this issue to the board and set a policy of accepting no further projects, if your opinion is shared by the rest of the incubator PMC. I did not suggest that we stop accepting projects. Read the post. I suggested that we try to come up with some principles governing what we accept into the incubator. If you can come up with some I'd happily discuss them with you. I don't think holding this proposal hostage to that is fair primarily because I don't have a lot of confidence the principals would exclude this project from entering. If you've read my previous posts you will see the principals I use when I vote. That concern need not be applied on a project-by-project basis (except to ensure there are sufficient number of interested mentors). Whatever principles we end up agreeing on should be applied to all candidate podlings. If just having enough mentors willing to sign up were sufficient, there would be no need for a vote of the IPMC. I agree with that and that is precisely what I do except that they are my own not a standard set. Apparently, I just don't use the same criteria you do. Frankly, that is OK by me. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice: were are we now?
On Jun 6, 2011, at 7:41 AM, Manfred A. Reiter wrote: Hi Richard, * 2011/6/6 Richard S. Hall he...@ungoverned.org On 6/6/11 2:48, Phil Steitz wrote: On 6/5/11 11:26 PM, William A. Rowe Jr. wrote: On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote: On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitzphil.ste...@gmail.com wrote: [...] Disclaimer: I work for Oracle, but certainly don't speak for them and I knew nothing about this other than what i've read on these mailing lists... However, it seems like we have lost sight of the fact that TDF split the community from OOo. Sure, Oracle is the perceived villain and TDF the perceived good guy, but it doesn't change the fact that OOo created the community in the first place. Fact: Your employer provoked the split, by a absolute non-communication on the existing mailinglist. Now, to say that TDF has split the Communtiy is dishonest! Under these conditions, I'll change my entry in the wiki. Manfred, I wouldn't be so hasty. There are lots of opinions around here and we all need a bit of a thick skin. You shouldn't take what any one member says as the truth. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Code covered by the Oracle grant
On Jun 6, 2011, at 7:27 AM, Sam Ruby wrote: On Mon, Jun 6, 2011 at 10:02 AM, Christian Lippka c...@lippka.com wrote: While the technical analyze here seems (should not use that word) correct my understanding is that missing bits could still be provided if requested. But this must be answered by people who are making the negotiations. I'll share my understanding. My first input was that any incubator proposal that was not accompanied by a substantial software grant would not get serious consideration. After a serious of miscommunications on both (ASF and Oracle's) sides I got on the phone directly with the Oracle VP driving this, and said that all we needed at this time was a substantial list to start from. If we needed more, we could discuss that later. This was approximately noon EDT on 31 May. After discussions with lawyers and collection of a list of files, the Software Grant was sent via email at 8:50PM PDT the same day. Others with no association to either IBM or Oracle can verify this basic timeline. My best guess is that while the list may be incomplete, it contains only files that Oracle could determine with absolutely certainty under incredible time pressure that they have the necessary rights to include a standard ASF software grant. While Oracle has absolutely no obligation to produce anything more, and people are welcome to factor that into their decisions once this comes up to a vote, nothing I have seen has indicated that anybody at Oracle is operating in anything other than good faith. It is my expectation that if we make reasonable requests and that if those requests are within Oracle's power to fulfill those requests, that we will obtain subsequent software grants. Sam, for me this is the only area where I question whether I will vote for the proposal. From what I read in Christian Lohmaier's summary Oracle has supplied about 50% of the OOo source code. His summary ended with Apache OOo is far from being able to deliver something that is even close to OOo as it is now. As I've said before, I don't want to see the project start off with an extremely large amount of work to do just to get something working. In later posts I see you got more files added to the list by Oracle and a list of more missing files from Simon. I would hope that the list of files to be delivered grows to the point where those far more familiar with the code than I am can verify it is at a reasonable starting point before we vote on this. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Sqoop for Incubation
+1 (binding) Ralph On Jun 7, 2011, at 8:39 PM, arv...@cloudera.com wrote: As there are no active discussions on the [PROPOSAL] thread for a few days now, I will like to initiate the vote to accept Sqoop as an Apache Incubator project. The proposal discussion thread and full text of the proposal can be found at the following locations: Discussion Thread: http://www.mail-archive.com/general@incubator.apache.org/msg27726.html Proposal: http://wiki.apache.org/incubator/SqoopProposal Please cast your votes: [ ] +1 Accept Sqoop for incubation [ ] +0 Indifferent to Sqoop incubation [ ] -1 Reject Sqoop for incubation This vote will close 72 hours from now. Thanks and Regards, Arvind Prabhakar - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Flume to join the Incubator.
Hadoop MapReduce. Furthermore, Flume provides a more general model for handling data and enables integration with projects such as Apache Hive, data stores such as Apache HBase, Apache Cassandra and Voldemort, and several Apache Lucene-related projects. == An Excessive Fascination with the Apache Brand == We would like Flume to become an Apache project to further foster a healthy community of contributors and consumers around the project. Since Flume directly interacts with many Apache Hadoop-related projects by solves an important problem of many Hadoop users, residing in the Apache Software Foundation will increase interaction with the larger community. = Documentation = * All Flume documentation (User Guide, Developer Guide, Cookbook, and Windows Guide) is maintained within Flume sources and can be built directly. * Cloudera provides documentation specific to its distribution of Flume at: http://archive.cloudera.com/cdh/3/flume/ * Flume wiki at GitHub: https://github.com/cloudera/flume/wiki * Flume jira at Cloudera: https://issues.cloudera.org/browse/flume = Initial Source = * https://github.com/cloudera/flume/tree/ == Source and Intellectual Property Submission Plan == * The initial source is already licensed under the Apache License, Version 2.0. https://github.com/cloudera/flume/blob/master/LICENSE == External Dependencies == The required external dependencies are all Apache License or compatible licenses. Following components with non-Apache licenses are enumerated: * org.arabidopsis.ahocorasick : BSD-style Non-Apache build tools that are used by Flume are as follows: * AsciiDoc: GNU GPLv2 * FindBugs: GNU LGPL * Cobertura: GNU GPLv2 * PMD : BSD-style == Cryptography == Flume uses standard APIs and tools for SSH and SSL communication where necessary. = Required Resources = == Mailing lists == * flume-private (with moderated subscriptions) * flume-dev * flume-commits * flume-user == Subversion Directory == https://svn.apache.org/repos/asf/incubator/flume == Issue Tracking == JIRA Flume (FLUME) == Other Resources == The existing code already has unit and integration tests so we would like a Jenkins instance to run them whenever a new patch is submitted. This can be added after project creation. = Initial Committers = * Andrew Bayer (abayer at cloudera dot com) * Jonathan Hsieh (jon at cloudera dot com) * Patrick Hunt (phunt at cloudera dot com) * Aaron Kimball (akimball83 at gmail dot com) * Bruce Mitchener (bruce.mitchener at gmail dot com) * Arvind Prabhakar (arvind at cloudera dot com) * Ahmed Radwan (ahmed at cloudera dot com) * Henry Robinson (henry at cloudera dot com) * Eric Sammer (esammer at cloudera dot com) * Derek Deeter (ddeeterctrb at gmail dot com) = Affiliations = * Andrew Bayer, Cloudera * Jonathan Hsieh, Cloudera * Patrick Hunt, Cloudera * Aaron Kimball, Odiago * Bruce Mitchener, Independent * Arvind Prabhakar, Cloudera * Ahmed Radwan, Cloudera * Henry Robinson, Cloudera * Eric Sammer, Cloudera * Derek Deeter, Intuit = Sponsors = == Champion == * Nigel Daley == Nominated Mentors == * Tom White * Nigel Daley * Ralph Goers * Patrick Hunt == Sponsoring Entity == * Apache Incubator PMC -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // j...@cloudera.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenOffice.org for incubation
+1 Ralph On Jun 10, 2011, at 9:02 AM, Sam Ruby wrote: *** Please change your Subject: line for any [DISCUSSION] of this [VOTE] As the discussions on the OpenOfficeProposal threads seem to be winding down, I would like to initiate the vote to accept OpenOffice.org as an Apache Incubator project. At the end of this mail, I've put a copy of the current proposal. Here is a link to the document in the wiki: http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207 As the proposal discussion threads are numerous, I encourage people to scan and review the archives for this month: http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser Please cast your votes: [ ] +1 Accept OpenOffice.org for incubation [ ] +0 Indifferent to OpenOffice.org incubation [ ] -1 Reject OpenOffice.org for incubation This vote will close 72 hours from now. - Sam Ruby = OpenOffice.org - An open productivity environment = == Abstract == !OpenOffice.org is comprised of six personal productivity applications: a word processor (and its web-authoring component), spreadsheet, presentation graphics, drawing, equation editor, and database. !OpenOffice.org is released on Windows, Solaris, Linux and Macintosh operation systems, with more [[http://porting.openoffice.org/|communities]] joining, including a mature [[http://porting.openoffice.org/freebsd/|FreeBSD port]]. !OpenOffice.org is localized, supporting over 110 languages worldwide. == Proposal == Apache !OpenOffice.org will continue the mission pursued by the !OpenOffice.org project while under the sponsorship of Sun and Oracle, namely: To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. In addition to to building the !OpenOffice.org product, as an end-user facing product with many existing individual and corporate users, this project will also be active in supporting end-users via tutorials, user forums, document template repositories, etc. The project will also work to further enable !OpenOffice.org to be used as a programmable module in document automation scenarios. == Background == !OpenOffice.org was launched as an open source project by Sun Microsystems in June 2000. !OpenOffice.org was originally developed under the name of StarOffice by Star Division, a German company, which was acquired by Sun Microsystems in 1999. Sun released this as open source in 2000. !OpenOffice.org is the leading alternative to MS-Office available. Its most recent major version, the 3.x series saw over [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100 million downloads]] in its first year. The [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most recent estimates]] suggest a market share on the order of 8-15%. The !OpenOffice source is written in C++ and delivers language-neutral and scriptable functionality. This source technology introduces the next-stage architecture, allowing use of the suite elements as separate applications or as embedded components in other applications. Numerous other features are also present including XML-based file formats based on the vendor-neutral !OpenDocument Format (ODF) standard from OASIS and other resources. == Rationale == !OpenOffice.org core development would continue at Apache following the contribution by Oracle, in accordance with Apache bylaws and its usual open development processes. Both Oracle and ASF agree that the !OpenOffice.org development community, previously fragmented, would re-unite under ASF to ensure a stable and long term future for OpenOffice.org. ASF would enable corporate, non-profit, and volunteer stakeholders to contribute code in a collaborative fashion. Supporting tooling projects will accompany the !OpenOffice.org contribution, providing APIs for extending and customizing !OpenOffice.org. Both !OpenOffice.org and the related tooling projects support the OASIS Open Document Format, and will attract an ecosystem of developers, ISVs and Systems Integrators. ODF ensures the users of !OpenOffice.org and related solutions will own their document data, and be free to choose the application or solution that best meets their requirements. The !OpenOffice.org implementation will serve as a reference implementation of the Open Document Format standard. = Current Status = == Meritocracy == We understand the intention and value of meritocracy at Apache. We are particularly gratified to learn, during the discussion on this proposal, that there is a strong role for non-coders to participate in this meritocracy and as they demonstrate their sustained commitment and merit, to take on
Re: [VOTE] Accept Bigtop for incubation
+1 (binding)
Ralph
On Jun 17, 2011, at 10:15 AM, Tom White wrote:
As there are no active discussions on the proposal thread, I would
like to initiate a vote to accept Bigtop as an Apache Incubator
project.
The proposal is available at
http://wiki.apache.org/incubator/BigtopProposal?action=recallrev=13
I've also put a copy of the proposal at the end of this email.
The discussion thread is available at
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cbanlktimriyvs5g5maklqvinauz9h6s5...@mail.gmail.com%3E
Please cast your votes:
[ ] +1 Accept Bigtop for incubation
[ ] +0 Indifferent to Bigtop incubation
[ ] -1 Reject Bigtop for incubation
This vote will close 72 hours from now.
Thanks,
Tom
= Bigtop - Apache Hadoop Ecosystem Packaging and Test =
== Abstract ==
Bigtop - a project for the development of packaging and tests of the
Hadoop ecosystem.
== Proposal ==
The primary goal of Bigtop is to build a community around the
packaging and interoperability testing of Hadoop-related projects.
This includes testing at various levels (packaging, platform, runtime,
upgrade, etc...) developed by a community with a focus on the system
as a whole, rather than individual projects.
Build, packaging and integration test code that depends upon official
releases of the Apache Hadoop-related projects (HDFS, MapReduce,
HBase, Hive, Pig, ZooKeeper, etc...) will be developed and released by
this project. As bugs and other issues are found we expect these to be
fixed upstream.
== Background ==
The initial packaging and test code for Bigtop was developed by
Cloudera to package projects from the Apache Hadoop ecosystem and
provide a consistent, inter-operable framework.
== Rationale ==
Hadoop defines itself as:
{{{
The Apache Hadoop project develops open-source software for reliable,
scalable, distributed computing. Hadoop includes these subprojects:
* Hadoop Common: The common utilities that support the other Hadoop
subprojects.
* HDFS: A distributed file system that provides high throughput access
to application data.
* MapReduce: A software framework for distributed processing of large
data sets on compute clusters.
}}}
There are also several other Hadoop-related projects at Apache. Some
TLP examples include HBase, Hive, Mahout, ZooKeeper, and Pig. There
are also several new projects in the Incubator such as HCatalog, Hama
and Sqoop.
From a packaging and deployment perspective, the current
loosely-coupled nature of the project has limitations:
1. Insufficient building against trunk versions of dependent projects
(in the style of Apache Gump).
1. Insufficient testing against the trunk versions of dependent projects.
1. No consistent packaging for the Linux servers which provide the
main Hadoop datacenter platform.
1. No functional testing against multi-machine clusters as part of
the regular automated build process. This is due to a lack of a
physical or virtual Hadoop cluster for testing, and not enough test
suites designed to run against a live cluster with known datasets.
The intent of this project is to build a community where the projects
are brought together, packaged, and tested for interoperability.
Projects such as Apache Whirr (incubating), which deploy and use a
collection of Hadoop-related projects, would benefit from the
interoperability testing done by Bigtop, rather than picking and
testing project combinations themselves.
== Initial Goals ==
Much of the code for Bigtop has been released by Cloudera under the
Apache 2.0 license for over two years.
Some current goals include:
* create a set of packages for the Hadoop ecosystem, over a wide
range of platforms
* interoperability test these projects
* document project sets that are known to work well together
Bigtop’s release artifact would consist of a single tarball of
packaging and test code that, when built, would produce source and
binary Linux packages for the upstream projects.
= Current Status =
== Meritocracy ==
Bigtop was originally developed and released as an open source
packaging infrastructure, CDH, by Cloudera.
== Community ==
The community is primarily the original developers at Cloudera,
however a number of contributions to the packaging specifications have
been accepted from outside contributors. Growing a diverse community
is the main reason to bring Bigtop to the Apache Incubator.
== Core Developers ==
The core developers for Bigtop project are:
* Andrew Bayer has extensive expertise with build tools, specifically
Jenkins continuous integration and Maven.
* Peter Linnell has contributed to the RPM packaging.
* Bruno Mahé has overseen much of the development of the RPM and
Debian packaging system.
* Roman Shaposhnik and Konstantin Boudnik designed and implemented
the system testing framework.
Many of the committers to the Bigtop project have
Re: [VOTE] Retire Bluesky Podling
+1 Ralph On Jun 27, 2011, at 10:49 PM, berndf wrote: Hi everyone, this is a vote to retire the Bluesky podling. 3.5 years into incubation, the podling has not made progress in terms of becoming an Apache project. Dev is still done behind closed doors, and developers are changing frequently without notifications on the public lists. Mentors are M.I.A. Reports are often late. No Apache release was every made. There were multiple attempts to reboot the podling (Thanks Luciano!) without much success. So now I'm calling a vote to end Incubation for Bluesky. The vote is open at least until 2011-07-02 12:00 UTC. [] +1, retire Bluesky for the time being [] -0/+0, I'm undecided [] -1, I will step up as a mentor, so let's give it another try Thanks for voting, Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Kafka to join the Incubator
+1 (binding) Ralph On Jun 28, 2011, at 10:00 AM, Jun Rao wrote: Hi all, Since the discussion on the thread of the Kafka incubator proposal is winding down, I'd like to call a vote. At the end of this mail, I've put a copy of the current proposal. Here is a link to the document in the wiki: http://wiki.apache.org/incubator/KafkaProposal And here is a link to the discussion thread: http://www.mail-archive.com/general@incubator.apache.org/msg29594.html Please cast your votes: [ ] +1 Accept Kafka for incubation [ ] +0 Indifferent to Kafka incubation [ ] -1 Reject Kafka for incubation This vote will close 72 hours from now. Thanks, Jun == Abstract == Kafka is a distributed publish-subscribe system for processing large amounts of streaming data. == Proposal == Kafka provides an extremely high throughput distributed publish/subscribe messaging system. Additionally, it supports relatively long term persistence of messages to support a wide variety of consumers, partitioning of the message stream across servers and consumers, and functionality for loading data into Apache Hadoop for offline, batch processing. == Background == Kafka was developed at LinkedIn to process the large amounts of events generated by that company's website and provide a common repository for many types of consumers to access and process those events. Kafka has been used in production at LinkedIn scale to handle dozens of types of events including page views, searches and social network activity. Kafka clusters at LinkedIn currently process more than two billion events per day. Kafka fills the gap between messaging systems such as Apache ActiveMQ, which provide low latency message delivery but don't focus on throughput, and log processing systems such as Scribe and Flume, which do not provide adequate latency for our diverse set of consumers. Kafka can also be inserted into traditional log-processing systems, acting as an intermediate step before further processing. Kafka focuses relentlessly on performance and throughput by not introspecting into message content, nor indexing them on the broker. We also achieve high performance by depending on Java's sendFile/transferTo capabilities to minimize intermediate buffer copies and relying on the OS's pagecache to efficiently serve up message contents to consumers. Kafka is also designed to be scalable and it depends on Apache ZooKeeper for coordination amongst its producers, brokers and consumers. Kafka is written in Scala. It was developed internally at LinkedIn to meet our particular use cases, but will be useful to many organizations facing a similar need to reliably process large amounts of streaming data. Therefore, we would like to share it the ASF and begin developing a community of developers and users within Apache. == Rationale == Many organizations can benefit from a reliable stream processing system such as Kafka. While our use case of processing events from a very large website like LinkedIn has driven the design of Kafka, its uses are varied and we expect many new use cases to emerge. Kafka provides a natural bridge between near real-time event processing and offline batch processing and will appeal to many users. == Current Status == === Meritocracy === Our intent with this incubator proposal is to start building a diverse developer community around Kafka following the Apache meritocracy model. Since Kafka was open sourced we have solicited contributions via the website and presentations given to user groups and technical audiences. We have had positive responses to these and have received several contributions and clients for other languages. We plan to continue this support for new contributors and work with those who contribute significantly to the project to make them committers. === Community === Kafka is currently being used by developed by engineers within LinkedIn and used in production in that company. Additionally, we have active users in or have received contributions from a diverse set of companies including MediaSift, SocialTwist, Clearspring and Urban Airship. Recent public presentations of Kafka and its goals garnered much interest from potential contributors. We hope to extend our contributor base significantly and invite all those who are interested in building high-throughput distributed systems to participate. We have begun receiving contributions from outside of LinkedIn, including clients for several languages including Ruby, PHP, Clojure, .NET and Python. To further this goal, we use GitHub issue tracking and branching facilities, as well as maintaining a public mailing list via Google Groups. === Core Developers === Kafka is currently being developed by four engineers at LinkedIn: Neha Narkhede, Jun Rao, Jakob Homan and Jay Kreps. Jun has experience within Apache as a Cassandra committer and PMC member. Neha has been an
Re: Bluesky calls for a new mentor!
Sorry, but the explanation below makes things sound even worse. Apache projects are not here to give students a place to do school work. What you have described is not a community. If the project cannot build a community of people who are interested in the project for more than a school term then it doesn't belong here. Ralph On Jun 29, 2011, at 8:12 PM, SamuelKevin wrote: Hi, Noel: 2011/6/30 Noel J. Bergman n...@devtech.com Joe Schaefer wrote: Chen Liu wrote: We propose to move future development of BlueSky to the Apache Software Foundation in order to build a broader user and developer community. You are supposed to be doing your development work in the ASF subversion repository, using ASF mailing lists, as peers. Chen, as Joe points out, these are what BlueSky should have been doing for the past three (3) years, and yet we still here a proposal for the future. Looking at the (limited) commit history, there is a total imbalance between the number of people associated with the development work (20+) and the number of people with Apache accounts here (2). I guess i can explain that. Most of the developers of BlueSky project are students. As you all know, students come when they join in school and go after they graduate. So the active developers are around 10. Like we used to have 5 committers, but now we only have 2 committers in active. Again, as Joe points out, ALL of BlueSky development should been done via the ASF infrastructure, not periodically synchronized. We are a development community, not a remote archive. What we really need you to discuss are *plans*, how you will implement them, who will implement them, and how you will collaborate in the codebase as peers. Joe, again, has this on the money. The BlueSky project must immediately make significant strides to rectify these issues. Now, not later. We should see: 1) All current code in the ASF repository. 2) All development via ASF accounts (get the rest of the people signed up). 3) Ddevelopment discussion on the mailing list. 4) All licensing issues cleaned up. According to what you've listed, i would forward your suggestion to bluesky dev list and wish we could make a quick response after discussion. Appreciate your help. regards, Kevin --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Bowen Ma a.k.a Samuel Kevin @ Bluesky Dev TeamXJTU Shaanxi Province Key Lab. of Satellite and Terrestrial Network Tech http://incubator.apache.org/bluesky/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Bluesky calls for a new mentor!
On Jul 1, 2011, at 2:04 PM, Gavin McDonald wrote: -Original Message- From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] Sent: Saturday, 2 July 2011 1:24 AM To: general@incubator.apache.org Subject: Re: Bluesky calls for a new mentor! On 7/1/2011 10:19 AM, Luciano Resende wrote: On Fri, Jul 1, 2011 at 7:49 AM, Benson Margulies bimargul...@gmail.com wrote: Based on the email trail recently, I'm in favor of completing the vote. I think that there is sufficient evidence that this project has 'failed to launch' as an Apache community, and should go put itself on github. If enough people disagree, they can vote -1. My vote is +1 to retire. This will be my sentiment as well, particularly if I look at the commit list archive [1] on Monday and continue to see no commits even after telling the podling that the code should be committed to Apache repository and any cleanup or further development should be done in the open. http://apache.markmail.org/search/?q=list%3Aorg.apache.incubator.blues ky-commits We also made it clear the *author* should also commit their own code, and all authors should become committers. Each term (semester) Bluesky will get a new crop of students (committers) and the old ones will be gone forever. Are we to keep on creating new committer accts for these folks knowing damn well that at the end of the term they disappear and a new lot appears? This is why they ( when they did commit) shared accounts. For the infra requirements of an Apache project alone, this project does not fit. Sounds like a great project, but not one that belongs here under its current style of working. If they can change that somehow ... (It's also obvious a 'community' will never get time to gel as the next lot move out/in , It's also obvious outsiders to Bluesky will likely not be able to participate, as that is not what the project is about - from their end. (So a diverse community cannot be built...) I see no benefit to the ASF or Bluesky in continuing on, but I hope to be mistaken. Gav... +1 I also don't feel the vote to retire should be tabled. I'm convinced this project is not going to gel into anything that would ever make it out of the incubator. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] accept DirectMemory as new Apache Incubator podling
+1 (binding) Ralph On Oct 2, 2011, at 12:36 AM, Simone Tripodi wrote: Hi all guys, I'm now calling a formal VOTE on the DirectMemory proposal located here: http://wiki.apache.org/incubator/DirectMemoryProposal Proposal text copied at the bottom of this email. VOTE close on Tuesday, October 4, early 7:30 AM CET. Please VOTE: [ ] +1 Accept DirectMemory into the Apache Incubator [ ] +0 Don't care [ ] -1 Don't Accept DirectMemory into the Apache Incubator because... Thanks in advance for participating! All the best, have a nice day, Simo P.S. Here's my +1 http://people.apache.org/~simonetripodi/ http://www.99soft.org/ = DirectMemory = == Abstract == The following proposal is about Apache !DirectMemory, a Java !OpenSource multi-layered cache implementation featuring off-heap memory storage (a-la Terracotta !BigMemory) to enable caching of Java objects without degrading JVM performance == Proposal == !DirectMemory's main purpose is to to act as a second level cache (after a heap based one) able to store large amounts of data without filling up the Java heap and thus avoiding long garbage collection cycles. Although serialization has a runtime cost store/retrieve operations are in the sub-millisecond range being pretty acceptable in every usage scenario even as a first level cache and, most of all, outperforms heap storage when the count of the entries goes over a certain amount. !DirectMemory implements cache eviction based on a simple LFU (Least Frequently Used) algorythm and also on item expiration. Included in the box is a small set of utility classes to easily handle off-heap memory buffers. == Background == !DirectMemory is a project was born in the 2010 thanks to Raffaele P. Guidi initial effort under [[https://github.com/raffaeleguidi/!DirectMemory/|GitHub]] and already licensed under the Apache License 2.0. == Rationale == The rationale behind !DirectMemory is bringing off-heap caching to the open source world, empowering FOSS developers and products with a tool that enables breaking the heap barrier and override the JVM garbage collection mechanism collection - which could be useful in scenarios where RAM needs are over the usual limits (more than 8, 12, 24gb) and to ease usage of off-heap memory in general = Current Status = == Meritocracy == As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. == Core Developers == In alphabetical order: * Christian Grobmeier grobmeier at apache dot org * Maurizio Cucchiara mcucchiara at apache dot org * Olivier Lamy olamy at apache dot org * Raffaele P. Guidi raffaele dot p dot guidi at gmail dot com * Simone Gianni simoneg at apache dot org * Simone Tripodi simonetripodi at apache dot org * Tommaso Teofili tommaso at apache dot org == Alignment == The purpose of the project is to develop and maintain !DirectMemory implementation that can be used by other Apache projects. = Known Risks = == Orphaned Products == !DirectMemory does not have any reported production usage, yet, but is getting traction with developers and being evaluated by potential users and thus the risks of it being orphaned are minimal == Inexperience with Open Source == All of the committers have experience working in one or more open source projects inside and outside ASF. == Homogeneous Developers == The list of initial committers are geographically distributed across the Europe with no one company being associated with a majority of the developers. Many of these initial developers are experienced Apache committers already and all are experienced with working in distributed development communities. == Reliance on Salaried Developers == To the best of our knowledge, none of the initial committers are being paid to develop code for this project. == Relationships with Other Apache Products == !DirectMemory fits naturally in the ASF because it could be successfully employed together with a large number of ASF products ranging from JCS - as a new cache region between the heap and indexed file ones, to ORM systems like Cayenne (i.e. replacing current OSCache based implementation), Apache JDO and JPA implementations and also java based databases (i.e. Derby) and all systems managing large amounts of data from Hadoop to Cassandra == A Excessive Fascination with the Apache Brand == While the Apache Software Foundation would be a good home for the !DirectMemory project it already has some traction and it could live on its own - however we see reciprocal benefits for both the ASF and the project in adopting the brand to better reach the community
Re: [VOTE] Retire Olio [Was: Retire Olio?]
+1 (binding) Ralph On Nov 10, 2011, at 4:17 PM, Henri Yandell wrote: Coming back to this. It unfortunately seems that there's no (even optimistic) expectation that Olio will graduate. So, voting: [ ] +1 [ ] -1, no because... Hen On Tue, Aug 16, 2011 at 11:27 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 8/17/2011 12:47 AM, Henri Yandell wrote: On Tue, Aug 16, 2011 at 10:40 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 8/17/2011 12:37 AM, Henri Yandell wrote: The copyright item isn't signed off at https://incubator.apache.org/projects/olio.html. So would need to delete the code (assuming a successful retirement vote). Where are the mentors? Wondering how conflicted-providence IP would hit svn in the first place. Digging a bit: Initial Olio code dump from Sun by clr. r700550 Added rails webapp by wsobel. r705828 Adding Web20Emulator by sheetal. r706388 There were other large adds, but those were the three initial big ones. I don't see any software grants relating to Olio. I see lots in the board reports about struggling to get committer diversity because the committers were at 3 corporations. I don't believe that conflicted-providence IP would have hit svn, yet if it's not signed off and (assuming no one steps up to say otherwise) I think delete is the only option we have. Agreed. Unless the mentors can check off that checkbox prior to the project's dormancy, svn will need to be rm'ed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Flex to join the Apache Incubator
+1 (binding) Ralph On Dec 27, 2011, at 1:51 AM, Bertrand Delacretaz wrote: Hi Incubator PMC members (*), I've just reviewed the [PROPOSAL] Flex for Apache Incubator thread and I think all relevant issues have been adressed now. I have added Anne and Dave Fisher as mentors, pending their final approval as Incubator PMC members. In the unlikely worst case that this approval doesn't happen the project has two confirmed mentors to start with anyway. Let's cast your votes to accept Flex as an incubating project, proposal is at http://wiki.apache.org/incubator/FlexProposal, copied below as well: [ ] +1 approve Flex as an incubating project. [ ] -1 reject (explaining why) [ ] +/- 0 don't care. This majority vote is open for 72 hours. Here's my +1. -Bertrand (*) although only votes from Incubator PMC members are binding, anybody is welcome to cast a vote ** Flex proposal copy *** = Apache Flex Proposal = == Abstract == Apache Flex is an application framework for easily building Flash-based applications for mobile devices, the browser and desktop. == Proposal == Apache Flex allows developers to target a variety of platforms, initially Apple iOS, Google Android, RIM !BlackBerry, Microsoft Windows, and Mac OS X with a single codebase. Flex provides a compiler, skinnable user-interface components and managers to handle styling, skinning, layout, localization, animation, module-loading and user interaction management. == Background == Apache Flex is the software evolution of the popular Adobe Flex SDK project. Adobe Flex SDK evolved from the need to provide developers with an easy programming model for creating rich Internet applications that can run in the browser, on the desktop or on mobile devices. Adobe Flex SDK has always focused on a single goal: to provide application developers with all of the constructs needed to boost their productivity while building large-scale, visually expressive applications. This meant that Flex provided all the traditional UI components in a way that designers and developers could interact with them along with a dynamic scripting language, !ActionScript, and a declarative markup language, MXML. Adobe will donate the Flex trademark to the Apache Software Foundation as part of the incubation process. The source code, documentation and related assets will all be contributed to the Apache Foundation as Flex. == Rationale == Content developers need to target multiple screens and the cost of creating applications native to every target platform is high. Additionally, the dominant window to the web is quickly becoming devices, mostly phones, and delivering consistent experiences is key. The Apache Flex project exists to bring the focus back to a consistent development model, one where a single application can run the exact same way across the web, desktop and mobile devices. == Initial Goals == * Donate all Adobe Flex SDK source code and documentation to the Apache Software Foundation. * Setup and standardize the open governance of the Apache Flex project. * Rename all assets from Adobe Flex SDK to Apache Flex in project source code, docs, tests and related infrastructure. == Current Status == Flex is a mature software project. 1.0 was shipped in March of 2004 with 7 major releases having shipped since. The most recent release was the 4.6 version which shipped on November 29th, 2011. This proposal is currently being [[http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCB14DCA2.3885F%25aharui%40adobe.com%3E|discussed]] on the incubator general mailing list, once that's done we'll ask the Incubator PMC to vote to accept it. == Meritocracy == The Adobe Flex source code is available to the community on the Adobe opensource site: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK. Currently, while the community has been invited to contribute patches to the codebase, only Adobe employees decided on which patches to commit. There were no external committers and this caused frustration in the community. Going forward, both Adobe and our community are eager to become one single merit-based community working together. To that end, Adobe employes only have a minority representation on the initial committers list. Adobe is working to educate our community with meetings and blog posts on how the Apache model makes this possible for them. We have made it clear to our community that going forward, the community, rather than Adobe, will determine the future of Flex. == Community == The community surrounding Flex is vast, diverse, distributed globally, and with all levels of proficiency in software development. The common thread of application development binds all Flex developers together. It is estimated that there is between 350,000 and 500,000 Flex developers worldwide. Precise numbers are impossible for us to know
Re: [VOTE] DeviceMap to join the Apache incubator
+1 (binding) Ralph On Dec 29, 2011, at 8:05 AM, Bertrand Delacretaz wrote: Hi Incubator PMC members (*), I've just reviewed the [PROPOSAL] Apache DeviceMap... thread and I think all relevant issues have been adressed now. Let's cast your votes to accept DeviceMap as an incubating project, proposal is at http://wiki.apache.org/incubator/DeviceMapProposal and copied below as well: [ ] +1 approve DeviceMap as an incubating project. [ ] -1 reject (explaining why) [ ] +/- 0 don't care. This majority vote is open for at least 72 hours. Here's my +1. -Bertrand (*) although only votes from Incubator PMC members are binding, anybody is welcome to cast a vote *** DeviceMap proposal *** == Abstract == Apache DeviceMap is a data repository containing device information, images and other relevant information for all sorts of mobile devices, e.g. smartphones and tablets. While the focus is initially on that data, APIs will also be created to use and manage it. == Proposal == Apache DeviceMap allows users to access a wide array of technical specifications, images and other artifacts related to mobile devices. Typical mobile devices include smartphones and tablets, such as: * Android devices from multiple vendors * Apple’s iPhone and iPad family of devices * !BlackBerry devices * Windows Phone devices from multiple vendors * Symbian devices * Devices with a small marketshare running Bada, Tizen, WebOS etc. The list of Apache DeviceMap devices remains open to other device types, as the mobile sector is a highly dynamic marketplace and new device forms may surface which may not too well fit into a smartphone / tablet matrix, e.g. ChromeOS Devices. == Repository Data == The exact structure of the repository data will be defined as the project progresses. At the moment we envision storing user agent strings and/or regular expressions, properties similar to CSS Media Queries, images of the actual devices, other attributes similar to what’s in UAPROF (http://en.wikipedia.org/wiki/UAProf) for example, per-country market share data, etc. Modern mobile applications often do not need very detailed device data, so we will concentrate, at least initially, on basic device features as used in html5 websites. The W3C’s Mobile Web Initiative specs (http://www.w3.org/2005/MWI/DDWG/) will also be evaluated for use in DeviceMap. == Background == The initial motivation for Apache DeviceMap is to provide an open repository of mobile device data, available to the general public according to the Apache License. == Rationale == We propose an open and community driven repository containing mobile device data, thereby allowing for analysis of device capabilities and feature sets. This is beneficial on several fronts, be it for software developers, stakeholders/decision makers or analysts. == Initial Goals == * Define what form of data is valuable/required to setup a good working repository * Define what image sets are valuable/required * Define a data retention policy, meaning when should data be purged * Collect existing data and setup simple procedures for users to contribute and validate such data. == Current Status == Proposal has been [[http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAEWfVJkuv5qmb%2B8JXuF%3D3Zx4dsUNXoMMRKLWpZu4Eh%3D9-vJESg%40mail.gmail.com%3E|discussed]] on the Incubator general list, vote is ongoing there now (TODO add link). == Community == This project will form a new community, driven by the initial committers listed below. We hope and feel that Apache DeviceMap will draw interest and its community will broaden. == Known Risks == For device images and other data, we’ll need to define acceptance criteria and traceability rules similar to what Apache uses for code, to avoid any legal issues. Gathering data of any sort is a potential sensitive area and may require good public communication or even public relation activities. == Initial Source == The [[http://OpenDDR.org|OpenDDR.org]] team will donate their existing source code to the DeviceMap podling. == Initial Committers == * Philip Jespersen - philip.jespersen (at) terria (dot) com * Bertrand Delacretaz - bdelacretaz (at) apache (dot) org * Christian Stocker - chregu (at) liip.ch * Scott Wilson - scottbw (at) apache (dot) org * Sylvain Wallez - sylvain (at) apache (dot) org * Andrew Savory - asavory (at) apache (dot) org * Nils Dehl - nils.dehl (at) dkd (dot) de * Brian !LeRoux - brian (at) apache (dot) org * Stefano Andreani - s.andreani (at) opentecheng (dot) com * Alessandro Bellucci - a.bellucci (at) opentecheng (dot) com * Werner Keil - werner (at) openddr (dot) org * Tim Fernando - info (at) timfernando (dot) com == Required Resources == === Mailing lists === * devicemap-dev @ incubator.apache.org * devicemap-commits @ incubator.apache.org * devicemap-private
Re: [VOTE] Bloodhound to join the Incubator
I find this post disturbing. Had it been posted before the vote closed I most certainly would have voted -1 as we don't encourage hostile forks at the ASF. Ralph On Dec 30, 2011, at 12:30 PM, Ethan Jucovy wrote: -1 The Bloodhound proposal is to build an issue tracker by first importing the Trac core code into the Apache Subversion repository. As currently planned, this project has potential to be detrimental to the existing Trac brand and community, and it seems that the Bloodhound project's goals could equally be achieved without taking the heavy-handed first step of forking the Trac codebase. I hope that the Bloodhound team will consider building Bloodhound as a set of plugins and configurations and an installer that distributes them with an upstream Trac version, rather than forking Trac as a first resort. My concerns fall into three categories: a) The Bloodhound proposal contains substantial allegations about the health of the Trac community and the competence of its maintainers, as motivating factors for the fork and rebuild community approach proposed. No documented evidence has been provided to support these claims, and many of the claims are directly contradicted by the publicly available records in the Trac community's issue tracker, mailing list archives and commit logs. b) Neither the Bloodhound proposal nor the ensuing discussions have demonstrated any compelling legal, procedural, technical or strategic reason why Bloodhound should be based on a fork of Trac rather than an upstream distribution of Trac. c) Although the people involved have been friendly and expressed a desire to keep the two projects in cooperation, the actions taken so far and the intentions announced are characteristic of a hostile fork. -- (a) The Bloodhound proposal contains substantial allegations, without evidence, about the health of the Trac community and the competence of its maintainers. These allegations are largely contradicted by publicly available records of the Trac community. * The Bloodhound proposal claims, Private efforts to engage the existing developers in implementing features have been negatively received[1]. (a.1) I was not involved, and all conversations between WANdisco and the Trac developers were private and off-record, so it is impossible to verify the actual sequence of events. But, per [2], it seems that what is referred to here is the following: WANdisco’s developers asked for commit access to the Trac core, and/or proposed migrating the Trac core to the Apache Foundation’s infrastructure and governance, with no prior history of engagement with the Trac community and no prior contributions (see a.2 below). If this is the case, characterizing it as an offer to implement features which was negatively received by the Trac developers is significantly misleading. (a.2) Five out of Bloodhound's six initial core developers have no publicly documented history of attempting to contribute or engage with Trac's existing mailing lists, issue tracker, or subversion repository[3,4,5,6,7]. The contributions of the one developer who has participated on the Trac mailing list and issue tracker have been well received[8,9]. * The proposal also says: As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions[1]. This last statement is false: (a.3) Outside contributions from non-core developers are certainly accepted. A quick search of Trac’s issue tracker turns up at least six patches submitted by non-core developers and merged in to core within the past four months[10,11,12,13,14,15]. Other contributions like bug reports and documentation are also accepted and well received. (a.4) Furthermore, outside contributors with a history of good submissions are granted direct commit access. According to the Trac project wiki the core currently has five active developers with wholesale commit access[16]. Two of those developers became core committers in the past year, based explicitly on their records of prior contributions[17,18]. -- (b) WANdisco's Ian Wild said that We'd rather only fork what we have to[19] but neither the Bloodhound proposal nor the ensuing discussions have demonstrated any substantial legal, procedural, technical or strategic reason why Bloodhound should be based on a fork of Trac rather than an upstream distribution of Trac. (b.1) Legal: On the trac-dev mailing list, in explaining WANdisco’s decision to propose a fork, Ian Wild said, The strong governance and very important legal protections that the Apache Software Foundation provide are not matched by the current Trac setup[20]. This may be true (I am not in a position to judge) but as far as I understand, the legal protections concern does not seem relevant to the decision to fork, one way or another. IANAL, but it seems that precisely the same legal protections would be in
Re: [VOTE] Bloodhound to join the Incubator
Arguing about the vote procedure isn't likely to get you very far. At this point, I would recommend that you hold a vote on the appropriate Trac mailing list regarding approving or disapproving a fork and then forwarding that here. If the existing community doesn't want a fork I would suspect the incubator PMC would require the bloodhound project not to start from one. Ralph On Dec 31, 2011, at 8:16 AM, Ethan Jucovy wrote: On Sat, Dec 31, 2011 at 10:57 AM, Ralph Goers ralph.go...@dslextreme.comwrote: I find this post disturbing. Had it been posted before the vote closed I most certainly would have voted -1 as we don't encourage hostile forks at the ASF. I hadn't realized the vote was closed until after sending the message -- my apologies. I don't wish to stir things up unnecessarily but is there any possibility of redoing the vote? * Per [1,2,3] it's not clear to me that the vote followed the Incubator's documented procedures. Who was the Sponsor who called the vote? Presumably Hyrum Wright is acting as Champion, but he seems to have initiated and closed the vote as well as making the proposal. * The announcement that the vote was closed, and the tally of votes, was not made in a separate thread. (I was not subscribed to this list until this week; until then I was only watching the discussion through the web archive, and I didn't notice that the vote was closed.) * Having a 72 hour voting period does not seem to be required[4] and it seems very short for a proposal of this nature. (Finding the time to write my message, and collecting the references, took me five days.) * In particular a 72 hour voting period in the middle of December seems especially short, as many people travel or are otherwise occupied for holidays. [1] The decision to accept a project is taken on a vote by the Sponsor. from http://incubator.apache.org/incubation/Process_Description.html#Acceptance [2] The decision to approve the candidate proposal MUST be taken on a vote by the Sponsor from http://incubator.apache.org/incubation/Incubation_Policy.html#Approval+of+Proposal+by+Sponsor [3] http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor [4] The Sponsor will typically take about 7-10 days before announcing a vote result. http://incubator.apache.org/incubation/Process_Description.html#Acceptance -- though glancing through the list's recent archives a 72-hour period doesn't seem atypical. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Thanks, Jukka. What I find interesting is that most of the posts in the first thread are after the vote had already closed here and it seems apparent they weren't even aware the vote had taken place. From what I read there was a single initial comment expressing discomfort about the proposal that was answered with At this point we're still in a period of community building and performing enough discovery to form a detailed plan. As such precise decisions about what will be in the first Bloodhound release are yet to be made. which was responded to with Cool. Looking forward to seeing the detailed plan. As I read it the ambivalence then seemed to be a wait and see about what the detailed plan was to be. I'm having trouble reconciling the answer in [4] since the only thing it could be based on was that bit of discussion and what happened in private, from which it is clear to me that they believed a plan was going to be proposed before anything was going to happen, especially in light of the later comments. Even in the private discussion with the few that were involved there apparently was misunderstanding as they said they expected more of a git-fork rather than a community fork. That is hard to understand though, since all along they knew the proposal was to come to the ASF. There is quite a bit of history in there about private discussions. Nothing seems to have been discussed in public with Trac until Dec 2, almost simultaneously with the proposal here. So far, there has only been a single response to [2]. I've not come to any conclusion myself on this but at the moment I'm still uncomfortable. Ralph On Jan 1, 2012, at 3:34 AM, Jukka Zitting wrote: Hi, On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: The Incubator proposal was publicized and discussed on trac-dev *simultaneously* with the discussion on general@incubator, and the reception was generally indifferent (as Greg mentioned earlier) To add some pointers to this, the trac-dev discussion thread is at [1]. A related vote was just called at [2]. The question about the fork status was also brought up [3] on general@ during discussion, and was IMHO answered pretty well [4]. Obviously the fear of this being seen as a hostile fork did become reality at least for some, so I guess there's a lesson here for us all. [1] https://groups.google.com/d/topic/trac-dev/FCaDVcbh1JQ/discussion [2] https://groups.google.com/d/topic/trac-dev/kMVFq9pkfus/discussion [3] http://markmail.org/message/w5efz3m2ihs7gmbw [4] http://markmail.org/message/3ylvwqjmqqvvh3sf BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. As one of the responses on their email thread says, Its just rude. You can choose to frame it however you want, but if the plan is to take the current Trace code base and check it in to our subversion repository, then in my book it is a fork. That said, it is still unclear to me how this will resolve itself. I have yet to see any outright support of a fork. Mostly, hell, no or it's BSD licensed, let them do what they want, which isn't exactly a resounding endorsement. Most of the concern seems to be that they would like to be able to incorporate whatever work is done in Bloodhound back into Trac but under a BSD license. I'm not sure why they have concerns about incorporating Apache licensed code but simply working something out could be helpful. I suspect hosting this project in git would also help. Ralph On Jan 2, 2012, at 4:26 PM, Greg Stein wrote: On Sun, Jan 1, 2012 at 06:34, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: The Incubator proposal was publicized and discussed on trac-dev *simultaneously* with the discussion on general@incubator, and the reception was generally indifferent (as Greg mentioned earlier) To add some pointers to this, the trac-dev discussion thread is at [1]. A related vote was just called at [2]. The question about the fork status was also brought up [3] on general@ during discussion, and was IMHO answered pretty well [4]. Obviously the fear of this being seen as a hostile fork did become reality at least for some, so I guess there's a lesson here for us all. Note that the Trac principals suggested the fork with a let's see where it goes view. It is just a few of the other committers that are taking issue with Bloodhound. This can be seen simply by reading the thread on trac-dev. I think it important to highlight that trac-dev was notified on Dec 2 of the Bloodhound proposal, but Ethan and others didn't even notice for three weeks. The activity level on trunk, and the active committers can be seen on Ohloh: http://www.ohloh.net/p/trac/contributors?sort=latest_commit Looking at the timeline on trac.edgewall.org, it seems many of the commits are release-related or possibly on dev branches. It is kind of hard to tell. Trunk is certainly minimal activity. Christian is the most active committer (http://www.ohloh.net/p/trac/contributors/13108240188505) and has been supportive of the Bloodhound effort. When I looked at this, a number of months ago, I never felt that we were forking an active project. The Trac community revolves mostly around the plugins rather than the core. I see Bloodhound as improving the core facilities (new features and hauling in certain plugins), resulting in a better default distribution (right now, you need to add a dozen plugins to get a useful Trac install). This kind of work has not been happening on the (core) Trac project. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Jan 2, 2012, at 11:15 PM, Greg Stein wrote: On Jan 2, 2012 10:51 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. Eh? You ever read the rules for revolutionaries page? The basic concept is: don't try to force two communities into one; when separate visions for the project occur, then separate them. I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. We provide a temporary home in the Incubator to see if it can become a good, proper, and healthy Apache community. We don't turn them away a-priori based on their history. Greg, this seems to be so much B.S as it apparently serves some particular interest you have. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. In my mind, the Trac core has slowed, and it needs revitalization and a new vision. Others may disagree, and do, and that's fine. But I don't think it is fine for us to make judgements of communities (or nascent ones!) who want to try something new. To pick up and go in a direction that others are not heading, or do not have the time to make. I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
FWIW, this link was used by Sam during the discussion I referred to below - http://s.apache.org/QeN Ralph On Jan 2, 2012, at 11:29 PM, Ralph Goers wrote: On Jan 2, 2012, at 11:15 PM, Greg Stein wrote: On Jan 2, 2012 10:51 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. Eh? You ever read the rules for revolutionaries page? The basic concept is: don't try to force two communities into one; when separate visions for the project occur, then separate them. I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. We provide a temporary home in the Incubator to see if it can become a good, proper, and healthy Apache community. We don't turn them away a-priori based on their history. Greg, this seems to be so much B.S as it apparently serves some particular interest you have. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. In my mind, the Trac core has slowed, and it needs revitalization and a new vision. Others may disagree, and do, and that's fine. But I don't think it is fine for us to make judgements of communities (or nascent ones!) who want to try something new. To pick up and go in a direction that others are not heading, or do not have the time to make. I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that. Ralph
Re: [VOTE] Bloodhound to join the Incubator
On Jan 3, 2012, at 12:02 AM, Greg Stein wrote: As a person wanting to see Apache Bloodhound take off... yeah, I'm making a judgement call on whether that can better occur at the ASF instead of within the current Trac community. (fwiw, some of the ideas are non-starters for Trac, so the *only* solution is do it outside the core project). I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor. My suggestion is to simply continue working with them to either allay any fears they may have and possibly find a way to easily share the core code. If that doesn't work then I think perhaps you need to have a discussion at the next board meeting about how to resolve it. If it ends up that the actual Trac developers are OK with this or simply don't care then that would seem to me to be equivalent to them giving their approval. I haven't checked who has commented against the list of developers. In the end, I would also like to see Bloodhound move forward. However, I believe we need to be careful what precedents we are setting when these kinds of issues arise. You seem to be of the opinion that getting any project that wants to come to the ASF going is what is of importance. Mine is that we need to do that while respecting the rest of the open source community. Ralph
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote: The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY. And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community. If a corporation were to create an ASF-licensed codebase, and later decide to take back control, would we refuse a COMMUNITY-based project based on that codebase? The answer to that is yes. It has happened. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 7, 2012, at 8:05 AM, Sam Ruby wrote: On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote: The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY. And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community. If a corporation were to create an ASF-licensed codebase, and later decide to take back control, would we refuse a COMMUNITY-based project based on that codebase? The answer to that is yes. It has happened. As always, the answer is a bit more subtle than that. More typically, what happens is somebody asks a few questions. Then the people who were pushing the idea realize that that they don't have answers. A bit of time passes. Then those who were originally pushing the idea state that they weren't allowed because some unnamed they wouldn't let them. It isn't my intention to drag in a different set of parties, which is why I haven't linked to messages on other lists. However, what you say above isn't my recollection at all. As always, Roy gave a refreshingly clear answer which I quoted several days ago. You then more or less backed that up by saying the i's had to be dotted, the t's crossed and to document what was being done. Then be prepared to answer hard questions. You finished with Matters of law are non-negotiable. Matters of policy are. However you had better have a solid reason and a d**n good plan before you challenge an established policy like everything here is a voluntary contribution. Search the archives. For example, look at earlier versions of the Apache License. It is a part of our DNA and who we are at this point. It is not something we are going to change lightly. While your answer was not as crystal clear as Roy's you said multiple times - go get a software grant. Our response was, We aren't going to bother because we know we won't get one. I am not sure why you are backing off from this now. I have no problem with this policy. I just wish it was written down on the How it works page and then applied uniformly. To see current directors who have all been members of the foundation for a long, long time rendering different opinions on what the policy is isn't helpful. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
I'm not worried about a mentor that can't write a decent report. I want a podling that can write a decent report. I'm much more worried when the mentor can't prod the podling to write a report, and doesn't review it or sign it when they do. If the podling submits a poor report that is evidence enough that the mentors need a bit of education. Ralph On Jan 10, 2012, at 2:26 PM, Joe Schaefer wrote: It's not about blame, it's about tangible, recorded demonstrations of oversight. As I said elsewhere we place no conditions on mentors when they sign up to mentor a podling, and I think that is part of the problem we face here. A podling will be able to report about a poor report from a mentor easily enough, we don't need to police each other all that much. We do need to start actively collaborating tho, and we can't do that without ensuring there's actual participation. - Original Message - From: Marcel Offermans marcel.offerm...@luminis.nl To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, January 10, 2012 5:21 PM Subject: Re: Small but otherwise happy podlings I see your point. I still think that if you read a bad report it does not matter who wrote it, in the end you can still blame the mentors because it's their responsibility. Who wrote it is not that relevant to me. On Jan 10, 2012, at 23:10 , Joe Schaefer wrote: The thing is there is no way to tell whether or not a mentor is even CAPABLE of writing a status report for a podling if the podling is immediately tasked with doing so themselves. We are in the boat we are in now because we have for too long assumed any member who offered to mentor a podling was ready, able, and willing to do a decent job of it. Without putting any feedback loops into the system for determining whether mentors are performing their job well we will never be able to move to a system that's both providing proper oversight organizationally and distributing trust to the mentors who are providing it. - Original Message - From: Marcel Offermans marcel.offerm...@luminis.nl To: general@incubator.apache.org Cc: antel...@apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Tuesday, January 10, 2012 5:03 PM Subject: Re: Small but otherwise happy podlings Whilst I agree there is value in demonstrating a starting podling what a good report should look like by doing it for them, I also strongly believe in learning by doing, so I would still propose that a podling has a go at it themselves, before having a mentor step in. In the end, this is also a question of mentoring style and I think we should leave that up to the mentors and podlings. A mentor should be actively involved in the discussion about the report though, ensuring that the end result is good. Greetings, Marcel On Jan 10, 2012, at 22:52 , Joe Schaefer wrote: I don't know about you, but in the podlings I mentor I am subscribed to most if not all of the mailing lists and try to read the bulk of it all. I could easily write status reports for them if it was my responsibility to do so, and for the initial 6 months would prefer that mentors showed their podlings and their fellow mentors what can be done with a properreport before passing that duty along to the PPMC. - Original Message - From: ant elder ant.el...@gmail.com To: general@incubator.apache.org Cc: Sent: Tuesday, January 10, 2012 4:47 PM Subject: Re: Small but otherwise happy podlings I like the idea of mentors being expected to signoff on the wiki just to show that they are paying attention, but i also agree that it might be useful to have along with the poddling reports to have comments from the mentors. So how about doing both? Just extend the mentor signoff section to include comments so a poddling report is the poddling comments, mentor comments about whats going on and what they'd like to see the poddling doing in the next months and a signoff from all active mentors. Or Joe are you saying that we should scrap the poddling comments bit entirely? I think its useful to get a quick overview of whats going on and it gets them used to the TLP board report requirement. ...ant On Mon, Jan 9, 2012 at 6:27 PM, Joe Schaefer joe_schae...@yahoo.com wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a
Re: Improviing quarterly reports
On Jan 11, 2012, at 10:44 PM, William A. Rowe Jr. wrote: On 1/11/2012 11:54 PM, Daniel Shahaf wrote: On Thu, Jan 12, 2012, at 00:33, Noel J. Bergman wrote: Joe Schaefer wrote: Now lets look at the remainder- several projects with no report whatsoever This has been an issue. Perhaps we need to put some teeth in the requirement, such as closing down commit access until reports are posted? I don't have an issue with saying that a project that does not report by the assigned cut-off date has its commit access turned off until the report is posted. Or, perhaps to give weight to your view that Mentors need to be more involved, until after it is signed off by a Mentor? Is sending (satisfactory) reports to the IPMC the responsibility of the mentors or of the PPMC? The project. Which means, the PPMC collectively, including its mentors. Optimally the mentors lead the first few times to an incoming community who isn't familiar with our reporting goals. They can pick it up from there. The goal of incubation is for the PPMC to (gradually) assume all of the tasks that a TLP is responsible for. I would go a bit further. I think the mentors have the responsibility of saying Hey, where is the report for me to sign?. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On Jan 12, 2012, at 4:11 AM, Niclas Hedhman wrote: On Thu, Jan 12, 2012 at 2:47 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: I was thinking about this differently: mentors be responsible for ensuring IPMC has a complete picture, but normally the PPMC members write the reports. (Not unlike how, in a PMC, any PMC member might write the report but it's the Chair's responsibility to ensure it is complete and accurate.) And I want to throw in my pet peeve; 1 Mentor! One Responsible Mentor is better than 5 paper ones, and with a minimal work load (whatever that might be) the trimmed IPMC (also good idea) will know quickly when Mentor is AWOL, pretty much like Board sees missing PMC Chairs. I disagree. Everybody gets busy from time to time. But a podling doesn't need 5 mentors. It is also helpful to have three mentors who are on the IPMC since it makes it easier to get a release vote to pass if all 3 mentors are active. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
You know, you have 4 mentors all of whom are supposed to be IPMC members. Have they voted? Ralph On Jan 14, 2012, at 10:17 AM, Eric Yang wrote: This is a reminder to vote Chukwa 0.5.0 release candidate 3. We are still missing 2 IPMC votes to close this vote. If someone could take a look, it would be greatly appreciated. regards, Eric On Wed, Jan 11, 2012 at 12:55 PM, Chris Douglas cdoug...@apache.org wrote: +1 (binding) Checksum and signature match, verifications from previous RCs hold b/c only NOTICE and LICENSE have changed. -C On Mon, Jan 9, 2012 at 10:09 PM, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc3/ Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc2: - Updated LICENSE and NOTICE files to reflect changes base on Sebb's examples. The vote will close at 12:30pm PST on Saturday January 14, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
+1 (binding) Everything looks fine and the build worked for me. However, I do find it odd that the online documentation references a binary distribution yet none is present on the web site below. On Jan 14, 2012, at 10:17 AM, Eric Yang wrote: This is a reminder to vote Chukwa 0.5.0 release candidate 3. We are still missing 2 IPMC votes to close this vote. If someone could take a look, it would be greatly appreciated. regards, Eric On Wed, Jan 11, 2012 at 12:55 PM, Chris Douglas cdoug...@apache.org wrote: +1 (binding) Checksum and signature match, verifications from previous RCs hold b/c only NOTICE and LICENSE have changed. -C On Mon, Jan 9, 2012 at 10:09 PM, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc3/ Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc2: - Updated LICENSE and NOTICE files to reflect changes base on Sebb's examples. The vote will close at 12:30pm PST on Saturday January 14, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
Did you every get another vote? Ralph On Jan 19, 2012, at 10:46 PM, Eric Yang wrote: Still missing one IPMC vote. Could someone help out? regards, Eric On Tue, Jan 17, 2012 at 12:06 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/15/2012 1:42 AM, Ralph Goers wrote: You know, you have 4 mentors all of whom are supposed to be IPMC members. Have they voted? Nope, traveling, and now back in project hell at one of my own homes. I did review the Chukwa monthly report and comment on several apparent issues on dev@. I don't expect to have time to review this specific candidate, owing to a backlog of work accumulated over this short vacation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
Now you have me worried. This podling has 4 mentors listed. Only 1 voted on the release. You indicated you were too busy to look at it and the other two didn't participate at all. Although the tally below is obviously incorrect and needed to be corrected, your response leads me to believe you weren't monitoring the voting on chuckwa-dev. My worry isn't about the PPMC or committers but about whether this podling has sufficient mentors. Is everything being left to Chris? Mind you, I don't follow chuckwa-dev so perhaps my perception is incorrect, but a podling should normally be able to get 3 IPMC votes just from its mentors. Ralph Sent from my iPad On Jan 26, 2012, at 1:04 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/25/2012 11:49 PM, Eric Yang wrote: The voting period is now closed. Thanks to everyone who took the time to review the release. Result Summary for this List: +1 [1] 0[1] -1[0] With the one IPMC member vote from mentors on the dev list and two +1 from general@incubator, the vote succeeds. IPMC member voting record: Chris Douglas:+1 Ralph Goers: +1 Ant Elder: +1 I am very confused by your tally above. you cite [1] in brackets and there are three votes +1 between PPMC and IPMC. I'm very worried that, sans mentors, this PPMC can't muster three votes for a candidate. I think it might be premature to release and is a very long way from graduation. Please don't summarize simply IPMC binding votes, but cover all categories, most especially chukwa-dev community votes. Repost with the correct totals, because we [Incubator PMC] need that to gauge the health of the project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
On Jan 26, 2012, at 4:38 PM, Marvin Humphrey wrote: On Thu, Jan 26, 2012 at 06:57:08AM -0500, Ralph Goers wrote: This podling has 4 mentors listed. Only 1 voted on the release. Situations like this seem to be common. My worry isn't about the PPMC or committers but about whether this podling has sufficient mentors. Perhaps the podling has an especially conscientious PPMC member or two who should be evaluated for IPMC membership, as discussed recently? http://s.apache.org/Y4B Mind you, I don't follow chuckwa-dev so perhaps my perception is incorrect, but a podling should normally be able to get 3 IPMC votes just from its mentors. If we can't scare up enough IPMC votes for a release, why not get them from people who are... * familiar with the podling's ongoing development * going to be entrusted with binding votes the instant the project graduates ... as soon as they demonstrate proper diligence and understanding of ASF procedures? i'd agree, but this was the podling's first release. The point have having mentors is to get them up to speed. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Regular rotation PMC chair
On Jan 28, 2012, at 6:20 PM, Noel J. Bergman wrote: Should the current chair be forced to resign I'm not going to make an issue of it. I didn't interpret this as directed at you but at what a new policy on regular elections of a PMC should be. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Regular rotation PMC chair
On Jan 28, 2012, at 5:15 PM, Alan D. Cabrera wrote: There's always the perennial chat here and there about rotating the PMC chair on a regular basis. It's my understanding that other PMCs have adopted this policy and are quite happy with it. It's also my understanding that some in this community think it would be a good idea to do it here. Good idea? What should be the term length? Should the current chair be forced to resign or can the person re-run for the next term? If forced to resign can the person re-run for a term sometime in the future? If not forced to resign is there a limit to the number of terms that can be held? I like the idea of an annual election so that there aren't any hard feelings. I personally have no problem with the same person being re-elected every year. This is pretty much what the members do with the board elections - some members have served for a long time while others rotate more frequently. Personally, I would prefer it if this was an across the board policy that applied to all PMCs. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOMINATIONS for Incubator PMC Chair
On Jan 29, 2012, at 12:00 PM, Deepal jayasinghe wrote: If he has not resigned, why do we have this vote (or why started this vote) ? forcing him to resign ? Because it is very poor practice, IMO, to just keep the same PMC chair in place forever without giving others the opportunity. This should not be a reflection on Noel and he should be allowed to be re-nominiated and accept if he chooses. This question is why I'd prefer a policy of just holding an election annually, even if it ends up just reconfirming the existing chair year after year. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Regular rotation PMC chair
On Jan 29, 2012, at 12:16 PM, Benson Margulies wrote: On Sun, Jan 29, 2012 at 2:23 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 29, 2012, at 6:18 AM, Ate Douma wrote: FTR: as should be clear from my above response, I disagree with the topic of this discussion thread. This should be about Regular (re)election of the PMC Chair. Regular rotation IMO would be unwise and undesirable. Good point. I share the same opinion. Let me try to state some alternatives: 1) No particular policy: The PMC has no special policy about recommending a new chair to the board. It will happen if the chair resigns, or if the PMC as a whole reaches a consensus on a change. 2) Fixed election schedule: On some schedule (e.g. annually), nominations are opened, including potentially the current chair, and a vote takes place. (I'd hate to have to fire up the full secret ballot mechanism used for board members.) Whomever wins is recommended to the board. 3) Rotation policy: On some schedule, the PMC chooses a new chair to recommend to the board 'whether it needs one or not.' This could be viewed as 'term limits'. If we don't reach a consensus on something else, we stick with the current state of affairs, which is, I claim, (1). We could adopt both (2) and (3): purely for example, we could have an annual election, but a 5-year maximum on continuous service. My preference is option 2 alone. I don't see the point of term limits as I believe that will take care of itself. I'm not in favor of 1 because it always seems to end up feeling like it is personal when people bring up rotating the chair - i.e. isn't the current chair doing a good enough job, the current chair should say they want to resign first, etc., rather than it just being time to allow the PMC to reevaluate itself Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Regular rotation PMC chair
On Jan 30, 2012, at 4:29 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Jan 30, 2012 at 11:46 AM, Ate Douma a...@douma.nu wrote: ...I just realize something not clear from this proposal: are we *only* talking about the Incubator PMC Chair here, or is this a proposal for every PMC Chair? I presumed (and propose) the latter, but maybe that wasn't the intend (yet)... We're talking only about the Incubator PMC chair, no need to generalize this IMO and this list wouldn't be the right place anyway. Actually, I wish this was a policy that every PMC followed, but this is definitely the wrong list for that. However, simply having the incubator do it might be enough of an example to encourage other projects to do the same. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 11:12 AM, Greg Stein wrote: On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote: So that everyone affected by these proposals has the opportunity to engage in the discussion, I recommend that we pull these out of e-mail for a while and ask everyone who has a new plan for the incubator to draft proposals on the wiki as Chris did. At that point, we could have a bake-off discussion where the community has the ability to evaluate and chime in with their concerns/comments/suggestions. Funny you mention it, the Incubator itself was the product of a bake off between two proposed resolutions, still recorded in the board minutes :) http://www.apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt It is actually interesting reading those resolutions - although to be honest I didn't see much difference between them. I don't really see anything wrong with them. As I see it, the problem with the PMC isn't its charter but how it has chosen to carry it out. For example, requiring mentors to be IPMC members vs ASF members means constantly pinging the board with people who are coming and going who are interested in helping a podling succeed but who aren't really interested in running the incubator. I really see nothing wrong with having an incubator PMC whose job it is to monitor the podlings, make sure they have active mentors, are getting the help they need and then make a decision on graduating or retiring them. However, that PMC doesn't need more than a dozen people on it. Disbanding the PMC seems to me to be a very reactionary approach to the problem. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Evolution instead of a revolution (Was: Time to vote the chair?)
On Feb 3, 2012, at 4:20 PM, William A. Rowe Jr. wrote: On 2/3/2012 5:55 PM, Ralph Goers wrote: Disbanding the PMC seems to me to be a very reactionary approach to the problem. That's because disbanding the IPMC isn't in response to /that/ problem, so little wonder you are confused. Disbanding the IPMC, and making PPMC contributors part of their own committees, gives them voices in a process that they are locked out of. One recent response was to hand pick a select few of the PPMC contributors who went above and beyond, and give these exalted few individual membership in the IPMC, so their votes would be binding. And who said the IPMC had to fix the problem that way? Why is making a podling effectively a TLP with a PMC that reports to the board and a VP of incubation the only way to fix this? What is preventing us from allowing the PPMC to have much more control over what they do while preserving the IPMC? The rule that says a PMC created by the board has to have 3 votes for a release? This seems like a sledgehammer approach to fix that. After all, all the bylaws say about this is the PMC chair shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible. It would be perfectly reasonable to me for the IPMC to find other ways for a PPMC to have binding votes. But Roy has always been fond of saying that if you are creating the code you should be the one with voting privileges. All of 'you'. Making each 'podling' an actual committee, with additional restrictions due to their 'freshness' and new exposure to ASF culture, gives the core of each new podling the voice and authority to act on their own code. While each podling should be an actual committee, there is no reason they can't be sub-committees of the IPMC with the authority that has been delegated to them. And /that/ is the problem that we are trying to solve ;) I agree with that. I think everyone is saying it is stupid to require mentors to be IPMC members. So fix that. I'd prefer a structure where every PPMC had active and qualified mentors to help with community building and performing a release, and without having to go to the IPMC to add new committers or get a release approved. The purpose of the IPMC would then be to make sure each podling had active and qualified mentors, to add new podlings or terminate dead podlings and recommend graduation to the board. The main problem I see, and what Joe seems to complain about a lot, is that mentors seem to fail at mentoring. Creating a project that reports to the board whose mentors stop mentoring just pushes the problem to the board, which is IMO not what they should be having to deal with. Ralph
