Re: [PROPOSAL][VOTE] Subversion
+1 Ate > 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
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 (binding) Ate On 09/30/2013 09:27 PM, Dave wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web & mobile applications based on RESTful APIs, as an Apache Incubator podling. The original proposal has been revised to name Dave Johnson as the Champion and to bring Jim Jagielski back in as a Mentor and to add John Lewis Mcgibbney as a Mentor. I also add some text to the Initial Committers section and a new Interested Contributors section to list those who have expressed interest in contributing. Here is a link to the revised proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web & mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration & management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy & compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from a reference implementation they can deploy in trust, or extend to their needs without losing time writing less-vetted, less-performant boilerplate functionality. Usergrid has been open source since 2011 and has grown as an independent project, garnering 11 primary committers, 35 total contributors, 260+ participants on its mailing list, with 3,700+ commits, 200+ external contributions, 350+ stars and 100+ forks on Github, not to mention several large scale production deployments at major global companies in t
Re: September report
On 08-09-14 06:57, Roman Shaposhnik wrote: Hi! it looks like September report is almost done, except the following podlings: * Streams [ ](streams) Matt Franklin [ ](streams) Ate Douma [ ](streams) Craig McClanahan If there's any chance the above mentors can facilitate the report and later sign-off on it would be really appreciated. Hi Roman, I'm sorry about the missing Streams report. The problem here is that the current committers, while pretty much active on Streams itself, still have trouble getting it into their skull and planning to draft up a report themselves, so that we (mentors) can sign it off... Previous reports so far had to be drafted up by the mentors to get it done in time, despite repeated nudges. The last time we warned the committers we would do this no more: part of learning the ropes and working towards graduation is that they also learn to take up this responsibility themselves. Regrettably, they again failed to pick this up and clearly I'm annoyed and disappointed :( Hopefully though this blunder and the fact they should 'fix' this already for the report next month will finally make them realize this is not something they can keep overlooking. To be clear, IMO the Streams committers are actually making good progress with the project itself, so from that perspective I do not think the IPMC has much to be worried about. They just need some spanking to get their act together with respect for the Foundation :) So hopefully this direct feedback will be enough 'spanking' ;) and we'll see a proper report delivered and signed off the next month. Kind regards, Ate Thanks, Roman. P.S. The biggest help with the summary is tracking releases -- so if somebody can help with at least that -- it'll be perfect! - 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 Airavata from the incubator
+1 (Airavata Mentor) Ate On 09/08/2012 03:23 PM, Suresh Marru wrote: On Sep 7, 2012, at 12:11 PM, "Mattmann, Chris A (388J)" wrote: +1 from me! (binding) Great work guys! During the discussion I requested to be included on the PMC and there was also talk of Ross being there though. Cheers, Chris Hi All, Sorry for missing Chris's name in the resolution, we had couple of resolution drafts in parallel and bad miss on my part in merging them. Chris's willing and rest of PMC's approval is recorded in discussion and associated JIRA. Please vote on the resolution, everything else is the same with addition of Chris Mattmann to the initial PMC. Will leave the vote open 72 hours from now. Just for clarity I am copying the vote the full resolution again: -- X. Establish the Apache Airavata Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to executing and managing computational jobs on distributed computing resources including local clusters, supercomputers, national grids, academic and commercial clouds and for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Airavata Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Airavata Project be and hereby is responsible for the creation and maintenance of software related to executing and managing computational jobs on distributed computing resources including local clusters, supercomputers, national grids, academic and commercial clouds; and be it further RESOLVED, that the office of "Vice President, Apache Airavata" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Airavata Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Airavata Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Airavata Project: Aleksander Slominski Ate Douma Chathura Herath Chris Mattmann Eran Chinthaka Srinath Perera Heshan Suriyaarachchi Lahiru Gunathilake Marlon Pierce Patanachai Tangchaisin Raminderjeet Singh Saminda Wijeratne Shahani Weerawarana Suresh Marru Thilina Gunarathne NOW, THEREFORE, BE IT FURTHER RESOLVED, that Suresh Marru be appointed to the office of Vice President, Apache Airavata, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Airavata PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Airavata Project; and be it further RESOLVED, that the Apache Airavata Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Airavata podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Airavata podling encumbered upon the Apache Incubator Project are hereafter discharged. -- On Sep 7, 2012, at 3:58 AM, Suresh Marru wrote: Hi All, Since entering Incubation in May 2011, the Airavata community has evolved and has been steadily growing. The project has made 3 releases, added 6 new committers and PPMC members. The podling has been very actively using mailing list and JIRA and all communication is in open. Thanks to very hands-on mentors, the project has learned to self-govern and has been following the Apache Way. The project incubator status page [1] is up to date and trademarks has approved Airavata as a name for TLP [2]. The community has discussed graduation and prepared a board charter [3]. The initial PMC has been opted in on the private mailing list and PMC chair has been elected on the dev list [4]. The community feels ready to graduate [5] and voted 19 positives vo
Re: [VOTE] Graduate Wookie podling from the incubator
+1 Ate On 10/24/2012 08:32 PM, Scott Wilson wrote: This is a call for vote to graduate the Wookie podling from Apache Incubator. Wookie entered the Incubator in July of 2009. During incubation, Wookie has: * Produced 5 releases * Added 3 new Committer/PPMC members * Cleared IP on all donations * Learned to self-govern and engage the community * Received and applied multiple community patches The Wookie community has voted to proceed with graduation [1] and the result can be found at [2]. Please VOTE on the resolution below: [ ] +1 Graduate Wookie from the Incubator per the resolution below. [ ] +0 Don't care. [ ] -1 Don't graduate Wookie from the Incubator because.. This vote will be open for at least 72 hours. [1] http://markmail.org/message/jcgdcacn535jqwqy [2] http://markmail.org/message/hp2bggjhec7vpdch == X. Establish the Apache Wookie Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to an implementation of the W3C Widgets family of specifications for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Wookie Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Wookie Project be and hereby is responsible for the creation and maintenance of software related to implementation of the W3C Widgets family of specifications; and be it further RESOLVED, that the office of "Vice President, Apache Wookie" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Wookie Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Wookie Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Wookie Project: * Scott Wilson * Ate Douma * Ross Gardler * Matt Franklin * Paul Sharples * Kris Popat * Raido Kuli * Hoang Minh Tien NOW, THEREFORE, BE IT FURTHER RESOLVED, that Scott Wilson be appointed to the office of Vice President, Apache Wookie, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Wookie PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Wookie Project; and be it further RESOLVED, that the Apache Wookie Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Wookie podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Wookie podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Streams as an Incubator Project
+1 (binding) Ate On 11/14/2012 01:37 PM, Franklin, Matthew B. wrote: Given the feedback received so far I think the Streams proposal is in good shape so I am calling for a vote to accept Streams into the Incubator. The proposal is at: http://wiki.apache.org/incubator/StreamsProposal and also copied as text below. Please vote. [ ] +1 Accept Streams into the incubator [ ] +0 Don't care' [ ] -1 Reject for the following reason: I'll close the vote at Monday morning on November 19th EST. - COPY OF PROPOSAL FROM http://wiki.apache.org/incubator/StreamsProposal - Apache Streams Proposal == Abstract == Apache Streams will be a lightweight server for ActivityStreams. The role of Apache Streams is to provide a central point of aggregation, filtering and querying for Activities that have been submitted by disparate systems. Apache Streams also intends to include a mechanism for intelligent filtering and recommendation to reduce the noise to end users. == Proposal == Apache Streams will bring together individuals who are or are looking to increase and centralize the production, consumption and federation of ActivityStreams throughout enterprise organizations and the Internet as a whole. The target features include: * Publication of Activities from multiple systems via HTTP * Aggregation and syndication of streams * Support for security trimming of streams by social graph * Noise reduction and intelligent filtering * Federation of streams across disparate systems * Provide libraries for easy integration in source systems == Background == The ActivityStreams specification standardizes a generic format for describing event-based data. Many social web companies have adopted the format and it has been included in the OpenSocial specification as the preferred method for delivery of activity data. During discussions of ActivityStreams at OpenSocial events earlier in the year, it became clear that multiple organizations are facing similar issues as to the publication and filtering of their activities and would benefit from a commonly-developed, open-source ActivityStreams server. == Rationale == In deployment, activities are generated from multiple sources. This is particularly true within the enterprise where disparate systems create and manage activities in stove pipes. What is needed is a central point for consumption, aggregation and exposure of activities generated within these systems. == Initial Goals == The initial goal of the project is to survey donated code and develop a common, high-level architecture for an initial release. The project will then work toward that release in a new code base, pulling in pieces of donated code as necessary. == Current Status == The MITRE Corporation will donate its prototype code to the project. Aside from this, the project is new and will need bootstrap time to develop an initial architecture and roadmap. Meritocracy As a new project with many team members who are seasoned Apache veterans, Apache Streams is prepared to build the project under the Apache Way. Community The Apache Streams community combines multiple individuals from different organizations, many of which have collaborated before in an open environment. Apache Streams is committed to expanding this community and adhering to Apache principles of openness and collaboration. == Known Risks == An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are recognized and noted then they can be addressed during incubation. Inexperience with Open Source Most of the initial committers have worked in open source and many are familiar with the ASF and the Apache Way; but, not all. Additionally, many of the committers have not worked on a software project together and will need time to familiarize themselves with each other. Speed of Development This project is dependent upon contributions made on company time. For this approach to succeed, the project must deliver a workable system in a timeframe acceptable to those companies. The initial parties have the intention of releasing a first version within 6 months after starting the Incubator. Failure to do so could prevent the project reaching critical mass, and could prevent the project from being in a position to attract new developers. Reliance on Salaried Developers At present, the vast majority of contributors will be doing so as a part of their day jobs. Therefore, as already alluded to, there is a risk that the project won't gain enough traction to be of use to their employers. However, given the centrality of these codebases to the participating companies, it is clearly in their best interests to transition to an openly developed alternative. Relationships with Other Apache Products Many of the initial committers will be integrating this software with Apache Rave & Apache Shindig. A po
Re: [PROPOSAL] Apache Steams Project
Hi Davide, You will need to create a wiki account and thereafter request write access here. For your convenience I've already added your name to the initial committers section of the proposal. If your are participating on behalf of a employer, please let us know so we can add that to the affiliation section of the proposal as well. Kind regards, Ate On 11/14/2012 01:41 PM, Davide Palmisano wrote: Thanks Matthew, but the page is an immutable one. how can I do? cheers, Davide On Wed, Nov 14, 2012 at 12:14 PM, Franklin, Matthew B. wrote: -Original Message- From: Davide Palmisano [mailto:dpalmis...@gmail.com] Sent: Tuesday, November 06, 2012 12:17 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Apache Steams Project Hi there, I'm working to something[1] (not yet fully open source released) which could somehow overlap with Streams. I'm also one of the authors of the Activity Streams Ontology[2] which is the rdf-ish version of activitystrea.ms. I'll be really happy to contribute on Streams. Feel free to add yourself as an initial committer to the proposal on the wiki. cheers, [1] http://www.slideshare.net/dpalmisano/semtech2012-finalpdf [2] http://xmlns.notu.be/aair/ On Tue, Nov 6, 2012 at 6:06 PM, Franklin, Matthew B. wrote: I would like to propose a new Activity Streams server project to the Incubator. The proposal is on the wiki at the following location: http://wiki.apache.org/incubator/StreamsProposal Streams is a collaborative effort from multiple organizations and individuals working with and around the Activity Streams specification (http://activitystrea.ms). We are looking forward to your feedback and suggestions. -Matt Franklin - COPY OF PROPOSAL FROM http://wiki.apache.org/incubator/StreamsProposal - Apache Streams Proposal == Abstract == Apache Streams will be a lightweight server for ActivityStreams. The role of Apache Streams is to provide a central point of aggregation, filtering and querying for Activities that have been submitted by disparate systems. Apache Streams also intends to include a mechanism for intelligent filtering and recommendation to reduce the noise to end users. == Proposal == Apache Streams will bring together individuals who are or are looking to increase and centralize the production, consumption and federation of ActivityStreams throughout enterprise organizations and the Internet as a whole. The target features include: * Publication of Activities from multiple systems via HTTP * Aggregation and syndication of streams * Support for security trimming of streams by social graph * Noise reduction and intelligent filtering * Federation of streams across disparate systems * Provide libraries for easy integration in source systems == Background == The ActivityStreams specification standardizes a generic format for describing event-based data. Many social web companies have adopted the format and it has been included in the OpenSocial specification as the preferred method for delivery of activity data. During discussions of ActivityStreams at OpenSocial events earlier in the year, it became clear that multiple organizations are facing similar issues as to the publication and filtering of their activities and would benefit from a commonly-developed, open-source ActivityStreams server. == Rationale == In deployment, activities are generated from multiple sources. This is particularly true within the enterprise where disparate systems create and manage activities in stove pipes. What is needed is a central point for consumption, aggregation and exposure of activities generated within these systems. == Initial Goals == The initial goal of the project is to survey donated code and develop a common, high-level architecture for an initial release. The project will then work toward that release in a new code base, pulling in pieces of donated code as necessary. == Current Status == The MITRE Corporation will donate its prototype code to the project. Aside from this, the project is new and will need bootstrap time to develop an initial architecture and roadmap. Meritocracy As a new project with many team members who are seasoned Apache veterans, Apache Streams is prepared to build the project under the Apache Way. Community The Apache Streams community combines multiple individuals from different organizations, many of which have collaborated before in an open environment. Apache Streams is committed to expanding this community and adhering to Apache principles of openness and collaboration. == Known Risks == An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are recognized and noted then they can be addressed during incubation. Inexperience with Open Source Most of the initial committers have worked in open source and many are familiar with the ASF and the Apache Way; but, not all.
Re: Ripple, Streams, Onami, HDT need to fix your metadata
I've removed the monthly schedule for Streams too. Not sure how about updating the site though, can't find instruction how to trigger that, if even needed? Thanks, Ate On 03/05/2013 08:15 AM, David Crossley wrote: Ripple, Streams, Onami, Hadoop Development Tools ... Those projects would have received the email reminder about reporting. You need to care for your podling metadata in the content/podlings.xml file to take yourself off the monthly schedule and onto quarterly. (Unless you do want to keep doing monthly.) See column C and the help notes below the table: http://incubator.apache.org/clutch.html This file http://incubator.apache.org/report-groups.txt and http://incubator.apache.org/report_due_3.txt are generated from that content/podlings.xml file and are used to automate the reminders and other stuff. -David David Crossley wrote: Dave Fisher wrote: Hey Folks, Etch has graduated and is now a TLP, correct? It's board reports should now go directly to board@ from the PMC chair. As explained in the Incubator graduation docs, the Etch project needs to finalise their graduation steps. http://incubator.apache.org/clutch.html#etch http://incubator.apache.org/clutch.html#other http://incubator.apache.org/clutch.html#h-Graduate -David Regards, Dave Begin forwarded message: From: Marvin Date: March 4, 2013 4:18:48 AM PST To: d...@etch.incubator.apache.org Subject: Incubator PMC/Board report for Mar 2013 ([ppmc]) Reply-To: d...@etch.apache.org delivered-to: mailing list d...@etch.apache.org delivered-to: moderator for d...@etch.apache.org Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 March 2013, 10:30:00:00 PST. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, Mar 6th). Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/March2013 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ripple, Streams, Onami, HDT need to fix your metadata
On 03/05/2013 01:47 PM, David Crossley wrote: Ate Douma wrote: I've removed the monthly schedule for Streams too. Not sure how about updating the site though, can't find instruction how to trigger that, if even needed? After making source changes, then i just go to https://cms.apache.org/incubator/publish to publish the generated changes when they are ready. I did that now. Thanks! The next time that someone runs Clutch (there are notes on that page) then it will pull together any pending metadata changes. Ah, I now see those build notes on the Clutch page itself, noted for next time. I was looking for something in the README.txt in the source tree. -David On 03/05/2013 08:15 AM, David Crossley wrote: Ripple, Streams, Onami, Hadoop Development Tools ... Those projects would have received the email reminder about reporting. You need to care for your podling metadata in the content/podlings.xml file to take yourself off the monthly schedule and onto quarterly. (Unless you do want to keep doing monthly.) See column C and the help notes below the table: http://incubator.apache.org/clutch.html This file http://incubator.apache.org/report-groups.txt and http://incubator.apache.org/report_due_3.txt are generated from that content/podlings.xml file and are used to automate the reminders and other stuff. -David David Crossley wrote: Dave Fisher wrote: Hey Folks, Etch has graduated and is now a TLP, correct? It's board reports should now go directly to board@ from the PMC chair. As explained in the Incubator graduation docs, the Etch project needs to finalise their graduation steps. http://incubator.apache.org/clutch.html#etch http://incubator.apache.org/clutch.html#other http://incubator.apache.org/clutch.html#h-Graduate -David Regards, Dave Begin forwarded message: From: Marvin Date: March 4, 2013 4:18:48 AM PST To: d...@etch.incubator.apache.org Subject: Incubator PMC/Board report for Mar 2013 ([ppmc]) Reply-To: d...@etch.apache.org delivered-to: mailing list d...@etch.apache.org delivered-to: moderator for d...@etch.apache.org Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 March 2013, 10:30:00:00 PST. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, Mar 6th). Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/March2013 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - 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 - 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
Re: [VOTE] Accept Apache BeanShell in the Incubator
+1 (binding) Regards, Ate On 05/24/2013 09: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 , * Patrick Niemeyer * Pedro Giffuni * Simone Tripodi == 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 absolutely aware of our already established role in the wide JSR-274 community. Furthermore, we are convinced that we can enthusiastically bring inside the ASF new and fresh energies in order to i
Re: Looking for a Champion
On 06/05/2013 04:12 PM, Mohammad Nour El-Din wrote: +1 @Marcel Any links for the draft proposal so people can assess if they can help or not ? He is asking for help (Champion) to create such a draft :) On Wed, Jun 5, 2013 at 4:07 PM, Marcel Offermans < marcel.offerm...@luminis.nl> wrote: I would never search for a generic job scheduling application in the Wicket project. I still don't know exactly what this new project is about, but the fact that it happens to use Wicket in itself is not enough to make it a Wicket subproject if you ask me. Greetings, Marcel On Jun 5, 2013, at 16:01 PM, Alexei Fedotov wrote: Could it be a part of Apache Wicket? -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Wed, Jun 5, 2013 at 5:33 PM, Andy Van Den Heuvel wrote: Hey Alexei, Yes, it does. On Wed, Jun 5, 2013 at 3:20 PM, Alexei Fedotov < alexei.fedo...@gmail.com>wrote: Andy, It uses Apache Wicket, doesn't it? -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Wed, Jun 5, 2013 at 4:42 PM, Andy Van Den Heuvel wrote: Jenkins is a continuous integration server, it provides integration with SCM, Build Automation, Testing... This proposal is for a multi-purpose tool, providing support for Monitoring, Backup's,Process Automation, (also Continuous Integration though) The architecture is very different. The idea behind this has come up of using Hudson/Jenkins for several years. On Wed, Jun 5, 2013 at 2:25 PM, Simon Lucy wrote: Andy Van Den Heuvel wrote: I'm looking for a Champion to help me setup a proposal. The project is a pluggable all-round job scheduling application. Not to be a killjoy but how is it different to Hudson/Jenkins? S Can somebody help me? Thanks for your consideration. --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org< general-unsubscr...@incubator.apache.org> For additional commands, e-mail: general-help@incubator.apache. **org< 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 - 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 Stratos proposal as an incubating project
On Jun 14, 2013 11:50 PM, "Ross Gardler" wrote: > > I would like to invite the IPMC vote to accept the Stratos proposal [1]. > > I want to clarify that this vote is for the Stratos project to enter > the incubator as a standard podling under the existing incubation > policy. The acceptance or otherwise of the probationary TLP idea is a > separate issue that will be explored during the first month of > incubation, potentially resulting in a further IPMC vote. > > This vote is *only* for accepting the Stratos project as a podling. > > [ ] +1 Accept the Stratos project as an incubating project > [ ] +0 > [ ] -1 Do not accept the Stratos project as an incubating project > because... (provide reason) > +1 (binding) Ate > It's late on Friday evening here in the UK. I'll let this vote run > well into next week to allow for the weekend. > > Thank you for your votes. > Ross > > - > 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
+1 Ate On 30/11/10 07:52, 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-backward&page=2 The vote options: [ ] +1 Accept Wave for incubation [ ] +0 Don't care [ ] -1 Reject for the following reason: The vote is open for 72 hours. Thanks, -Dan Apache Wave Proposal (Apache Incubator) = Abstract = Apache Wave is the project where wave technology is developed at Apache. Wave in a Box (WIAB) is the name of the main product at the moment, which is a server that hosts and federates waves, supports extensive APIs, and provides a rich web client. This project also includes an implementation of the Wave Federation protocol, to enable federated collaboration systems (such as multiple interoperable Wave In a Box instances). = Proposal = A wave is a hosted, live, concurrent data structure for rich communication. It can be used like email, chat, or a document. WIAB is a server that hosts waves. The best analogy for this is a mail server with a web client. WIAB is comprised of a few high-level components: the client and the server. They have the following major functionality (though this is not an exhaustive list): * Client *A dynamic web client for users to create, edit, and search waves. Users can access this client by directly visiting the server in a browser. * Gadgets provide the ability to insert, view, and modify the UI -- exposing the Wave Gadgets API ( http://code.google.com/apis/wave/extensions/gadgets/guide.html) * A console client that can create and edit waves via a command-line-like interface. * Server * Hosts and stores waves. WIAB comes with a default storage mechanism. The administrators of the server may configure it to use alternative storage mechanisms. * Indexing, allowing for searching the waves a user has access to. * Basic authentication, configurable to delegate to other systems. * Federation, allowing separate Wave in a Box servers to communicate with each other using the Wave Federation Protocol ( http://www.waveprotocol.org/federation). * Robots, using the Wave Robots API, ( http://code.google.com/apis/wave/extensions/robots/) may interact with waves on a WIAB instance. = Background = Wave expresses a new metaphor for communication: hosted conversations. This was created by Lars and Jens Rasmussen after observation of people's use of many separate forms of communication to get something done, e.g, email, chat, docs, blogs, twitter, etc. The vision has always been to better the way people communicate and collaborate. Building open protocols and sharing code available in an open and free way is a critical part of that vision. Anyone should be able to bring up their own wave server and communicate with others (much like SMTP). We hope this project will allow everyone to easily gain the benefits of Wave with a standard implementation of Wave – in a box. = Rationale = Wave has shown it excels at small group collaboration when hosted by Google. Although Wave will not continue as a standalone Google product, there is a lot of interest from many organizations in both running Wave and building upon the technology for new products. We are confident that with the community-centric development environment fostered by the Apache Software Foundation, WIAB will thrive. = Initial Goals = The initial goals of the project are: 1. To migrate the codebase from code.google.com and integrate the project with the ASF infrastructure (issue management, build, project site, etc). 1. To quickly reach a state where it is possible to continue the development of the Wave In a Box implementation under the ASF project. 1. To add new committers to the project and grow the community in "The Apache Way". = Current Status = The open source Wave in a Box project has existed in various forms for approximately 16 months (starting out life as the FedOne open source project). FedOne began in July 2009 in order to accelerate adoption of the wave federation protocol, and serve as a proof of concept that a non-Google implementation of the wave federation protocol could interoperate with the Google production instance. It worked. FedOne's existence lead to a prototype by Novell that demonstrated federation between Google Wave and Novell Pulse (now known as Vibe). In addition, in May of 2010, SAP unveiled a prototype version of SAP StreamWork that federated with both Novell Pulse and Google Wave. All three systems interoperated, sharing real-time state, and gadget updates. In May 2010 Google released significantly more code (including the cross-browser rich text editor) to connect with oth
[PROPOSAL] Apache Rave project
I would like to propose the Apache Rave project to the Incubator PMC. Our draft proposal is appended to the end of this email and is available at: http://wiki.apache.org/incubator/RaveProposal The Apache Rave project proposal is a joined effort of Hippo, the MITRE Corporation, the Open Gateway Computing Environments project (OGCE), the SURFnet SURFConext Portal project, OSS Watch, and several other individuals. == 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 OpenSocial container and services the (Java) Apache Shindig will be integrated. At a later stage further generalization is envisioned to also transparently support W3C Widgets using Apache Wookie. - We are looking forward to your feedback and suggestions. Kind regards, Ate Douma - 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 W
Re: [PROPOSAL] Apache Rave project
On 24/02/11 09:49, Bertrand Delacretaz wrote: On Wed, Feb 23, 2011 at 8:49 PM, William A. Rowe Jr. wrote: On 2/21/2011 5:18 PM, Ate Douma wrote: The Apache Rave project proposal is a joined effort of Hippo, the MITRE Corporation, the Open Gateway Computing Environments project (OGCE), the SURFnet SURFConext Portal project, OSS Watch, and several other individuals. Keep in mind that only individuals participate at Apache, sometimes independently, sometimes as employees, but ASF projects are collaborations of developers (and docs and users, but principally of developers). This might be part of the reason for some [dis]quiet to the proposal Ate wrote the above in his mail but that's not part of the proposal at http://wiki.apache.org/incubator/RaveProposal Indeed. I initiated a plan for a project like this back at the ApacheCON last November, seeking interest for it on several developer mailing lists, talked about it at the European OpenSocial Event last December and discussed it further at the OpenSocial 2.0 kickoff in Moutain View later that month. That triggered several representatives (developers) of the now involved organizations and projects to meetup and join the effort. The organizations behind this proposal needed to be involved as large code donations are provided so they'll have to provide the appropriate SGAs. And they'll provide the needed CCLAs for their employees involved, The reasons behind it has been discussed and explained in much detail. Everyone is well aware of the principals of meritocracy, including the fact they (as organizations) cannot and will not have formal control on the way how the project moves forward. If you really read the proposal, you'll even find explicit agreement and understanding that possibly nothing of an initial code donation may "survive" in this project. Something which will be decided by the project members (developers) themselves, not the organizations behind it. I think that statement and agreement strongly reflects everyones awareness and understanding of "how it works". For just about any Incubator project proposal there is one or more organizations involved because of the SGAs and CCLAs needed. And in this case, there are many, and much more than usual I'd say. Which I'm actually very exited about, it clearly shows their already is a strong interest, from widely different organizations and projects, none of which have direct ties to each other (yet). Large diversity and single organization independence is here right from the start! And we all are looking forward to further grow this community and its diversity. While the project will have to (learn) stand on its own, the help and support from all the organizations behind the initial members has been fabulous, making it possible to draft up this proposal in less than 2 months time and get all the needed clearances for the SGAs and CCLAs done upfront as well. I find it appropriate to honor this strong support from these organizations in my *introduction* to the proposal and say that this proposal is a joined effort on their part, as well as from all the initial members who did all the hard work. Ate I personally have no problem with the way companies are mentioned in that proposal - nor with the proposal in general, for me it's just fine as is. Thanks Bertrand. -Bertrand - 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
[VOTE] Accept Rave into the Incubator
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 http://issues.apache.org/jira/browse/SHINDIG-1402 * [[http://activitystrea.ms/|Activity S
Re: [VOTE] Accept Rave into the Incubator
Here is my own vote: +1 Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Accept Rave into the Incubator
On 25/02/11 01:08, 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 The vote passes with a total of 29 +1 votes of which 15 binding +1 (IPMC member) votes, and no other votes: (* = binding) Hadrian Zbarcea (*) Richard Hirsch (*) Ralph Goers (*) Alan D. Cabrera (*) ant elder (*) Bertrand Delacretaz (*) Ross Gardler (*) Scott Wilson Ard Schrijvers Sylvain Wallez (*) Sander W G van der Waal Ate Douma (*) Niels van Dijk Arje Cahn Upayavira (*) Troy Howard Davanum Srinivas (*) Ciancetta, Jesse E. Franklin, Matthew B. Suresh Marru Michael McCandless Woon-San Ko Craig L Russell (*) Thorsten Scherler William A. Rowe Jr. (*) Kevin Lau Antoine Levy-Lambert (*) Henry Saputra Mohammad Nour El-Din (*) We'll proceed with the project setup shortly. Thank you all for this strong support! Kind regards, Ate - 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 On 04/23/2011 01:57 PM, 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 * Christian Grobmeier * Jesse Kuhnert * Jochen Wiedmann * Lukasz Lenart * Olivier Lamy * Marc Andrew Davidson * Maurizio Cucchiara * Simone Tripodi * Upayavira 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 implementation, including Apache Struts, Apache Tapestry, Apache Tiles and Apache Camel. It is hoped that members of those projects will be interested in contributing to and adopting this implementation. A Excessive Fascination with the Apache Brand OGNL fits naturally in the ASF because : * It is already adopted by ASF Projects; * It is a key component on which man
Re: [VOTE] Accept Airavata into the Incubator
+1 Accept Airavata into the incubator Ate On 05/02/2011 11:32 PM, Ross Gardler wrote: I would like to call a vote to accept Airavata for entry into the Apache Incubator. The proposal thread can be found at [1] and the proposal text is at [2] [ ] +1 Accept Airavata into the incubator [ ] -1 Do NOT accept Airavata into the incubator because... Thanks, Ross [1] http://markmail.org/message/rhdiuwcexalfndim [2] http://wiki.apache.org/incubator/AiravataProposal - 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 OpenOffice.org for incubation
+1 (binding) Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Ping: [VOTE] Release Apache Rave 0.3-incubating
A week has passed since this vote started and but still no feedback so far. Possibly it was drowned by the Accumulo discussions, but now that has passed... It would be very appreciated if one or more of the IPMC members could spare a little time to review this podling release candidate, and cast a vote on it. (we still need one +1 extra from IPMC on this to pass) Kind regards, Ate On 09/05/2011 03:01 PM, Franklin, Matthew B. wrote: This is the second incubator release for Apache Rave, with the artifacts being versioned as 0.3-incubating. We are requesting at least one IPMC member vote, as we have already received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://goo.gl/VH5ok RESULT: http://goo.gl/b9hxh Release notes: https://svn.apache.org/repos/asf/incubator/rave/tags/0.3-incubating/CHANGELOG SVN source tag (r1163402): https://svn.apache.org/repos/asf/incubator/rave/rave-master-pom/tags/0.3-incubating/ SVN source tag (r1163411): https://svn.apache.org/repos/asf/incubator/rave/tags/0.3-incubating/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacherave-002/ Source releases: https://repository.apache.org/content/repositories/orgapacherave-002/org/apache/rave/rave-master/0.3-incubating/rave-master-0.3-incubating-source-release.zip https://repository.apache.org/content/repositories/orgapacherave-002/org/apache/rave/rave-project/0.3-incubating/rave-project-0.3-incubating-source-release.zip Demo Artifacts http://people.apache.org/builds/incubator/rave/0.3-incubating/rave-0.3-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.3-incubating/rave-0.3-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ping: [VOTE] Release Apache Rave 0.3-incubating
Hi Upayavira, Thanks for reviewing. I've feedback inline below. On 09/14/2011 10:31 AM, Upayavira wrote: I'm no master when it comes to reviewing releases, and I apologise for my lateness to the table. Here's two observations: 1. The NOTICE file should, as I understand it, include the licenses for any dependencies. You have quite a few in your pom.xml, but your NOTICE file is pretty empty. Shouldn't this file be better populated? I assume you refer to the NOTICE file in the svn project root and/or (same thing) in the release source zip? My interpretation is (and seen that being backed in several places and several people, e.g. Roy Fielding) that the NOTICE (and LICENSE) files cover the content of the distribution itself, *only*. Meaning, for a source distribution (or the svn project root, which might be regarded as a "online" distribution) the NOTICE and LICENSE files only need to cover what is within the sources itself. This therefore excludes external dependencies like what you pull in during a build. For the non-source distribution, the binary artifacts like jars, wars and demo tar.gz, which (might) bundle extra dependencies, the NOTICE (and LICENSE) file does have to cover those extra dependencies. And for that purpose, you'll "notice" there are different, much more extensive NOTICE and LICENSE files bundled within, covering those extra dependencies. Within our project (svn), we therefore maintain multiple NOTICE and LICENSE files (or appendable fragments) for this purpose. So please check the binary artifacts (jar,war,tar.gz, etc.) and review the NOTICE/LICENSE files which you'll find stored under their META-INF/ folder. 2. This one is less of a deal - the convention is for artifacts to be named apache-$PROJECT-$BLAH, whereas this is rave-$BLAH. Could future releases be apache-rave-$BLAH? Yes, I agree that would be better and we surely can do that for the next release. Note though, while this might be a good convention, I've seen numerous (both incubating and TLP) releases which have not adopted (yet) this. Which I think is the explanation why Rave hasn't done it either. We were just following some other projects examples. I defer to others on the incubator PMC, but I understanding is that the notice file needs to be better populated before this release can go out. Please see my above comment: I think this release candidate *is* in compliance (and pretty good at it imo) with the rules for the NOTICE/LICENSE files. Thanks again for your feedback, Ate Upayavira On Tuesday, September 13, 2011 9:07 AM, "Ate Douma" wrote: A week has passed since this vote started and but still no feedback so far. Possibly it was drowned by the Accumulo discussions, but now that has passed... It would be very appreciated if one or more of the IPMC members could spare a little time to review this podling release candidate, and cast a vote on it. (we still need one +1 extra from IPMC on this to pass) Kind regards, Ate On 09/05/2011 03:01 PM, Franklin, Matthew B. wrote: This is the second incubator release for Apache Rave, with the artifacts being versioned as 0.3-incubating. We are requesting at least one IPMC member vote, as we have already received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://goo.gl/VH5ok RESULT: http://goo.gl/b9hxh Release notes: https://svn.apache.org/repos/asf/incubator/rave/tags/0.3-incubating/CHANGELOG SVN source tag (r1163402): https://svn.apache.org/repos/asf/incubator/rave/rave-master-pom/tags/0.3-incubating/ SVN source tag (r1163411): https://svn.apache.org/repos/asf/incubator/rave/tags/0.3-incubating/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacherave-002/ Source releases: https://repository.apache.org/content/repositories/orgapacherave-002/org/apache/rave/rave-master/0.3-incubating/rave-master-0.3-incubating-source-release.zip https://repository.apache.org/content/repositories/orgapacherave-002/org/apache/rave/rave-project/0.3-incubating/rave-project-0.3-incubating-source-release.zip Demo Artifacts http://people.apache.org/builds/incubator/rave/0.3-incubating/rave-0.3-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.3-incubating/rave-0.3-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 On 10/11/2011 11:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more "correct", for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread of web development binding them all. In terms of contribution, excluding Nitobi Software employees, the Callback project has
Re: Proposal for Wookie a W3C Widget/Google Wave widget engine
Ross Gardler wrote: I would like to submit the Wookie project proposal to the Incubator PMC. Our draft is appended to the end of this mail and is available at: http://wiki.apache.org/incubator/WookieProposal A quick overview of Wookie is: Wookie is a Java server application that allows you to upload and deploy widgets for your applications. Wookie is based on the W3C Widgets specification, but widgets can also be included that use extended APIs such as Google Wave Gadgets and OpenSocial. I have agreed to champion and mentor this proposal, Gavin McDonald has also agreed to mentor, more mentors are being sought - let me know if you are interested. Hi Ross, The Wookie proposal has my high interest, especially from the bridging POV between W3C Widgets and Google Gadgets. Furthermore, I'm involved in Apache Portals (committer & PMC) and integrating these APIs and features into a portal server (e.g. Apache Jetspeed-2) is very much on our short list. So I'd like to help with mentoring Wookie through the incubator as much as possible. Note: while I'm an ASF Member, I'm not (yet) a Incubator PMC member, which I understand is required for this. Regards, Ate At this stage I am seeking feedback on or questions about the Wookie proposal. The project team are subscribed to this list and ready to respond to any queries. - COPY OF PROPOSAL FROM http://wiki.apache.org/incubator/WookieProposal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Wookie - a W3C widget engine with Google Wave extension
+1 BTW: not sure if my vote is "binding" as I received no formal feedback yet concerning my IPMC membership (but saw it being ACK by board). Ate Ross Gardler wrote: I would like to formally present the incubator proposal for Apache Wookie, a W3C widget engine with Google Wave extension The full proposal can be found at http://wiki.apache.org/incubator/WookieProposal Vote will close in a little over 72 hours at mid day (BST, UTC + 1) Friday 17th July. http://www.timeanddate.com/worldclock/fixedtime.html?month=7&day=17&year=2009&hour=12&min=0&sec=0&p1=136 Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator PMC Membership Status Check 2010
Hi Noel, I didn't receive one. Ate On 02/15/2010 05:16 PM, Noel J. Bergman wrote: I have sent an e-mail directly to everyone who is officially on the Incubator PMC. If you did NOT receive that e-mail, and believe that you should be on the PMC, please notify me, via e-mail here. Thank you. --- Noel - 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: Incubator PMC Membership Status Check 2010
On 02/15/2010 05:47 PM, Noel J. Bergman wrote: Ate Douma wrote: I didn't receive one. Check your @apache.org e-mail. That is the address to which it went, and you were definitely on the list. Unless mail forwarding is broken, I should receive it on this email account. Until now I got all my @apache.org email forwarded properly. I never have had need to check my @apache.org e-mail. Update: I asked someone else to email at a...@apache.org but I haven't received that either... Seems something not working right. Ate --- Noel - 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: Third party Maven Repository Usage
f even possible *just for the sake of Maven Central, or else indeed "cut the cord" and go "independent"... I really hope I'm missing the point here and none of this is going to cause much trouble after all. Please enlighten me! Regards, Ate --kevan - 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: Third party Maven Repository Usage
Thanks for the reply Brian, this is much relief. However in your initial response your wording clearly indicated the new policy already being enforced, up to: "[...] your artifacts will end up blocked." A little less restrictive description could have prevented this misunderstanding... I think that, with the goals you have, it would be good to already "announce" this more prominently, especially within the ASF. I suspect others will raise questions similar to mine and maybe even more. Upfront and public awareness of important changes things like these is important to build up support for it IMO. Doing it 1-on-1 with individual release managers/projects seems both very time consuming and "hiding" it from the larger community. I don't know who "owns" Maven Central (Sonatype?) but as the "default" repository build into Apache Maven I would think at least the ASF community would have to be informed proper and be allowed to discuss what/how/when concerning such policy changes. Never mind, we're cool again for now. I'll ping you again when we are ready for the rsync of our "legacy" bugfix release. Kind regards, Ate On 03/25/2010 05:49 AM, Brian Fox wrote: Interesting. That's news to me... You have a pointer to more information? As it turns out, almost all references to external repositories in poms are junk or turn out to be junk after a bit of time. See here for some examples: http://www.sonatype.com/people/2010/03/why-external-repos-are-being-phased-out-of-central/ * Unclear from the documentation is if this restriction on external repositories is limited to only the repository definitions in a pom, or if it is (or will be) extended to dependency resolving as well. If not all dependencies can be resolved to Central itself, would that be "flagged" too and also cause blocking the artifact(s) ? The validations are currently configured to disallow any release repository declarations in the poms. We may allow some approved external repos down the road if the contents are vetted and cleaned and unlikely to disappear. The main issues revolve around fly-by-night or unreliable repositories. Having these in your poms is a red herring and end up causing your users more harm than good. * At what stage is this policy "enforced"? I'm thinking of Apache Repository when we deploy and release. Would a violation of this policy already be noticed (and reported) while doing a staging release, or only at the final release to Maven Central? This is enforced by the Nexus staging rules in the various forges and ultimately will be applied to all avenues into Central regardless of the source. (Rsyncs are being phased out). I have not enabled this rule on repository.apache.org but it is in place in most other locations. I wanted to be able to analyze the external repo use of Apache based projects and work with them before throwing down a new gauntlet. No panic is necessary, we'll work this out together, but this is a rule that is going into effect at Central and all projects, Apache or not will eventually have to pass the same criteria. The latter clearly would be too little too late IMO. Note: we're using Apache Repository for snapshot deployments right now, and I haven't seen any "warning" about us referencing external repositories. This currently wouldn't trigger on any snapshot builds, but would prevent the promotion of a staged repo, exactly how you can't promote artifacts that aren't signed. Again, it's not enabled and I don't intend to enable it until I can analyze and work with projects to make this a non issue. * Does this new policy also affect the processing and handling of the "legacy" rsync repositories at /www/people.apache.org/repo? As it will affect all sources into Central, yes this would eventually affect the legacy repo as well. However... If it does, or even only partly, please let us know how and to what extend. Note: we're planning a bugfix release shortly of an older version of Jetspeed-2, version 2.1.4 (Apache Portals). That version of Jetspeed-2 doesn't and cannot use the new Apache master pom nor Apache Repository as it would require too major changes for the whole project configuration itself. The current Jetspeed-2 version 2.2.0 has been released through Apache Repository, and we're planning a new release 2.2.1 shortly too. However, for Jetspeed 2.1.4 we'll still have to use the "legacy" rsync procedure. When a project is moved over to the new repo, the legacy repo is disabled for that project. Meaning you won't be able to deploy there anymore. Central can't rsync the same project from two locations and expect the metadata to be correct. To deploy into r.a.o, you won't have to use the entire new master pom, just change the url in your distributionManagement
[VOTE] Termination of WSRP4J podling
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
Re: [VOTE] Termination of WSRP4J podling
The vote for the termination of the WSRP4J podling passes with 9 binding +1 votes and no 0 or -1 votes. Tally of the binding +1 votes: Ate Douma Ralph Goers Carsten Ziegler Bertrand Delacretaz ant elder Davanum Srinivas Martijn Dashorts Niclas Hedhman Luciano Resende I'm not all to familiar with what the next steps should be. As a minimum the WSRP4J incubator status page at http://incubator.apache.org/projects/wsrp4j.html needs updating (not sure I have the appropriate rights for that myself), and the board should be informed about this in the next incubator report. Furthermore, I assume the wsrp4j mailing list (-dev and -user) should be closed as well as the svn project under /portals/wsrp4j should be made read-only and possibly moved somewhere else? Finally, at the Portals PMC we can take care of removing the WSRP4J website or possibly should it be replaced with a notice of termination page? What exactly is the "standard" procedure for a terminated podling, I can't really find anything on that on the incubator website. Regards, Ate On 04/14/2010 02:37 AM, 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
[ANNOUNCE] WSRP4J Incubator project terminated
Dear remaining WSRP4J community, The Apache Incubator voted and accepted the Portals PMC proposal to terminate the WSRP4J project. The WSRP4J incubator project status has been updated accordingly, see: http://incubator.apache.org/projects/wsrp4j.html Furthermore, the subversion tree of WSRP4J will be made read-only and the wsrp4j mailing lists closed down shortly. This email therefore very well might be the last one delivered to these lists. With kind regards, Ate Douma On behalf of the Apache Portals PMC - 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
On 04/20/2010 01:44 AM, David Crossley wrote: Ate Douma wrote: What exactly is the "standard" procedure for a terminated podling, I can't really find anything on that on the incubator website. There ain't no exactlies. Searching for the term "Retire" has better results. However as far as i recall not much actual docs. Searching the mail archives for previous retired projects would help. Some tasks are noted at Clutch http://incubator.apache.org/clutch.html do find-in-page "retire" ... "Dormant or Retired - Remove from the ReportingSchedule. In the Projects in incubation table, move it to the "Dormant" or "Retired" section. Remove entry from right-side panel. (doc) " The doc link goes to https://issues.apache.org/jira/browse/INCUBATOR-100 "document the process for a podling that has decided to go to dormant status" which links to some previous ideas about what needs to be done. Hope that helps. -David Thanks, that really helped! I've scanned all incubator site-author documents with references to WSRP4J and took if from there. AFAIK I've covered all needed site-author specific changes and committed those back to site-publish and ran svn up on people.apache.org Furthermore, I removed WSRP4J from the Incubator ReportingSchedule Wiki page. I also asked infra to shutdown the WSRP4J mailing lists and make the svn tree read-only (INFRA-2631). Also, we added a status update on the Portals website about the WSRP4J termination and I just send out a final and last email to the WSRP4J mailing lists. If anyone thinks there is something else left to do, please let me know. Regards, Ate - 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 Stanbol for incubation
+1 Regards, Ate On 10/11/10 16:11, Bertrand Delacretaz wrote: Hi, I think we're ready to vote on the http://wiki.apache.org/incubator/StanbolProposal now, copy included below. This is TPFKAF - The Project Formerly Known As FOO. Please cast your votes: [ ] +1 Accept Stanbol for incubation [ ] +0 Don't care [ ] -1 Reject for the following reason: The vote is open for at least 72 hours. Thanks! -Bertrand = Apache Stanbol incubation proposal = == Abstract == Apache Stanbol is a modular software stack and reusable set of components for semantic content management. == Proposal == Stanbol components are meant to be accessed over RESTful interfaces to provide semantic services for content management. The current code is written in Java and based on the OSGi modularization framework, but other server-side languages might be used as well. Applications include extending existing content management systems with (internal or external) semantic services, and creating new types of content management systems with semantics at their core. The architecture of the current (alpha-level) code consists of four layers: * Persistence: services that store (or cache) semantic information and make it searchable * Lifting: services that add semantic information to “non-semantic” pieces of content * Knowledge models and reasoning: services that enhance the semantic information * Interaction: intelligent user interface management and generation == Background == Stanbol comes out of the IKS project (Interactive Knowledge Stack, http://iks-project.eu/), a research project funded by the European Community (EC) which aims to create a semantic content management software stack. One of the goals of IKS is for its software to survive the 4-year funding period of the EC, which ends in 2012. Developing its code in the open at the Apache Software Foundation, and growing a community before IKS funding runs out, is the best way to ensure the sustainability of the Stanbol software. For more background information, some articles and tutorials on FISE, which was the first usable IKS module, can be found in the “FISE links” section of http://wiki.iks-project.eu/index.php/FISE == Rationale == Content Management Systems (CMS) can benefit from semantic add-ons in a number of ways, including more intelligent linking, automatic or semi-automatic tagging of content, enhanced user interactions based on intelligent and dynamically adaptable user scenario modeling, etc. However, many CMS vendors and developers are not aware of or skilled enough in semantic technologies to make effective use of them. Research in semantic technologies often happens in academic circles which might not make their findings available in a way that’s easily consumable by today’s CMS vendors and developers. Some big companies are using semantic technologies behind the scenes to provide powerful services, but that technology is usually not accessible to smaller vendors. Stanbol aims to bridge these gaps by providing CMS vendors and developers with easy to integrate semantic components that add value to their offerings. At the same time, more experimental advanced semantic applications will be built on the Stanbol stack, with the medium-term goal of enabling pure semantic-based content management and other applications. == Initial Goals == * Import the existing IKS code. * Clean up as needed to take advantage of Apache infrastructure (Hudson continuous builds, etc.) * Replace up any dependencies that do not fulfill Apache licensing criteria. * Create the Stanbol website and migrate IKS website/wiki information to it as needed. * Make a first release and publicize it to start growing the community. == Current Status == === Meritocracy === As IKS is an EC research project with funding, it does not formally operate as a meritocracy. However, due to the open source way of working adopted by the consortium, an informal meritocracy has emerged within IKS. We estimate that adapting to the ASF’s meritocratic way of working will be easy for the initial set of Stanbol committers, as the differences to the current way of working are not dramatic. === Community === The IKS project plan includes an important effort to build a community around the software that it produces. Several community workshops have already taken place, attended by more than 40 European CMS developers and vendors. See http://wiki.iks-project.eu/index.php/Workshops for more info. A community is emerging around IKS, and moving to the Apache project governance model should help grow it - also by reassuring community members that the software will continue to be available and maintainable once the IKS EC funding runs out. === Core Developers === The IKS consortium consists of seven academic research groups and six “industrial partners”, companies active in the CMS space. See http://iks-project.eu/team/team for the list. The current IKS software has been written by
Re: [PROPOSAL] Accept Wave for incubation
+1 Regards, Ate On 23/11/10 21:16, Dan Peterson wrote: Hello all, We'd like to propose Wave for entry into the ASF incubator. The draft proposal is available at: http://wiki.apache.org/incubator/WaveProposal (for your convenience, a snapshot is also copied below) A wave is a hosted, live, concurrent data structure for rich communication. It can be used like email, chat, or a document. Wave in a Box (WIAB) is the name of the main product at the moment, which is a server that hosts and federates waves, supports extensive APIs, and provides a rich web client. This project also includes an implementation of the Wave Federation protocol, to enable federated collaboration systems (such as multiple interoperable Wave In a Box instances). As a result of the recent Wave Summit, beyond growing a few new committers, we've put together the following proposal for migrating the community into the ASF incubator. More details on the summit& Wave in a Box progress in this blogpost: http://googlewavedev.blogspot.com/2010/11/this-weeks-wave-protocol-summit-updates.html We are looking forward to your feedback and suggestions. By the way, if you're looking to learn more about the technology related to wave, you can see the videos and presentations from the recent Wave Summit in: https://wave.google.com/wave/waveref/googlewave.com/w+rwFyiw47A Kind regards, -Dan, on behalf of the Wave Community P.S. For those on the wave-protocol Google Group (that aren't yet on general@incubator.apache.org), please participate in this discussion by sending a message to general-subscribe at incubator dot apache dot org Apache Wave Proposal (Apache Incubator) = Abstract = Apache Wave is the project where wave technology is developed at Apache. Wave in a Box (WIAB) is the name of the main product at the moment, which is a server that hosts and federates waves, supports extensive APIs, and provides a rich web client. This project also includes an implementation of the Wave Federation protocol, to enable federated collaboration systems (such as multiple interoperable Wave In a Box instances). = Proposal = A wave is a hosted, live, concurrent data structure for rich communication. It can be used like email, chat, or a document. WIAB is a server that hosts waves. The best analogy for this is a mail server with a web client. WIAB is comprised of a few high-level components: the client and the server. They have the following major functionality (though this is not an exhaustive list): * Client *A dynamic web client for users to create, edit, and search waves. Users can access this client by directly visiting the server in a browser. * Gadgets provide the ability to insert, view, and modify the UI -- exposing the Wave Gadgets API ( http://code.google.com/apis/wave/extensions/gadgets/guide.html) * A console client that can create and edit waves via a command-line-like interface. * Server * Hosts and stores waves. WIAB comes with a default storage mechanism. The administrators of the server may configure it to use alternative storage mechanisms. * Indexing, allowing for searching the waves a user has access to. * Basic authentication, configurable to delegate to other systems. * Federation, allowing separate Wave in a Box servers to communicate with each other using the Wave Federation Protocol ( http://www.waveprotocol.org/federation). * Robots, using the Wave Robots API, ( http://code.google.com/apis/wave/extensions/robots/) may interact with waves on a WIAB instance. = Background = Wave expresses a new metaphor for communication: hosted conversations. This was created by Lars and Jens Rasmussen after observation of people's use of many separate forms of communication to get something done, e.g, email, chat, docs, blogs, twitter, etc. The vision has always been to better the way people communicate and collaborate. Building open protocols and sharing code available in an open and free way is a critical part of that vision. Anyone should be able to bring up their own wave server and communicate with others (much like SMTP). We hope this project will allow everyone to easily gain the benefits of Wave with a standard implementation of Wave – in a box. = Rationale = Wave has shown it excels at small group collaboration when hosted by Google. Although Wave will not continue as a standalone Google product, there is a lot of interest from many organizations in both running Wave and building upon the technology for new products. We are confident that with the community-centric development environment fostered by the Apache Software Foundation, WIAB will thrive. = Initial Goals = The initial goals of the project are: 1. To migrate the codebase from code.google.com and integrate the project with the ASF infrastructure (issue management, build, project site, etc). 1. To quickly reach a state where it is possible to continue the development of the Wave In a Box implementati
Re: [VOTE] Accept Openmeetings to Apache Incubator
+1 Ate On 11/07/2011 10:53 PM, Andrus Adamchik wrote: Opemeetings proposal has been discussed a few times here before. The group of developers behind it worked hard (and succeeded) to address all potential obstacles to the Incubator acceptance and to the following incubation. They even went an extra mile and collected all ICLAs in adbvance. So now I am starting the vote to accept Openmeetings to Apache Incubator. The proposal is also available at: http://wiki.apache.org/incubator/OpenmeetingsProposal Please cast your votes: [ ] +1 Accept Openmeetings for incubation [ ] +0 Don't care [ ] -1 Reject for the following reason: The vote is open for 72 hours. Andrus --- Andrus Adamchik Apache Cayenne ORM: http://cayenne.apache.org/ Twitter: http://twitter.com/andrus_a --- == OpenMeetings Project Proposal == == Abstract == Openmeetings is a web conferencing solution. == Proposal == Openmeetings provides video conferencing, instant messaging, white board, collaborative document editing and other groupware tools using API functions of the Red5 Streaming Server for Remoting and Streaming. == Background == Openmeetings was developed since 2007 by Sebastian Wagner and willing developers. The project ships a release approximately once per quarter. It was developed using LGPL license, and developers are currently thinking of re-licensing it under Apache License 2.0. The project started as module by Sebastian Wagner for an ELearning platform (Dokeos) and was then split into a separated project. That is the reason why there is a strong relation to educational institutions that are using OpenMeetings and there are integrations for platforms like Moodle, ATutor, Sakai, STudIP or ILias available (http://code.google.com/p/openmeetings/wiki/MoodlePlugins). The relation to educational institutions also subsequently lead to some projects funded by the EU where OpenMeetings was involved, for example by the Swedish/Finnish Centre of Open-Source !OpenKarken (Case-Study about the EU project at OSOR.eu: http://www.osor.eu/studies/finland-and-sweden-collaborate-using-oss ) The integration and internationalization of the project was a primary focus right from the start of the project. Since Version 0.5 there is a Language-Editor (http://code.google.com/p/openmeetings/wiki/LanguageEditor) to edit labels, export and import them as XML and you can use those XML files for future installations (or contribute it to the community). There are currently around 30 languages available. Since version 0.5.1 there is also a SOAP API to integrate !OpenMeetings. We constantly improve this SOAP/REST API (http://code.google.com/p/openmeetings/wiki/SoapMethods) with new functionality with a strong focus on security and usability. The auth-mechnism is quite similar to OAuth, you create some token and then assign rights to the token. (Documentation for Single Sign On: http://code.google.com/p/openmeetings/wiki/DirectLoginSoapGeneralFlow) The project name "!OpenMeetings" and logos are inspired by Ludovic Gasc who has been the project manager at Dokeos at the time Sebastian split !OpenMeetings as separated project. Red5 Server provides an "Edge-Orion-Clustering" (http://trac.red5.org/wiki/Documentation/Tutorials/EdgeOriginClusteringConfiguration). We hope to extend this clustering solution with support for rtmpt and rtmps and integrate that into our application as native clustering option. == Rationale == Last year most major vendors started commercial web conferencing solutions. This is an important part of software ecosystem, and there is an urge to consolidate open source development efforts in this direction. According to several studies demand for synchronous Communication, in opposite to asynchronous Communication like wiki's or email, will raise the upcoming years. For example Gartner promises that 2011 the market will grow 20% according to their "Magic Quadrant" report 2010 ( http://www.gartner.com/DisplayDocument?doc_cd=205941 ). Openmeetings is a unique solution in terms of patent purity and potentially can grow into solution built on top of the fully open source stack. That is why it is a good candidate for consolidating web conferencing community efforts. == Initial Goals == Each of project committers has their own set of goals, but we all share the following. * Move to Apache. * Become popular. To become popular we plan to do the following. * Improve ecosystem around the project. * Improve release process. * Improve project testing and stability. * Apply modular architecture/SOA for better integration with other projects. == Current Status == We have agreed on applying for the Apache Foundation and preparing our proposal for the vote. Technical status of the project is: Current stable tree is 1.8.x, Trunk is 1.9. === Meritocracy === Developers community is successfully driven by consensus now
Re: [1 IPMC VOTE NEEDED] [VOTE] Release Apache Rave 0.6-incubating
On 01/13/2012 09:53 AM, ant elder wrote: I've had a look, the only issue i see is I don't think the NOTICE file in the binary distribution is correct as it has many things which i expect are not required. When we last discussed this on general@ we said this is not strictly a blocking problem, so +1 Thanks for the review and vote ant, much appreciated. but i think you should do a complete review of whats in the NOTICE file with your mentors and remove everything which doesn't need to be there. I'm curious what in your opinion doesn't need to be in the NOTICE file. I might have missed some recent discussions on this topic here, but AFAIK all those notices are required. Or did the guidelines really change dramatically recently? Thanks, Ate ...ant On Thu, Jan 12, 2012 at 2:16 PM, Franklin, Matthew B. wrote: We still need to get one more IPMC vote to close this vote. If someone could take a look, it would be greatly appreciated. -Matt -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Wednesday, January 11, 2012 8:03 AM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Monday, January 09, 2012 8:45 AM To: general@incubator.apache.org Cc: rave-...@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Monday, January 09, 2012 8:21 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 9 January 2012 13:09, Franklin, Matthew B. wrote: Does my answer below suffice? It would be nice to close this vote out one way or another The answer describes what happened. However, it does not fix the problem, which is that the end-user sees a file with conflicting information. Thanks. This is what I was looking for, so that we can have the discussion as to whether or not to cancel the release (we won't do a re-release). Not a blocker, but you may find it takes less time overall to fix the issue before release rather than dealing with user queries afterwards. It may also lessen confidence in the release: if there is such an obvious error, what other errors are lurking? While I agree that it doesn't look great, the CHANGELOG is distributed with the source release and is probably not viewed as much as the release notes sent out with the announcement (which will be the JIRA list I linked). I will take this back to our dev list, but if they don't see it as a blocker, would you be comfortable voting +1? The community was presented with the issue and via lazy consensus agreed to move forward with the release, even though the CHANGELOG file is incorrect. We still need 1 final IPMC vote to release. [ Community discussion on proceeding: http://markmail.org/message/tp5nyqh24tdpybw6 ] -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Tuesday, January 03, 2012 12:19 PM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231 1 2 90 &version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave- 278/ https://repository.apache.org/content/repositories/orgapacherave- 279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6- incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6- incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/inc
Re: [VOTE] Clarify the role of the Champion as an "incubation coordinator"
+1 (binding) Ate On 01/12/2012 04:02 PM, Bertrand Delacretaz wrote: Hi Incubator PMC, Here's the result of discussions that took place around Christmas - the goal is to try and improve the PMC's oversight on podling reports and missing mentors, by having the Champion act as the main liaison between a podling and the Incubator PMC. If we agree on the below principles, I'll update the http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion description accordingly. Please cast your votes to accept the following clarifications to the Champion's role - this majority vote is open for at least 72 hours: Once a podling is created, and until it graduates, its Champion must: 1. Coordinate the creation and timely delivery of the podling's board reports. 2. Keep an eye on the mentors' activity and take action (ask for new mentors, talk to the Incubator PMC) if they don't seem to provide enough oversight or mentorship to the podling, As far as the podling is concerned: 3. The podling can elect a new Champion at any time, and must notify the Incubator PMC when that happens. 4. Existing podlings will need to elect a Champion, unless their current one agrees to take on the above tasks. 5. The podling reports must indicate who the current Champion is. -Bertrand - 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: [1 IPMC VOTE NEEDED] [VOTE] Release Apache Rave 0.6-incubating
On 01/17/2012 10:41 AM, ant elder wrote: On Sat, Jan 14, 2012 at 10:20 PM, Ate Douma wrote: On 01/13/2012 09:53 AM, ant elder wrote: I've had a look, the only issue i see is I don't think the NOTICE file in the binary distribution is correct as it has many things which i expect are not required. When we last discussed this on general@ we said this is not strictly a blocking problem, so +1 Thanks for the review and vote ant, much appreciated. but i think you should do a complete review of whats in the NOTICE file with your mentors and remove everything which doesn't need to be there. I'm curious what in your opinion doesn't need to be in the NOTICE file. I might have missed some recent discussions on this topic here, but AFAIK all those notices are required. Or did the guidelines really change dramatically recently? See this email [1] for an answer to a similar question, also there is now a definition of required third party notices at [2]. In a nutshell, very few things actually require mention in the NOTICE file, and best not to unless there is a reason to. Thanks ant, I've been going through my backlog of still unread general@ list messages since end of November last night, which I didn't had time to look at before. So I did find the long, very long, discussion(s) about it. I can't say it is 100% clear yet and to me it seems like the 'rules' haven't been 'formalized' or 'codified' properly yet. To me [2] by itself doesn't explain it good enough at least. But reading through the whole mail thread(s) does help. At any way, I think I now understand the arguments *why* we should not have unnecessary notices: "to keep the burden as low as possible for down stream (re) distributers as they are required to retain our NOTICE file". Right? For following releases of Apache Rave I'll re-evaluate our NOTICE file to check if we actually have unnecessary (not asked for) notices which we can remove then. Thanks for the heads-up, Ate ...ant [1] http://mail-archives.apache.org/mod_mbox/incubator-general/20.mbox/%3CCAJO%2BUbvDfOib7FnQpJPtVcMJKDvBPRHpAG4%3DbEO3Vmy4w4reFA%40mail.gmail.com%3E [2] http://apache.org/legal/resolved.html#required-third-party-notices - 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] Release Apache Rave 0.7-incubating
On 01/23/2012 10:30 PM, Franklin, Matthew B. wrote: On 1/23/12 3:29 PM, "sebb" wrote: On 23 January 2012 15:17, Franklin, Matthew B. wrote: This is the sixth incubator release for Apache Rave, with the artifacts being versioned as 0.7-incubating. We are requesting a lazy consensus vote, as we have already received 3 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/xqH RESULT: http://s.apache.org/rg Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/CHANGE LOG SVN source tag (r1227377): https://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/ NOTICE file says: Apache Rave Copyright 2011 The Apache Software Foundation Is this still correct? The release was spun on January 4th of 2012 and there were 4 minor changes made between 2012& the release. Based on prior discussions on this list, minor changes don't seem to be a blocker [1]. Additionally, I have created a JIRA ticket for updating the copyright date on all NOTICE files [2]. [1] : http://markmail.org/message/3b776xpdzijynypc [2] : https://issues.apache.org/jira/browse/RAVE-439 Besides this being a minor and certainly non-blocker issue, a similar question came up just last week on legal-discuss@ where the question was if every copyright statement would need to be 'bumped' to adjust for the new year. Greg Stein provided IMO a nice and clear (follow up) answer about the importance of how and when to do this [3]: Actually, the shorter answer is "get it close, but don't worry about it." (per a lawyer friend of mine) What you put in the header is advisory. If you end up in court, it has zero impact compared to the actual commit history that demonstrates it is your work. "Your work" is the operative issue; not when you happened to do that work." Original message and thread link: http://markmail.org/message/v3n7vyd4anxmgzbn So I see no reason at all to worry about these now. And, for the record, none of the NOTICE files in this release themselves were modified since 2011. Ate Maven staging repo: https://repository.apache.org/content/repositories/orgapacherave-015/ Source release: https://repository.apache.org/content/repositories/orgapacherave-015/org/ apache/rave/rave-project/0.7-incubating/rave-project-0.7-incubating-sourc e-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave -0.7-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave -0.7-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Lazy consensus, vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - 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] Release Apache Rave 0.7-incubating
On 01/23/2012 10:56 PM, Ate Douma wrote: On 01/23/2012 10:30 PM, Franklin, Matthew B. wrote: On 1/23/12 3:29 PM, "sebb" wrote: On 23 January 2012 15:17, Franklin, Matthew B. wrote: This is the sixth incubator release for Apache Rave, with the artifacts being versioned as 0.7-incubating. We are requesting a lazy consensus vote, as we have already received 3 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/xqH RESULT: http://s.apache.org/rg Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/CHANGE LOG SVN source tag (r1227377): https://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/ NOTICE file says: Apache Rave Copyright 2011 The Apache Software Foundation Is this still correct? The release was spun on January 4th of 2012 and there were 4 minor changes made between 2012& the release. Based on prior discussions on this list, minor changes don't seem to be a blocker [1]. Additionally, I have created a JIRA ticket for updating the copyright date on all NOTICE files [2]. [1] : http://markmail.org/message/3b776xpdzijynypc [2] : https://issues.apache.org/jira/browse/RAVE-439 Besides this being a minor and certainly non-blocker issue, a similar question came up just last week on legal-discuss@ where the question was if every copyright statement would need to be 'bumped' to adjust for the new year. Greg Stein provided IMO a nice and clear (follow up) answer about the importance of how and when to do this [3]: Actually, the shorter answer is "get it close, but don't worry about it." (per a lawyer friend of mine) What you put in the header is advisory. If you end up in court, it has zero impact compared to the actual commit history that demonstrates it is your work. "Your work" is the operative issue; not when you happened to do that work." Original message and thread link: http://markmail.org/message/v3n7vyd4anxmgzbn On second thought, the above quote might not be relevant in *this* context, as in this case it concerns the NOTICE file, not some copyrighted resource itself. Nonetheless, the fact this was a release cut on January 4th, I think it truely isn't of much concern anyway, and for subsequent releases we'll adjust the copyright date. I do however very much appreciate the proper review and feedback from sebb, and others on general@ alike, because all these tiny issues are soo easy to overlook! Thanks, Ate So I see no reason at all to worry about these now. And, for the record, none of the NOTICE files in this release themselves were modified since 2011. Ate Maven staging repo: https://repository.apache.org/content/repositories/orgapacherave-015/ Source release: https://repository.apache.org/content/repositories/orgapacherave-015/org/ apache/rave/rave-project/0.7-incubating/rave-project-0.7-incubating-sourc e-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave -0.7-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave -0.7-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Lazy consensus, vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - 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: [DISCUSSION] Regular rotation PMC chair
On 01/29/2012 02:15 AM, Alan D. Cabrera wrote: On 01/29/2012 02:15 AM, 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 think it is a good idea to have the position of the PMC Chair limited to a pre-defined term, so everybody knows and recognizes this is as an appointed position, not tied to a specific person. I think it is healthy both for the community *and* the appointed PMC Chair itself, to not get too much 'attached' or accustomed to the position, which could make it increasingly more difficult to 'detach' from it over time. Or that a community simply doesn't recognize it anymore as something questionable. IMO a PMC Chair which has and retains the support of the rest of the PMC need not resign and can maintain that position for as long the PMC supports it. But it would be good to 'touch base' after every term, making it easier and less awkward for others to step up proposing themselves, or others, as candidate for a next term. If nobody else is proposed as candidate (and the current Chair is willing to continue), everything stays the same. But it should be notified to the board in the next report the current PMC Chair was re-elected for the next term. What length such a term should be, probably can be discussed endlessly, and I expect it will be, if we make it an important topic. IMO it is not. From a pragmatic POV I propose a one year term, same as with the Board's term and easy not to forget or ignore. One typical argument I'll expect against this at large is that a good PMC Chair needs time and experience to grow into the position. Which I agree with. A PMC Chair position which is *rotated* every year definitely sound undesirable to me because it doesn't allow the current Chair time to properly build up this experience. But that should be obvious to everyone involved. So common sense can expect a PMC to grant a chosen Chair more than a year's term to 'prove' himself and build up the needed experience. And re-electing (or not proposing other candidates) the current Chair then should be a trivial matter, even allowed by lazy consensus for all I care. And I'd prefer something like the above to be made formal 'policy' by the board, so there will be no need to discuss this over and over again. Effectively, I don't think any of this would or should have *any* consequences for PMCs and their Chairs doing a good job for years already. Actually more a confirmation and (internal) praise for the tremendous job they've been doing. To me personally, this includes Noel Bergman, fulfilling a tremendously difficult job on behalf of the Incubator PMC. If there is one PMC Chair position within the ASF which needs a *very* experienced person to fulfill it, this one surely is. Regards, Ate Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 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? Regards, Alan - 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: [DISCUSSION] Regular rotation PMC chair
On 01/29/2012 03:15 PM, Ate Douma wrote: On 01/29/2012 02:15 AM, Alan D. Cabrera wrote: On 01/29/2012 02:15 AM, 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 think it is a good idea to have the position of the PMC Chair limited to a pre-defined term, so everybody knows and recognizes this is as an appointed position, not tied to a specific person. I think it is healthy both for the community *and* the appointed PMC Chair itself, to not get too much 'attached' or accustomed to the position, which could make it increasingly more difficult to 'detach' from it over time. Or that a community simply doesn't recognize it anymore as something questionable. IMO a PMC Chair which has and retains the support of the rest of the PMC need not resign and can maintain that position for as long the PMC supports it. But it would be good to 'touch base' after every term, making it easier and less awkward for others to step up proposing themselves, or others, as candidate for a next term. If nobody else is proposed as candidate (and the current Chair is willing to continue), everything stays the same. But it should be notified to the board in the next report the current PMC Chair was re-elected for the next term. What length such a term should be, probably can be discussed endlessly, and I expect it will be, if we make it an important topic. IMO it is not. From a pragmatic POV I propose a one year term, same as with the Board's term and easy not to forget or ignore. One typical argument I'll expect against this at large is that a good PMC Chair needs time and experience to grow into the position. Which I agree with. A PMC Chair position which is *rotated* every year definitely sound undesirable to me because it doesn't allow the current Chair time to properly build up this experience. But that should be obvious to everyone involved. So common sense can expect a PMC to grant a chosen Chair more than a year's term to 'prove' himself and build up the needed experience. And re-electing (or not proposing other candidates) the current Chair then should be a trivial matter, even allowed by lazy consensus for all I care. And I'd prefer something like the above to be made formal 'policy' by the board, so there will be no need to discuss this over and over again. Effectively, I don't think any of this would or should have *any* consequences for PMCs and their Chairs doing a good job for years already. Actually more a confirmation and (internal) praise for the tremendous job they've been doing. To me personally, this includes Noel Bergman, fulfilling a tremendously difficult job on behalf of the Incubator PMC. If there is one PMC Chair position within the ASF which needs a *very* experienced person to fulfill it, this one surely is. Regards, Ate 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. Ate Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 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? Regards, Alan - 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: [DISCUSSION] Regular rotation PMC chair
On 01/29/2012 09:37 PM, Ralph Goers wrote: On Jan 29, 2012, at 12:16 PM, Benson Margulies wrote: On Sun, Jan 29, 2012 at 2:23 PM, Alan D. Cabrera 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 +1 for option 2 (alone) as well, and fully agree with Ralph's arguments. Concerning having to 'fire up the full secret ballot mechanism used for board', I would think that not necessarily nor often needed. As I said earlier, if there are no other candidates and the current Chair is willing to serve another term, which could be determined by a simple and lazy consensus heads-up email on private@, there need not be held any format vote as long as everybody is aware of the fact. Regards, Ate 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
Re: [DISCUSSION] Regular rotation PMC chair
On 01/30/2012 10:17 AM, Ross Gardler wrote: On 30 January 2012 09:11, Bertrand Delacretaz wrote: On Sun, Jan 29, 2012 at 9:16 PM, Benson Margulies wrote: ...2) Fixed election schedule: On some schedule (e.g. annually), nominations are opened, including potentially the current chair, and a vote takes place... +1 to this option. +1 I suggest the date be 30 days after the board elections. The calibre of people we need here is the same calibre as those on the board. By making these elections shortly after the board elections we allow people to manage their commitments better. 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). Ate Ross -Bertrand - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 02/03/2012 06:47 PM, Karl Wright wrote: +1 on this. Work the bugs out before everyone transitions. +1 on that Ate Karl On Fri, Feb 3, 2012 at 12:27 PM, Jukka Zitting wrote: Hi, [Forking a new thread thread to make this easier to track.] On Fri, Feb 3, 2012 at 5:22 PM, Mattmann, Chris A (388J) wrote: http://wiki.apache.org/incubator/IncubatorDeconstructionProposal As already mentioned by others, instead of deconstructing everything in one go, wouldn't it make more sense to gradually shift into a new way of doing things? You're proposing that podlings should start as full TLPs (with ASF members on board for mentoring) right from the beginning. Instead of changing the rules on all podlings at the same time, how about we try this out by giving interested podlings (or new proposals) this "direct to TLP" option? If that works out better than the current Incubator model, we can stop accepting more old-style podlings and just direct them into TLPs right from the beginning. Meanwhile any existing podlings should have a chance to graduate under the existing rules unless they rather choose to use this "direct to TLP" option. If as a result there's no more podlings in the Incubator, that's IMHO then the right time to shut down the IPMC, not before. And if it turns out that the proposed new model doesn't work as expected, we still have the current processes and structures to fall back to. The current Incubator model certainly has flaws, but it also does a lot of things right. There are good reasons for things like the extra publicity and release constraints placed on podlings, and the proposed model doesn't address how such restrictions would still work without the incubator. I note that many of the original constraints of the Incubator (no releases, etc.) turned out to be unnecessarily strict in practice, so it could well be that everything will work out smoothly also without the extra red tape. But small, reversible steps into such unknown territory are clearly preferable to major leaps of faith. BR, Jukka Zitting - 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: Evolution instead of a revolution (Was: Time to vote the chair?)
On 02/03/2012 08:35 PM, Franklin, Matthew B. wrote: -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Friday, February 03, 2012 2:13 PM To: general@incubator.apache.org Subject: Re: Evolution instead of a revolution (Was: Time to vote the chair?) On Fri, Feb 3, 2012 at 14:04, William A. Rowe Jr. 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 Interesting. What are your thoughts on using this approach for our current discussion? As I said, staying abreast of all the threads where these discussions are occurring is difficult at best and I feel like some are treating certain ideas as foregone conclusions because the entire community hasn't been given the time and opportunity to engage without joining the melee. In the end, I imagine we will end up compromising, but I think it is important to take a step back and let others propose a few strategies without it adding to the current frenzy. Thanks for voicing this Matt, I can't agree more. Last weeks discussions on general@ (and private) really were impossible to follow with everyone jumping the gun or at each others troat, thread hijacking, too many half-baked/refined/opposed/amended/etc. proposals to booth. And it seemed like some were even trying to turn that mess to their advantage by trying to 'force' some conclusions or at least make it seem so. What *is* this rush about, so all of the sudden? There surely is a lot to improve, but rushing into half-backed and not properly thought through radical changes doesn't make sense to me. So, taking a step back, and have the proposers draft up a comprehensible story first, and *please* not on this list but on the wiki, really would be appreciated. Thanks, Ate - 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: Earned autonomy
On 02/06/2012 01:41 AM, Marvin Humphrey wrote: On Sun, Feb 05, 2012 at 01:26:47PM -0600, William A. Rowe Jr. wrote: It might be worthwhile to require 3 ASF members on the initial release, 2 on the next, 1 on the following and then trust the committee to follow the established precedent. +1 Instead of automatically decreasing the count, the device I'd suggest is for the ASF Members on the committee to vote to grant binding votes to individual contributors who they believe have demonstrated a thorough understanding of the Apache Way. Release Managers would be prime candidates; given the challenge of getting an incubating release out the door, an RM will likely have acquired greater expertise than many ASF PMC members who have been voted directly into TLP PMCs. Just being an RM might not be enough, but it would be left to the judgment of the ASF Members / Mentors to vet and vote on candidates. The canonical path towards project autonomy would thus be to make three incubating releases with three different contributors serving as RM. What worries me a lot about the recent proposals, not only the text above, is that project autonomy seems to be measured foremost by just doing proper releases. To me, Apache == Community over code. Code is important, it is what we are all here for (too), but the 'Apache Way' and especially community development and a healthy diversity IMO are even more critical. And especially for reaching project autonomy: *that* IMO is what the Incubator is (or should be) about. Learning the 'tricks' and reasons of doing proper releases isn't easy, and for sure required. But a 'perfect' RM doesn't automatically make a 'perfect' Apache TLP PMC member in my book. Which has been discussed quite a lot as well last week. The thing I'm worried about with the 'radical/revolutionary proposals of creating Incubator projects as TLPs from the start, is that they they also start 'on their own', even with 3 Mentors on board. Meaning: there is no 'glue' or common community between individual 'incubator' TLPs anymore which can help them, with the help of (many more) experienced IPMC members, as well as fellow Incubator PPMC members, to learn the ropes. Beyond merely doing proper releases. I fully agree the current Incubator has its issues, but radically killing it off IMO will also kill off more than just those issues: it will also kill the Incubator community itself. Maybe ComDev can or actually then will have to take over, but we should be really careful before breaking something down without having a replacement 'safety net' in place. Ate This mechanism incentivizes the following healthy habits: * Release early, release often. * Share crucial responsibilities and disperse knowledge amongst multiple contributors. * Learn ASF documentation and relevant legal issues (thoroughly enough to pass muster in the eyes of the ASF Members / Mentors). I don't worry too much that promoting individuals one-at-a-time will create a class of pseudo-BDFL contributors who are "more equal" than others. Every project is going to have people who contribute disproportionally; what we want is for those people to do less coding and more community building and small-m mentoring. projects should earn incremental trust and authority. +1 for incremental increases in autonomy. +1 for making it clear that the increased autonomy is *earned*. We want newcomers to internalize ASF values. We want them to understand both how much we care about doing things the way we do and why. We also have oversight responsibilities that it would be best if we relinquished progressively. Marvin Humphrey - 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: Licence headers in template files
On 02/06/2012 02:44 PM, ant elder wrote: On Mon, Feb 6, 2012 at 1:37 PM, Franklin, Matthew B. wrote: I am sure you know this (especially since you first pointed me at this page), but the release FAQ [1] makes it sound like you need the header, if you assume your templates are source: Which Files Must Contain An ASF License Text? Every source file must contain the appropriate ASF License text. I am no lawyer, so I will defer to someone who has more experience than me to help you determine whether your snippets count as source. I think that is a bug in the Release FAQ. What i've been told in the past but which i can't find links to right now, is that the top level LICENSE file covers everything anyway and the individual license headers aren't strictly necessary especially for source files without significant IP. Really? That then would be quite some 'bug' IMO. I can't recall have heard it said like this before, instead confirmation of the above rule quite often. Exceptions (no headers) only being allowed for sources without real IP value. Ate IMHO if the headers are problematic for Wookie in those files then it would be ok to just not include the header. ...ant - 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: Licence headers in template files
On 02/06/2012 03:30 PM, ant elder wrote: On Mon, Feb 6, 2012 at 2:16 PM, Ate Douma wrote: On 02/06/2012 02:44 PM, ant elder wrote: On Mon, Feb 6, 2012 at 1:37 PM, Franklin, Matthew B. wrote: I am sure you know this (especially since you first pointed me at this page), but the release FAQ [1] makes it sound like you need the header, if you assume your templates are source: Which Files Must Contain An ASF License Text? Every source file must contain the appropriate ASF License text. I am no lawyer, so I will defer to someone who has more experience than me to help you determine whether your snippets count as source. I think that is a bug in the Release FAQ. What i've been told in the past but which i can't find links to right now, is that the top level LICENSE file covers everything anyway and the individual license headers aren't strictly necessary especially for source files without significant IP. Really? That then would be quite some 'bug' IMO. I can't recall have heard it said like this before, instead confirmation of the above rule quite often. Exceptions (no headers) only being allowed for sources without real IP value. Ate IMHO if the headers are problematic for Wookie in those files then it would be ok to just not include the header. ...ant I've just asked for clarification about this over at legal - https://issues.apache.org/jira/browse/LEGAL-124 Seems to me this has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions ...ant - 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: Licence headers in template files
On 02/06/2012 03:40 PM, Jukka Zitting wrote: Hi, [legal-discuss@?] On Mon, Feb 6, 2012 at 10:58 AM, Ross Gardler wrote: Would it be acceptable for these files to *not* have licence headers in them? Going further, you may want to explicitly declare that downstream users have the right to distribute their widgets under whatever terms they choose (without the conditions of section 4 of ALv2), regardless of whether they contain such template content from Wookie. A bit like the GPL exceptions mentioned in http://www.gnu.org/licenses/exceptions.html. Very good point Jukka. AFAIK these templates are indeed intended to be used to kind of 'create' code, which output then preferably not require NOTICE obligations. BR, Jukka Zitting - 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: Licence headers in template files
On 02/06/2012 07:18 PM, Ross Gardler wrote: Sent from my mobile device, please forgive errors and brevity. On Feb 6, 2012 5:26 PM, "Greg Stein" wrote: On Feb 6, 2012 11:41 AM, "sebb" wrote: ... Perhaps the answer to "Why is a licensing header necessary?" http://www.apache.org/legal/src-headers.html#faq-whyheader is relevant here. The README file is generally not going to be modified - or seen in isolation - so it's not so necessary for the end user to know its license from the file itself. However, the template files are specifically designed for modification, and are likely to be seen without the LICENSE file, so IMO the enduser should see the AL header as part of the file. That would be my thinking, too. Not in this specific case, I think. The original template files are not modified directly, neither are the output files. Modifications are by token replacement in the simplest form or by creating a completely new template to override the original (at which point the user can define their own licence). Ross: maybe the analogy with the two ways you can define embedded comments on JSP files might make sense here. In JSP files, which also can be seen as a template solution, including the support for including (embedding) output from a JSP fragment in a larger JSP page, you can use two type of comments: a) standard XML type comments, e.g.
Re: [VOTE] Apache BVal as a TLP
+1, good luck! Ate On 02/08/2012 03:39 PM, Mohammad Nour El-Din wrote: Hi... It has been discussed, since a while, about the graduation of Apache BVal, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. It also has been decided to name the project Apache BVal [6]. The resolution charter content has been discussed and reviewed here [7]. *NOTE*: As per Niall's request, his name has been removed from the proposed PMC [8]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [9] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/tY <http://markmail.org/message/kzqgd7ff7t6p62va> [7] - *http://s.apache.org/49R* [8] - http://s.apache.org/JYS [9] - See below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache BVal Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Bean Validation Specification and its implementation as Apache BVal for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache BVal Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache BVal Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with the Bean Validation Specification and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of "Vice President, Apache BVal" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache BVal Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache BVal Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache BVal Project: - Albert Lee - Carlos Vara Callau - David Jencks - Donald Woods - Gerhard Petracek - Jeremy Bauer - Kevan Lee Miller - Luciano Resende - Matthias Wessendorf - Matthew Jason Benson - Mohammad Nour El-Din - Roman Stumm - Simone Tripodi - Mark Struberg NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache BVal, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache BVal PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache BVal Project; and be it further RESOLVED, that the Apache BVal Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
+1 (binding) Ate On 02/09/2012 04:16 PM, Mattmann, Chris A (388J) wrote: Hi Folks, OK there has been enough discussion here. It's time to VOTE for a new IPMC chair and it looks like the remaining folks (including me) that were in the running have aligned beyond the following nominee: Jukka Zitting. Suffice to say, he was *my first choice* :) In the interest of moving the current discussion matters forward, please VOTE on this recommendation to the board by the IPMC. I'll leave the VOTE open for at least the next 72 hours: [ ] +1 Recommend Jukka Zitting for the IPMC chair position. [ ] +0 Don't care. [ ] -1 Don't recommend Jukka Zitting for the IPMC chair position because... Note that only VOTEs from the Incubator PMC members are binding, but all are welcome to voice their opinion and it will be recorded in the final tallies. Finally, just to note, these VOTEs on personnel are normally the only thing in Apache that is discussed in private (human/social issues), but in the interest of openness and transparency that has been demonstrated here during these discussions, I will hold this VOTE on the public list. Thanks! Cheers, Chris P.S. Here's my +1. Thanks buddy. On Feb 8, 2012, at 3:11 PM, Benson Margulies wrote: I am happy to step out of the way for Jukka. He was clever enough to stay out of the email s*** storm, and that alone, in my mind, renders him most qualified. On Wed, Feb 8, 2012 at 6:02 PM, Christian Grobmeier wrote: I already mentioned that I would have nominated you, and so I am delighted to read your message. It will be very difficult to choose between all these strong candidates. Cheers On Wed, Feb 8, 2012 at 11:49 PM, Jukka Zitting wrote: Hi, After consideration and some convincing (thanks!), I've decided to throw also my hat into the ring as a candidate to be the next chairman of the IPMC. I believe in that role I could be more effective in focusing more of our collective attention at where I think it would do most good - at the actual podlings we're here to help. That said, the current incubation process clearly has problems and I very much support efforts to improve the way we work (even if the result is to replace the Incubator with something better). However, I'd like to leave the leadership on these efforts to others and, as mentioned elsewhere, rather try to act as a balancing force that helps achieve consensus where possible. Should I be elected, I'd resign as the chairman of the Jackrabbit PMC. In fact I think it's in any case high time for Jackrabbit to be rotating that role. Finally, if elected (and assuming the IPMC still exists), I'd serve for at most two years before calling for a re-election, or possibly much less if I don't find enough free cycles to perform the duty as well as it should. BR, Jukka Zitting ++ 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 ++ - 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: [DISCUSS] [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
On 02/09/2012 05:54 PM, Bertrand Delacretaz wrote: On Thu, Feb 9, 2012 at 5:49 PM, Jim Jagielski wrote: ...I suggest that this VOTE be withdrawn, and a true election, with all candidates be done... Agreed - I think Chris assumed there was only one candidate, but it's just an assumption AFAICS. I agree. I already voted for Jukka, under the impression only he now remained candidate. Seeing that not being the case (or properly checked), I'm retracting my preliminary vote for Jukka (for now). Ate -Bertrand - 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: [DISCUSS] [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
On 02/09/2012 05:58 PM, Mattmann, Chris A (388J) wrote: On Feb 9, 2012, at 8:49 AM, Jim Jagielski wrote: On Feb 9, 2012, at 11:10 AM, Andrus Adamchik wrote: Well, if there's an election, the fair thing is to include all candidates and see who gets the majority. A vote on just one candidate is odd. Agreed. I suggest that this VOTE be withdrawn, and a true election, with all candidates be done. What's preventing anyone from calling a VOTE on any other candidate? Of which, as I understand it, there are none. Noel is the existing chair. If this VOTE is *not* successful, then he remains the chair. If it is, successful, then the recommendation is to change him out as the chair. Did I miss something by actually "trying" to make progress here? For one, how or when would you call this vote successful? If there is a +3, a majority of every IPMC member, a majority from only those who voted, etc. With Noel not being voted on *at the same time*, there is no proper comparison possible on the result (votes for Jukka) and 'undetermined result (support for Noel). Ate 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 ++ - 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: [DISCUSS] Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
Thanks many times Noel! This also makes (for me) voting for Jukka again a proper process. I'm therefore reconfirming my earlier retracted vote for Jukka, +1 Ate On 02/10/2012 03:31 AM, Noel J. Bergman wrote: Ross Gardler wrote: I'm ready to vote, but Chris said "it looks like the remaining folks (including me) that were in the running have aligned beyond the following nominee:" Where is the mail from Noel saying he is no longer standing? Have I missed something? There wasn't one. I was traveling when the vote started. No worries. I have no issue with standing down after 8 years, and Jukka is an excellent and active successor. I was exceedingly pleased to see his message that he had reconsidered, was willing to stand as Incubator PMC Chair, and would rotate out of the JackRabbit VP position. --- Noel - 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] Release Apache Rave 0.8-incubating
On 02/16/2012 04:05 PM, Karl Wright wrote: What is the license on ecj-3.7.jar (Eclipse JDT Java compiler)? If you are going to redistribute it you should provide that info somewhere unless it's Apache licensed. The ecj is EPL 1.0 license, and explicitly mentioned and covered in the root LICENSE file of the binary distribution. Thanks, Karl On Thu, Feb 16, 2012 at 10:00 AM, Karl Wright wrote: I'll have a look at it. Stay tuned... Karl On Thu, Feb 16, 2012 at 9:20 AM, Franklin, Matthew B. wrote: We still need one more IPMC member vote for the release. Does anyone have time to take a look? Thanks in advance, -Matt On 2/12/12 9:29 PM, "Franklin, Matthew B." wrote: This is the seventh incubator release for Apache Rave, with the artifacts being versioned as 0.8-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/U8G RESULT: http://s.apache.org/Fcv IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.8-incubating/CHANGEL O G SVN source tag (r1163402): https://svn.apache.org/repos/asf/incubator/rave/rave-master-pom/tags/0.8-i n cubating/ SVN source tag (r1163411): https://svn.apache.org/repos/asf/incubator/rave/tags/0.8-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-195/ Source releases: https://repository.apache.org/content/repositories/orgapacherave-195/org/a p ache/rave/rave-master/0.8-incubating/rave-master-0.8-incubating-source-rel e ase.zip https://repository.apache.org/content/repositories/orgapacherave-195/org/a p ache/rave/rave-project/0.8-incubating/rave-project-0.8-incubating-source-r e lease.zip Binary releases http://people.apache.org/builds/incubator/rave/0.8-incubating/apache-rave- 0 .8-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.8-incubating/apache-rave- 0 .8-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Graduate Apache Rave as TLP
Hi IPMCers and Incubator community,
Apache Rave entered the Incubator almost 1 year ago on March 1st 2011.
Since then Rave provided 7 incubator releases, added 3 more committers/PPMC
members, and shows a steady growth of community and interest in general.
Diversity is great, as is the collaboration between the project members and with
the community as a whole.
The Rave PPMC decided it is now time to consider graduation from the Incubator
and held a community vote which was accepted unanimous and includes the support
of the 4 Rave Mentors [1].
I therefore now request the IPMC to vote on recommending the graduation of Rave
with the below resolution [2] to the ASF Board.
Please cast your votes:
[ ] +1 to recommend graduation of Apache Rave as TLP
[ ] +0 don't care.
[ ] -1 no, don't recommend yet, because ...
This vote will be open for 72 hours.
Regards, Ate
[1] http://s.apache.org/TBH
[2] https://issues.apache.org/jira/browse/RAVE-428, and copied below:
X. Establish the Apache Rave Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to a widgets-based, web-and-social
mashup platform for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Rave Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache Rave Project be and hereby is
responsible for the creation and maintenance of software
related to a widgets-based, web-and-social mashup platform;
and be it further
RESOLVED, that the office of "Vice President, Apache Rave" be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Rave Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Rave Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Rave Project:
* Ard Schrijvers
* Ate Douma
* Bas Zoetekouw
* Gerald Guo
* Hadrian Zbarcea
* Jasha Joachimsthal
* Jesse Ciancetta
* Joost van Dijk
* Maarten Kremers
* Marlon Pierce
* Matt Franklin
* Niels van Dijk
* Okke Harsta
* Raminder Singh
* Ross Gardler
* Sander van der Waal
* Scott Wilson
* Sean Cooper
* Suresh Marru
* Tony Carlucci
* Unico Hommes
* Venkat Mahadevan
* Woonsan Ko
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matt Franklin
be appointed to the office of Vice President, Apache Rave, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache Rave PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Rave Project; and be it further
RESOLVED, that the Apache Rave Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Rave podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator Rave podling encumbered upon the Apache Incubator
Project are hereafter discharged.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Rave as TLP
+1 (binding) On 02/27/2012 01:26 PM, Ate Douma wrote: Hi IPMCers and Incubator community, Apache Rave entered the Incubator almost 1 year ago on March 1st 2011. Since then Rave provided 7 incubator releases, added 3 more committers/PPMC members, and shows a steady growth of community and interest in general. Diversity is great, as is the collaboration between the project members and with the community as a whole. The Rave PPMC decided it is now time to consider graduation from the Incubator and held a community vote which was accepted unanimous and includes the support of the 4 Rave Mentors [1]. I therefore now request the IPMC to vote on recommending the graduation of Rave with the below resolution [2] to the ASF Board. Please cast your votes: [ ] +1 to recommend graduation of Apache Rave as TLP [ ] +0 don't care. [ ] -1 no, don't recommend yet, because ... This vote will be open for 72 hours. Regards, Ate [1] http://s.apache.org/TBH [2] https://issues.apache.org/jira/browse/RAVE-428, and copied below: X. Establish the Apache Rave Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a widgets-based, web-and-social mashup platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Rave Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Rave Project be and hereby is responsible for the creation and maintenance of software related to a widgets-based, web-and-social mashup platform; and be it further RESOLVED, that the office of "Vice President, Apache Rave" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Rave Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Rave Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Rave Project: * Ard Schrijvers * Ate Douma * Bas Zoetekouw * Gerald Guo * Hadrian Zbarcea * Jasha Joachimsthal * Jesse Ciancetta * Joost van Dijk * Maarten Kremers * Marlon Pierce * Matt Franklin * Niels van Dijk * Okke Harsta * Raminder Singh * Ross Gardler * Sander van der Waal * Scott Wilson * Sean Cooper * Suresh Marru * Tony Carlucci * Unico Hommes * Venkat Mahadevan * Woonsan Ko NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matt Franklin be appointed to the office of Vice President, Apache Rave, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Rave PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Rave Project; and be it further RESOLVED, that the Apache Rave Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Rave podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Rave podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote: Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@ I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. I agree. And specifically as this seems to concern compatibility support for Cloudera own API, only needed for Cloudera customers. Keeping those com.cloudera packages in the code could imply a specific preference and affiliation with an external and commercial entity, thereby potentially jeopardizing the project independence. While I don't expect there was any intend to do so, even the impression itself can be considered harmful to the ASF and the project. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. That sounds reasonable and hopefully easy to do (if not this case might even be more worrisome then). I'm not really sure though if Apache Extras is an appropriate location either. I think Apache Extras intends to convey an affiliation with the ASF and probably should value project independence high as well. If this really only concerns a thin layer to provide compatibility only for Cloudera's API, hosting and maintenance of this should be the responsibility of Cloudera itself. Ate Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasuluwrote: On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting wrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 02:45 PM, Greg Stein wrote: On Feb 29, 2012 8:07 AM, "Alex Karasulu" wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein wrote: ... They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sorry but I don't think that's right. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? It's fine but those com.cloudera packages don't need to be hosted here. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? I bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. To me this actually *is* the question at hand, but from a different perspective than you bring up. In my initial response on this I raised this as a question about affiliation and independence of the project towards the community. For all I know Cloudera might not get pissed off at all if arbitrary packages in their namespace are created. There are plenty Cloudera committers on Sqoop which could (legally be allowed to) do this themselves. So to me this is not a legal problem but one of community, diversity and independence of affiliation. How will the community perceive the project independence from Cloudera if it carries, and maintains a 3rd party namespace, to which several committers are commercially affiliated as employee. That IMO should be an concern for the Foundation, not solely a 'Right' of a PMC to decide on themselves. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 03:52 PM, Ate Douma wrote: On 02/29/2012 02:45 PM, Greg Stein wrote: On Feb 29, 2012 8:07 AM, "Alex Karasulu" wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein wrote: ... They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sorry but I don't think that's right. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? It's fine but those com.cloudera packages don't need to be hosted here. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? I bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. To me this actually *is* the question at hand, but from a different perspective than you bring up. In my initial response on this I raised this as a question about affiliation and independence of the project towards the community. For all I know Cloudera might not get pissed off at all if arbitrary packages in their namespace are created. There are plenty Cloudera committers on Sqoop which could (legally be allowed to) do this themselves. So to me this is not a legal problem but one of community, diversity and independence of affiliation. How will the community perceive the project independence from Cloudera if it carries, and maintains a 3rd party namespace, to which several committers are commercially affiliated as employee. That IMO should be an concern for the Foundation, not solely a 'Right' of a PMC to decide on themselves. To elaborate a bit more: to me project independence is one of the most important values the ASF stands for. IMO many of our rules and guidelines are founded on that principle. The (required) usage of the org.apache namespace is one way we tell the community: this is Apache, free to use and independent of possible 3rd party donations, claims or direction. While for SOME use-cases there might be valid arguments we MUST use other namespaces (cleanroom spec. implementations for instance), or if a project *itself* needs to decorate a 3rd party dependency, IMO the base principle SHOULD be to stay away from including 3rd party namespaces. I would propose that an ASF project SHOULD not use 3rd party namespaces, unless there is a very strong and logical requirement to do so. I'm explicitly not using the term MUST here. In the case of Sqoop, at least AFAIK, there is no *requirement* to include the com.cloudera namespace, other than as a convenience to the community. To me that doesn't sound as a strong enough argument. Allowing for such use-cases only muddies the water and will dilutes the ASF principle of project independence. Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Graduate Apache Rave as TLP
After 72+ hours this vote has passed with the following tally of 13 votes in total, including +11 binding IPMC member votes: +1: Ross Gardler* Chris Mattmann* Arje Cahn Hadrian Zbarcea* Ate Douma* Alex Karasulu* Jukka Zitting* Alan D. Cabrera* Jean-Baptiste Onofré* Niall Pemberton* Henry Saputra Upayavira* Sylvain Wallez* * indicates IPMC member I will send the proposed resolution to the board for inclusion in their next board meeting. Thanks to everybody for their vote, support and feedback during incubation. Regards, Ate On 02/27/2012 01:26 PM, Ate Douma wrote: Hi IPMCers and Incubator community, Apache Rave entered the Incubator almost 1 year ago on March 1st 2011. Since then Rave provided 7 incubator releases, added 3 more committers/PPMC members, and shows a steady growth of community and interest in general. Diversity is great, as is the collaboration between the project membersand with the community as a whole. The Rave PPMC decided it is now time to consider graduation from the Incubator and held a community vote which was accepted unanimous and includes thesupport of the 4 Rave Mentors [1]. I therefore now request the IPMC to vote on recommending the graduationof Rave with the below resolution [2] to the ASF Board. Please cast your votes: [ ] +1 to recommend graduation of Apache Rave as TLP [ ] +0 don't care. [ ] -1 no, don't recommend yet, because ... This vote will be open for 72 hours. Regards, Ate [1] http://s.apache.org/TBH [2] https://issues.apache.org/jira/browse/RAVE-428, and copied below: X. Establish the Apache Rave Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a widgets-based, web-and-social mashup platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Rave Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Rave Project be and hereby is responsible for the creation and maintenance of software related to a widgets-based, web-and-social mashup platform; and be it further RESOLVED, that the office of "Vice President, Apache Rave" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Rave Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Rave Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Rave Project: * Ard Schrijvers * Ate Douma * Bas Zoetekouw * Gerald Guo * Hadrian Zbarcea * Jasha Joachimsthal * Jesse Ciancetta * Joost van Dijk * Maarten Kremers * Marlon Pierce * Matt Franklin * Niels van Dijk * Okke Harsta * Raminder Singh * Ross Gardler * Sander van der Waal * Scott Wilson * Sean Cooper * Suresh Marru * Tony Carlucci * Unico Hommes * Venkat Mahadevan * Woonsan Ko NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matt Franklin be appointed to the office of Vice President, Apache Rave, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Rave PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Rave Project; and be it further RESOLVED, that the Apache Rave Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Rave podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Rave podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][IPMC] Graduate RAT as Apache Creadur Project
On 03/11/2012 08:42 PM, Robert Burrell Donkin wrote: -8<--- [ ] +1 Recommend The Apache Creadur Proposal To The Board (below) [ ] +0 [ ] -0 [ ] -1 Do not graduate Rat podling -- +1 (binding) Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] CloudStack for Apache Incubator
+1 (binding)
Ate
On 04/10/2012 03:32 AM, Kevin Kluge wrote:
Hi All. I'd like to call for a VOTE for CloudStack to enter the Incubator.
The proposal is available at [1] and I have also included it below. Please
vote with:
+1: accept CloudStack into Incubator
+0: don't care
-1: do not accept CloudStack into Incubator (please explain the objection)
The vote is open for at least 72 hours from now (until at least 19:00 US-PST on
April 12, 2012).
Thanks for the consideration.
-kevin
[1] http://wiki.apache.org/incubator/CloudStackProposal
Abstract
CloudStack is an IaaS ("Infrastracture as a Service") cloud orchestration
platform.
Proposal
CloudStack provides control plane software that can be used to create an IaaS
cloud. It includes an HTTP-based API for user and administrator functions and a
web UI for user and administrator access. Administrators can provision physical
infrastructure (e.g., servers, network elements, storage) into an instance of
CloudStack, while end users can use the CloudStack self-service API and UI for
the provisioning and management of virtual machines, virtual disks, and virtual
networks.
Citrix Systems, Inc. submits this proposal to donate the CloudStack source code,
documentation, websites, and trademarks to the Apache Software Foundation
("ASF").
Background
Amazon and other cloud pioneers invented IaaS clouds. Typically these clouds provide virtual
machines to end users. CloudStack additionally provides baremetal OS installation to end users via
a self-service interface. The management of physical resources to provide the larger goal of cloud
service delivery is known as "orchestration". IaaS clouds are usually described as
"elastic" -- an elastic service is one that allows its user to rapidly scale up or down
their need for resources.
A number of open source projects and companies have been created to implement IaaS
clouds. Cloud.com started CloudStack in 2008 and released the source under GNU General
Public License version 3 ("GPL v3") in 2010. Citrix acquired Cloud.com,
including CloudStack, in 2011. Citrix re-licensed the CloudStack source under Apache
License v2 in April, 2012.
Rationale
IaaS clouds provide the ability to implement datacenter operations in a
programmable fashion. This functionality is tremendously powerful and benefits
the community by providing:
- More efficient use of datacenter personnel
- More efficient use of datacenter hardware
- Better responsiveness to user requests
- Better uptime/availability through automation
While there are several open source IaaS efforts today, none are governed by an
independent foundation such as ASF. Vendor influence and/or proprietary
implementations may limit the community's ability to choose the hardware and
software for use in the datacenter. The community at large will benefit from
the ability to enhance the orchestration layer as needed for particular
hardware or software support, and to implement algorithms and features that may
reduce cost or increase user satisfaction for specific use cases. In this
respect the independent nature of the ASF is key to the long term health and
success of the project.
Initial Goals
The CloudStack project has two initial goals after the proposal is accepted and
the incubation has begun.
The Cloudstack Project's first goal is to ensure that the CloudStack source
includes only third party code that is licensed under the Apache License or
open source licenses that are approved by the ASF for use in ASF projects. The
CloudStack Project has begun the process of removing third party code that is
not licensed under an ASF approved license. This is an ongoing process that
will continue into the incubation period. Third party code contributed to
CloudStack under the CloudStack contribution agreement was assigned to
Cloud.com in exchange for distributing CloudStack under GPLv3. The CloudStack
project has begun the process of amending the previous CloudStack contribution
agreements to obtain consent from existing contributors to change the
CloudStack project's license. In the event that an existing contributor does
not consent to this change, the project is prepared to remove that
contributor's code. Additionally, there are binary dependencies on
redistributed libraries that
are not provided with an ASF-approved license. Finally, the CloudStack has source files incorporated from third parties that were not provided with an ASF-approved license. We have begun the process of re-writing this software. This is an ongoing process that will extend into the incubation period. These issues are discussed in more detail later in the proposal.
Although CloudStack is open source, many design documents and discussions that
should have been publicly available and accessible were not publicized. The
Project's second goal will be to fix this lack of tra
Re: [DISCUSS] Apache Airavata 0.2-Incubating RC5
I haven't seen anyone respond to this yet and I'm in a tight spot myself to make time for it. I'll try to free up some by tomorrow though, please accept my apologies for the delay. Ate On 04/22/2012 06:40 PM, Mattmann, Chris A (388J) wrote: Sorry to cross post here, but I think we need to get help from the Incubator vets and not just burden Ate here. I also think it would be great to get a fresh opinion. Incubator licensing/notice file experts, if you could help out the Airavata community here, I would sincerely appreciate it. Cheers, Chris On Apr 22, 2012, at 7:42 AM, Suresh Marru wrote: Hi All, Before I call a vote on the 0.2-incubating release, Can you please verify if all license and notice file requirements are met correctly? Source release: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC5/apache-airavata-0.2-incubating-SNAPSHOT-src.tar.gz Binary release: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC5/apache-airavata-0.2-incubating-SNAPSHOT-bin.tar.gz Hi Ate, Thank you very much for all the help and guidance so far on the L, N, D requirements. Can you please verify, if the above releases confirm the legal guidelines? It will be great if you can find time to verify so we can save time with voting iterations. I really its very time taking and will appreciate your effort. Thanks, Suresh ++ 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 ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Airavata 0.2-Incubating RC5
I've reviewed this SNAPSHOT release candidate primarily on compliance and completeness of the L&N files as requested. One other thing I noticed: the README points to http://www.airavata.org Seems like the www.airavata.org domain is under control of this project as it does renders as a frameset pointing to the official airavata incubator site. I'm curious what the ASF policy is on such separate project related domains? And especially with respect to ownership/control of it. Who actually does own this domain? Should this be a concern to the ASF? Now concerning the -src and -bin release candidates and the L&N files, I think this has been greatly improved since the last candidate. Kudos everyone who helped with this: quite a lot of work! But I can't help it to point out a few remaining quirks :) * source NOTICE and LICENSE file seem fine by me ;) * binary LICENSE file - it contains some duplications of the same (set of) licenses, I think starting on line # 2085: "APACHE JACKRABBIT SUBCOMPONENTS" Actually that part which follows and which possible has been copied from a Jackrabbit provided LICENSE file is a bit more nicely formatted (e.g. like for the javax.jcr part). - I haven't checked if *every* bundled jar is now properly covered in the LICENSE file (where applicable) but with the size (2k+ lines) and coverage of the LICENSE file I kind of now 'trust' they are ;) * binary NOTICE file - I think there are some unneeded/unwanted entries still. Some notices and copyright statements should not legally be needed nor are they requested. For instance for BSD/MIT like licenses which already are provided for verbatim in the LICENSE file itself, there is no need to (and thus should not) be covered *also* in the NOTICE file. Having those in the LICENSE file should be enough. And certainly so if the 3rd party artifact doesn't have or require an explicit NOTICE file itself. I think this applies to the NOTICE entries for SLF4J, DOM4J, ICU4J, Jettison, etc. Please do check if each of these notices really are necessary/required. - A different thing is the NOTICE provided for commons-logging (1.1.1). The commons-logging jar come with a NOTICE file of its own (being an ASF release it should). But IMO the additional content copied verbatim from that NOTICE file can be ignored and thus removed. It concerns the following section: This product includes/uses software(s) developed by 'an unknown organization' - Unnamed - avalon-framework:avalon-framework:jar:4.1.3 - Unnamed - log4j:log4j:jar:1.2.12 - Unnamed - logkit:logkit:jar:1.0.1 Only log4j is actually bundled with airavata and as an ASF artifact doesn't need extra NOTICE coverage. And as the other referenced artifacts aren't included or used there is no need to 'honor' this part from the common-logging NOTICE file. The ASL 2.0 license sections 4.d) says: "[...], excluding those notices that do not pertain to any part of the Derivative Works." Another thing I noticed in the binary distribution: some of the samples included come with both src and (maven build) target folders, for example the /samples/complex-math-service as well as a few others. You might consider cleaning this up a bit further. In addition, those samples modules also have additional NOTICE and LICENSE files in their src/main/resources folders, but AFAIK these are not or no longer used/bundled in the build artifact. Possibly outdated/leftover? IMO none of the above really are release blockers, so my overall impression: awesome work guys! Regards, Ate On 04/24/2012 05:28 PM, Ate Douma wrote: I haven't seen anyone respond to this yet and I'm in a tight spot myself to make time for it. I'll try to free up some by tomorrow though, please accept my apologies for the delay. Ate On 04/22/2012 06:40 PM, Mattmann, Chris A (388J) wrote: Sorry to cross post here, but I think we need to get help from the Incubator vets and not just burden Ate here. I also think it would be great to get a fresh opinion. Incubator licensing/notice file experts, if you could help out the Airavata community here, I would sincerely appreciate it. Cheers, Chris On Apr 22, 2012, at 7:42 AM, Suresh Marru wrote: Hi All, Before I call a vote on the 0.2-incubating release, Can you please verify if all license and notice file requirements are met correctly? Source release: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC5/apache-airavata-0.2-incubating-SNAPSHOT-src.tar.gz Binary release: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC5/apache-airavata-0.2-incubating-SNAPSHOT-bin.tar.gz Hi Ate, Thank you very much for all the help and guidance so far on the L, N, D requirements. Can you please verify, if the above releases confirm the legal guidelines? It will be great if you can find time to verify so we can save
Re: [PROPOSAL] Allura Proposal
Dave should mail his incubator wiki id here and request being added to the wiki ContributersGroup [1]. Once added to this page (by an incubator wiki admin) Dave can add/edit wiki pages himself. Ate [1] http://wiki.apache.org/incubator/ContributorsGroup On 06/19/2012 11:28 AM, Ross Gardler wrote: I'm not sure how to give you edit privs but I have made the change you suggest. Ross On 19 June 2012 01:34, Dave Brondsema wrote: I'd like to clarify the "Current Status" section to say "Apache License 2.0" -- I didn't catch that when we were editing the initial proposal text. But it doesn't look like I have permission to edit the wiki page. If that's something that can be granted, my wiki username is DaveBrondsema On Mon, Jun 18, 2012 at 5:00 PM, Ross Gardlerwrote: Couple of minor issues: Firstly this needs to go into the incubator Wiki - done see http://wiki.apache.org/incubator/AlluraProposal Under "reliance on salaried developers" the proposal states "At present, almost all development on Allura is done on salaried time. It is understood that expanding the developer community to the point where this is not the case, is a goal of incubation." This isn't quite accurate. We don't have a problem with salaried time, we only worry about single sources of salaried time. I've taken the liberty (as a mentor) to change it to "At present, almost all development on Allura is done on salaried time ***from a single company***. It is understood that expanding the developer community to the point where this is not the case, is a goal of incubation." Ross On 18 June 2012 17:17, Rich Bowen wrote: PROPOSAL: Admit Allura to the Apache Incubator = Abstract Allura is a modular and extensible free/open source software platform for software development. You can read more about Allura’s feature set in the Allura wiki at https://sourceforge.net/p/allura/wiki/Features/ = Proposal Allura is an open source implementation of a software "forge", a suite of web applications that manages source code repositories, bug reports, discussions, mailing lists, wiki pages, blogs and more for any number of individual projects as well as for collections of projects. SourceForge.net is running an instance of Allura, and Allura itself is a project managed there: http://sf.net/p/allura/. Additionally, http://software.dlr.de/ is using Allura. The name Allura itself has two meanings. It’s Sardinian slang for “And then …” It’s also the name of Princess Allura, from Voltron. Stories vary, as with any good project name. Allura has been designed to be the code and project hosting platform for SourceForge, the largest place for Open Source software tools and applications: home to over 3 million users, hosting a catalog of over 300,000 distinct projects and serving over 40 million unique visitors per month and over 15 million downloads per week. Allura was designed to be scalable, delivering only what projects need, and our aim is to collaborate with ASF to get the wider contributions and make it the richest all-in-one solution to design, write, debug and promote individual projects as well as collections of projects. = Background Since the late 1990’s, SourceForge has provided a place for people to create and run Open Source projects. In the last two years, the back-end has been completely rewritten, and has been Open Source since the beginning of that process. This rewritten code comprises Allura. Allura is written in Python, and provides a framework within which one can select source control (svn, git, mercurial, etc), issue trackers, discussion forums, and various other tools associated with the software development process. SourceForge.net itself is running on an instance of Allura. = Rationale Software development projects can be complicated beasts. By providing all of the necessary tools, and offering a choice of tools in most categories, Allura promotes best practice in software development. This product can be used either inside a company - as some are already doing at their own premise, such as http://software.dlr.de/ - or as an open forge like SourceForge, to encourage software projects to be done right. As Apache’s mission is to produce software for the public good, the Allura project fits right in by enabling others to also produce software using good development practices. We also believe strongly in giving project communities as much control over their destiny as possible, even if this means enabling them to take their project elsewhere. Allura is built to give projects complete control over their data, and Allura itself being Open Source contributes to this by giving them input into the hosting environment as well. Having Allura within Apache, and outside of direct SourceForge control, will give our development communities even more control of their projects. = Current Status Allura has
Re: [VOTE] Apache Airavata 0.3-Incubating RC3
+1 (binding, as well as a late Airavata PPMC Mentor vote) Ate On 06/18/2012 12:27 AM, Suresh Marru wrote: Apache Airavata (Incubating) is pleased to call for a vote on the following Apache Airavata 0.3-incubating release candidate artifacts. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on airavata-dev: Community VOTE THREAD: http://s.apache.org/uk RESULT: - http://s.apache.org/te Detailed change log/release notes: https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.3-incubating/RELEASE_NOTES All Release Artifacts: http://people.apache.org/builds/incubator/airavata/0.3-incubating/RC3/ PGP release keys (signed using 617DDBAD): https://svn.apache.org/repos/asf/incubator/airavata/KEYS Specific URL's: SVN source tag (1348704): https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.3-incubating/ Source release: http://people.apache.org/builds/incubator/airavata/0.3-incubating/RC3/airavata-0.3-incubating-source-release.zip Binary Artifacts: http://people.apache.org/builds/incubator/airavata/0.3-incubating/RC3/apache-airavata-0.3-incubating-bin.tar.gz http://people.apache.org/builds/incubator/airavata/0.3-incubating/RC3/apache-airavata-0.3-incubating-bin.zip Maven staging repo: https://repository.apache.org/content/repositories/orgapacheairavata-220/ Please verify the artifacts and vote. The vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Airavata 0.4-Incubating RC1
Hi Suresh, I looked at the two issues raised and IMO these do not pose as blockers for this release, so +1 from me on this release candidate (binding and Mentor) More feedback below. Regards, Ate On 08/01/2012 03:46 PM, Suresh Marru wrote: Hi All, The VOTE is called for a lazy consensus and is close to 72 hours. Just in case if there are any further comments, I will leave the vote open for 6 more hours. If you have any concerns or comments with this release please voice your opinions and vote now. Thanks, Suresh On Jul 31, 2012, at 10:09 AM, Alexei Fedotov wrote: Suresh, I am not a lawyer, and cannot yet decide if any of issues is serious enough. Let mentors decide. I'm glad to see that you have cleaned the trunk. -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Tue, Jul 31, 2012 at 5:59 PM, Suresh Marru wrote: Hi Alexei, Thank you for taking time to review the release. Please see comments below: On Jul 29, 2012, at 4:15 PM, Alexei Fedotov wrote: Hello Suresh, hope the following questions could make the release better. 1. Why root NOTICE and LICENSE files are nearly empty, while the files at modules/distribution/src/main/resources contain all required info on licenses? Why not to move files to the root? The root NOTICE & LICENSE are for source code and the ones in modules/distribution/src/main/resources are for binary release. Since the source code does not have any third party codes, you will see it have only APL V2 where as the binary ones include all L&D of all the bundled jars. 2. I have noticed import com.sun.tools.doclets.internal.toolkit.MethodWriter at modules/ws-messenger/samples/messagebroker/wse-multiple-producers-consumers/src/org/apache/airavata/wsmg/samples/wse/Consumer.java MethodWriter license seems to be GPL, see below. If the link below is correct, we get linking to GPL code. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/tools/doclets/internal/toolkit/MethodWriter.java?av=h It seems the class is not used anyway. Why not to remove it? Thanks for this catch, too bad to have this unused import linger through in a stale sample code. Since it was an unused import and it was not linked to any code, is it a blocker for the release?, I removed it in the trunk though (r1367537). While an annoyance I wouldn't call this 'linking' to GPL code. It only means you'll need a Sun JDK to compile the project, but most likely you don't even need it at runtime if the compiler is smart enough to drop this unused import. At any rate this really is only a mistake without intended GPL linking nor any actual usage. And fixed already. So, really not an issue at all IMO. 3. I wonder if the parts of work (modules/xbaya-gui/src/main/java/org/apache/airavata/xbaya/ui/graph/system/DifferedInputNodeGUI.java) containing APL along with Indiana University Extreme! Lab Software License can be just licensed under Apache License in the release (for usage simplicity). The initial authors seem to be the same as Apache committers. Yes your assertion is right, during incubation the IP was donated from Indiana University to Apache and headers were properly replaced. Tracking back on the file you pointed out (and couple of others) were added to the trunk from donation area and added the APL header but a legacy snipped was left out at the bottom of the files, I removed them now. The RAT check passes on all the code since all java have APL headers and probably ignored these stale snippets at the bottom. Same thing here. The appropriate license header was already in place, the old one at the bottom doesn't 'negate' the one on top. It wasn't a problem to begin with, even less so now after fixing it in trunk. Appreciate your attention to detail. Do you think we should call a new RC or 2 and 3 are non-blockers for the release? Thanks, Suresh -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Sun, Jul 29, 2012 at 6:37 PM, Suresh Marru wrote: Apache Airavata (Incubating) is pleased to call for a vote on the following Apache Airavata 0.4-incubating release candidate artifacts: We are requesting a lazy consensus vote, as we have already received 3 binding IPMC +1 votes during the release voting on airavata-dev: Community VOTE & RESULT Thread: http://markmail.org/thread/4nbaxvi5byjpvhgq Detailed change log/release notes: https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.4-incubating/RELEASE_NOTES All Release Artifacts: http://people.apache.org/builds/incubator/airavata/0.4-incubating/RC1/ PGP release keys (signed using 617DDBAD): https://svn.apache.org/repos/asf/incubator/airavata/KEYS Specific URL's: SVN source tag (1364995): https://svn.apache.org/repos/asf/incubator/airavata/tags/airava
Re: What's up with WSRP4J?
David Sean Taylor wrote: On Oct 23, 2008, at 6:54 AM, Ralph Goers wrote: That is a very good question. I do know that we did a portal evaluation earlier this year and every vendor was planning on having WSRP 2.0 support during this year. The spec was finally approved this year. I seem to recall the OASIS site had links to the encumbrances. I can't find them now. My observation is there hasn't been much interest in the project or the standard.There are so many issues related to the project that, unless someone steps up and starts working on this project, Im afraid its going to continue down the same path. I would hate to see that happen. If this standard is relevant, then we really should support this standard here at Apache Portals. I want lto second this, and add some additional information and opinion. In my view WSRP(4J) might very well become much more important in the near future, definitely with the improvements and alignment with the Portlet 2.0 (JSR-286) specification of the latest WSRP 2.0. In the last year I have had concrete requests from several (extremely) large organizations, both governmental and commercial, for support and general information about the status of WSRP4J. And I've been involved in an actual test/evaluation project for the Dutch government to validate the feasibility to use WSRP to integrate and *standardize* application integration across organizations. That test project, while still limited in scope, was quite successful and very well might lead to follow up activities. The definite increase in adoption of portal and portlet technology we are experiencing, especially in the area of cross-application/organization integration, in my view shows that the market is finally recognizing the real benefits of these solutions based on open standards. The problem of course is that WSRP4J still is in incubation and to be honest hasn't seem much activities for some years now. Part of the reason in my view (and possibly a big one) is the *still* fuzzy state of potential patent claims on WSRP 1.0. David Taylor and myself have been pursuing this over the last year to get resolved, but we're kind of stuck with that right now. Lack of time is large part of the reason, but also lack of insight and experience how to proceed (note: we have been in contact with legal-internal@ too). Anyway, I think WSRP4J *can* have a great usage and interest *if* we can get it stabilized, spec compliant, ASF license compliant (like currently there is some Hibernate usage still in the code base), *and* out of the incubator. To be clear on this: WSRP4J already *is* used quite a lot, even while its not formally endorsed by the ASF yet. Several other open-source portals are using it: at least Liferay, uPortal, and even Cocoon Portal (not sure if that's still true though). Furthermore, I've knowledge it has been forked and adapted by and for several closed source solutions as well. And not to forget: IBM donated the initial code-base for WSRP4J so they might very well be using it themselves too. We are in a kind of limbo here though: without proper developer and community support how can it ever get out of incubator? But, because its not formally endorsed, those big clients like I mentioned above won't/can't touch it and thus are likely going looking somewhere else. I for one, and I know a few other (also committers) would definitely like to breath new life into the WSRP4J project and for instance get it integrated and provided out-of-the-box with Jetspeed. If we can get a resolution on these legal issues soon, the state of the project could be improved a lot in a short time (its not *that* big a project to be honest), which I think then definitely will result in a much more interested and growing community (there is a large group of silent subscribers to the wsrp4j lists). Without such a resolution on the legal status though, I'm afraid I can't nor want to invest valuable time in something which we then might never be able to use... Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's up with WSRP4J?
Bertrand Delacretaz wrote: Hi Ate, Thanks very much for your detailed reply. I'll comment on what's specific to the incubating status. On Thu, Oct 23, 2008 at 11:53 PM, Ate Douma <[EMAIL PROTECTED]> wrote: ...The problem of course is that WSRP4J still is in incubation and to be honest hasn't seem much activities for some years now. Part of the reason in my view (and possibly a big one) is the *still* fuzzy state of potential patent claims on WSRP 1.0 Does that patent issue mean that an ASF release of the WSRP4J would not be safe from a legal point of view? Or is it just that users might be afraid of using it? The patent claim (as it stands right now, but: IANAL) seems to require for any usage an *individual* license, e.g. there is no waver (yet) for the ASF to allow release and distribution without putting this burden onto the end users again. In my view, this would not be in compliance with the ASF license and thus a blocker for an ASF endorsed release. Now, end users might or might now be afraid to use it. Its (again in my view, and again: IANAL) questionable to say the least if there would ever be a claim by this one patent holder, but legally it is unclear if/how we can make sure (so nor can the end-users) without having this go to court at least once or get this waver from the acclaimed patent holder. ...We are in a kind of limbo here though: without proper developer and community support how can it ever get out of incubator?... Assuming the legal issue can be worked out, would the portals PMC be prepared to "adopt" the WSRP4J code and maintain it in the future? Definitely, and we already did (for as much as possible)! AFAIK The Portal PMC accepted long time ago to do so. This was before I became member though and I haven't be able to find concrete references in the mail archives for this. But the Portals PMC has taken responsibility for reporting WSRP4J status to the board, the code-base is hosted underneath the portals root folder in svn and the project website is also hosted under portals.apache.org. Note: possibly part of the reason the WSRP4J status reports have not always been delivered is that the separate incubator status reports are not in schedule with the separate Portals status report, and of course that there hasn't been much to report either. But when it was, the *Portals* status reports also included the needed information to the board AFAIK. ...If we can get a resolution on these legal issues soon, the state of the project could be improved a lot in a short time (its not *that* big a project to be honest), which I think then definitely will result in a much more interested and growing community (there is a large group of silent subscribers to the wsrp4j lists) Do you have pointers to discussions on our legal lists (Message-Id would do), so that interested people can get more details? As this was mostly done on legal-internal@, only people *really* interested and willing to help out might have/request access to this restricted list (there can be potential legally implicating information so this is not for just casual access). @Bertrand: MessageID: <[EMAIL PROTECTED]> is the starting point of a thread of currently 26 messages started early this year. David Taylor and myself got stuck again on this after a few months, because we are unclear how to proceed and severe lack of time too. It would be great if we can solicit some additional help with this as we definitely would like to resolve this once and for all (no matter the outcome). Both David and myself will be at the ApacheCon so maybe we can setup a meeting then to discuss what can/needs to be done? Regards, Ate -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's up with WSRP4J?
Bertrand Delacretaz wrote: Hi Ate, On Fri, Oct 24, 2008 at 12:29 PM, Ate Douma <[EMAIL PROTECTED]> wrote: Bertrand Delacretaz wrote: ...Does that patent issue mean that an ASF release of the WSRP4J would not be safe from a legal point of view?... Or is it just that users might be afraid of using it? The patent claim (as it stands right now, but: IANAL) seems to require for any usage an *individual* license, e.g. there is no waver (yet) for the ASF to allow release and distribution without putting this burden onto the end users again. In my view, this would not be in compliance with the ASF license and thus a blocker for an ASF endorsed release... Ok, so that looks like the core issue. And if the answer is that a release cannot happen within the ASF, I think the code must move elsewhere. That does not prevent it from coming back later if the issue is resolved. ..Now, end users might or might now be afraid to use it. Its (again in my view, and again: IANAL) questionable to say the least if there would ever be a claim by this one patent holder, but legally it is unclear if/how we can make sure (so nor can the end-users) without having this go to court at least once or get this waver from the acclaimed patent holder Ok. ...Assuming the legal issue can be worked out, would the portals PMC be prepared to "adopt" the WSRP4J code and maintain it in the future? Definitely, and we already did (for as much as possible)! AFAIK The Portal PMC accepted long time ago to do so. This was before I became member though and I haven't be able to find concrete references in the mail archives for this ...But the Portals PMC has taken responsibility for reporting WSRP4J status to the board, the code-base is hosted underneath the portals root folder in svn and the project website is also hosted under portals.apache.org Ok, so the project's status is kind of weird w.r.t the incubator, but I guess we can accept this temporarily based on the legal blocker. ...Note: possibly part of the reason the WSRP4J status reports have not always been delivered is that the separate incubator status reports are not in schedule with the separate Portals status report, and of course that there hasn't been much to report either. But when it was, the *Portals* status reports also included the needed information to the board AFAIK Ok, that clarifies the missing incubator reports. Again, looks like the project and code has been de facto accepted by the portals PMC, without the incubator being really aware of that. Could you maybe add a note to http://incubator.apache.org/projects/wsrp4j.html with a brief summary of the project's status, pointing to this thread? That would help in avoiding repeated inquiries. Will do. ...David Taylor and myself got stuck again on this after a few months, because we are unclear how to proceed and severe lack of time too. It would be great if we can solicit some additional help with this as we definitely would like to resolve this once and for all (no matter the outcome). Both David and myself will be at the ApacheCon so maybe we can setup a meeting then to discuss what can/needs to be done?... IMHO as far as the incubator is concerned, your explanations have clarified the project's status. Ok, glad it helped. I'm not qualified to discuss the legal issue, so I think a meeting only makes sense if ASF people with sufficient legal knowledge can participate - the best might be for you to call for volunteers on the legal and [EMAIL PROTECTED] lists, in a separate thread. Ok. thanks for the follow-ups, -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release Apache AsterixDB Hyracks 0.2.16-incubating (RC3)
On 2015-09-22 20:11, Ian Maxon wrote: First let me just preface by saying this is just how I understand it... If I am wrong anyone please feel free to chime in. There are indeed two votes, one is the vote on dev@asterixdb.a.i.o where the folks we need to vote (the binding votes) are the Podling Project Management Committee (PPMC) members (which is basically all the committers at this point). In this vote that just passed, the binding votes come from Incubator Project Management Committee (IPMC) members, which can be any of our mentors or other interested folks. The latter vote is the one that actually determines whether or not we can release our artifacts and source, the former simply is to establish that there is consensus in the community that it is time for a release. Largely correct, with the additional note that the IPMC +1 votes (like from the mentors) during the first PPMC voting round also account/tally for the second IMPC voting round on general@. So in this case (taking into account that Till voted +1 twice, which technically wasn't necessary) the finally tally of binding +1 votes actually was +5. Ate -Ian On Tue, Sep 22, 2015 at 9:22 AM, Mike Carey wrote: Same Q here - did we need to vote on a different list too? On Sep 22, 2015 8:55 AM, "Chen Li" wrote: Ian, I already did my "+1". Do I have to say "Binding" in order to include it? Still not quite clear about the protocol. Chen On Tue, Sep 22, 2015 at 12:20 AM, Ian Maxon wrote: The vote for releasing Apache AsterixDB Hyracks 0.2.16-incubating passed with 3 binding +1s, 0 non-binding +1s, and no 0 or -1 votes. Binding +1s: Till Westmann Justin Mclean Henry Saputra I've filed a JIRA issue to start addressing the issues Justin mentioned before the next release: https://issues.apache.org/jira/browse/ASTERIXDB-1108 Many thanks to those who voted and helped audit this release! (and stay tuned for the AsterixDB half of the release coming soon...) - Ian On Sat, Sep 19, 2015 at 10:46 PM, Henry Saputra wrote: +1 (binding) On Fri, Sep 18, 2015 at 5:21 PM, Ian Maxon wrote: Hi everyone, Please verify and vote on the first release candidate for the Hyracks components of Apache AsterixDB . This is our first incubating release so feedback would be much appreciated. The vote to release on the development list passed: https://mail-archives.apache.org/mod_mbox/incubator-asterixdb-dev/201509.mbox/%3ccan_yf5xzo8qv_yk-p41m+tppv_y2dynehc_keujwxpem_1l...@mail.gmail.com%3E with result Binding +1s: Murtadha Hubail Till Westmann (IPMC) Yingyi Bu Abdullah Alamoudi Ate Douma (IPMC) Mike Carey Chris A. Mattmann (IPMC) Ian Maxon Non-binding +1s: Heri Ramampiaro And no 0 or -1 votes The tag to be voted on is fullstack-0.2.16-incubating commit :2eb6e71bdf8b3f676717a300d3224e06fb961abc link: https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb-hyracks.git;a=tag;h=refs/tags/fullstack-0.2.16-incubating The artifacts, md5s, and signatures are at: https://dist.apache.org/repos/dist/dev/incubator/asterixdb/fullstack-0.2.16-incubating-source-release.zip https://dist.apache.org/repos/dist/dev/incubator/asterixdb/fullstack-0.2.16-incubating-source-release.zip.asc https://dist.apache.org/repos/dist/dev/incubator/asterixdb/fullstack-0.2.16-incubating-source-release.zip.md5 https://dist.apache.org/repos/dist/dev/incubator/asterixdb/fullstack-0.2.16-incubating-source-release.zip.sha1 MD5: 5c3e7cf34918695f77a812b6434b81f1 SHA1: ca5715e14658a8835399be1d21efbe6aad566daa Additionally, a staged maven repository is available at: https://repository.apache.org/content/repositories/orgapacheasterix-1007/ The KEYS file containing the PGP keys used to sign the release can be found at https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS RAT was executed as part of Maven via the RAT maven plugin, but it excludes the following paths: **/algebricks-tests/src/test/resources/results/** **/javascript/flot/*.js **/javascript/jsplumb/*.js **/javascript/jquery/*.js **/javascript/adminconsole/*.js **/stylesheet/jquery-ui/** **/hyracks-dist/src/main/resources/conf/** **/src/test/resources/data/** **/src/test/resources/results/** **/src/test/resources/expected/** **/testcases/*.piglet **/data/**/*.txt **/data/**/*.tbl **/data/**/*.ddl **/data/**/*.tsv **/actual/conf.xml **/actual/customer_result/part-* **/src/main/resources/conf/* **/data/dfs/** **/invIndex*/** **/*.job **/*.conf **/src/main/resources/*.cleaned **/ClusterControllerService/** **/output/** **/*.iml These files either are either data for tests, procedurally generated, or source files which come without a head
Re: Draft report November 2015 -- please review
On 2015-11-09 18:12, Marvin Humphrey wrote: Incubator PMC report for November 2015 * Ready to graduate - AsterixDB While IMO AsterixDB is doing great, it is not yet considering graduation so I think it shouldn't be listed as such. Ate (AsterixDB mentor) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Draft report November 2015 -- please review
On 2015-11-10 23:59, Marvin Humphrey wrote: On Tue, Nov 10, 2015 at 12:22 PM, Ate Douma wrote: On 2015-11-09 18:12, Marvin Humphrey wrote: Incubator PMC report for November 2015 * Ready to graduate - AsterixDB While IMO AsterixDB is doing great, it is not yet considering graduation so I think it shouldn't be listed as such. Ate (AsterixDB mentor) Thanks for the review, Ate! Podlings tend to progress linearly through 4 stages: 1. Getting started 2. No incubating release 3. Community growth 4. Ready to graduate Although AsterixDB's report did not communicate that they were ready to graduate, they've put out a release and they didn't mention needing to grow the community as a challenge. Here are their "three issues to address prior to graduation": 1. Do an Apache release that can also provide binary artifacts with correct LICENSEs and NOTICEs. 2. 3. Feel free to invent a custom category that describes where AsterixDB is at. Otherwise, "Community growth" is a bit of a catch-all -- so if there's not any other obvious choice we can put them there. Hi Marvin, I see how you got to your assessment and I think from the outside that makes sense :) In this case, their first challenge clearly indicates making a next release with also providing convenience binary artifacts is seen as the next hurdle to take. It is true AsterixDB already put out two releases, but those were source only releases. And the AsterixDB team is well aware that next hurdle isn't going to be so easy. So I would personally place them still at stage 2 for now. Community growth, while not stated in this report (and probably an oversight from us mentors not requesting them to do so) also needs some further development. Although I don't see or expect that to be problematic either, just needs a little bit more time. The community is quite vibrant. At any rate, I think they are in fine shape, just need a bit more time before they should start focusing on graduation, that's all. Regards, Ate Marvin Humphrey - 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
Must name and copyright of bundled (other) ASF artifacts be attributed in NOTICE file?
I'm helping out the AsterixDB podling assembling a first release with bundled binaries, and one of the advises I've given is that: For bundled ASF artifacts you need to merge (at least) their name and copyright year statement, to be compliant with ASL 2.0, section 4.d [1] However Justin (see below) seems to indicate that even this is not needed? The reference to [2] as clarification however doesn't seems to be sufficient. I'd like to know if there is more / clearer clarification available on this. Or if there is not then this should be made explicit, required or not. Thanks, Ate [1] https://mail-archives.apache.org/mod_mbox/incubator-asterixdb-dev/201602.mbox/%3C56B16910.8050702%40douma.nu%3E [2] http://www.apache.org/dev/licensing-howto.html#mod-notice On 2016-02-03 23:04, Justin Mclean wrote: Hi, NOTICE contains copyright, commons-io [2] It’s my understanding that for an ASF produced product with the name, copyright and “this software produced at the ASF” that nothing needs to be added to notice. Thanks, Justin 2. http://www.apache.org/dev/licensing-howto.html#mod-notice - 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: [RESULT][VOTE] Graduate AsterixDB from the Incubator
Just for the record I'd like to add my binding +1 as well Regards, Ate (AsterixDB mentor) On 2016-04-11 06:10, Till Westmann wrote: Hi, the vote is now closed. The vote passes with the following votes: +1 : 5 (all binding) Chris Mattmann Henry Saputra Till Westmann John D. Ament Ted Dunning 0 : 0 -1 : 0 The next step will be the submission of the resolution to the board to be included in the agenda for the next meeting. Thanks for voting, Till On 7 Apr 2016, at 19:49, Till Westmann wrote: Hi, AsterixDB started incubating a little more than a year ago (2015-02-28) [1] and the members of the community think that it is ready to graduate from the incubator to be a TLP. Since starting incubation the community has shipped 2 incubating Apache releases for AsterixDB and Hyracks: - Apache AsterixDB 0.8.7-incubating (2015-10-22) and Hyracks 0.2.16-incubating (2015-09-22) - Apache AsterixDB 0.8.8-incubating (2016-02-26) and Hyracks 0.2.17-incubating (2016-02-26) The AsterixDB community today is open and very active and distributed over several continents. It has also grown during incubation and Chris Hillery (2015-10-20), Heri Ramampiaro (2016-01-16), and Michael Blow (2016-03-28) have been added as committers and PPMC members AsterixDB's community passed a supporting vote with 26 +1 votes (3 of those were from the podling's mentors Chris Mattmann, Henry Saputra, and Ate Douma) and no 0 or -1 votes [2]. The proposed board resolution is attached. Please vote if the Apache Incubator PMC should recommend the creation of the Apache AsterixDB project to the Board. [ ] +1 Recommend the creation of the Apache AsterixDB project. [ ] 0 Don't care. [ ] -1 The Apache AsterixDB podling is not ready to graduate because ... Thanks for your VOTE, Till (on behalf of the Apache AsterixDB PPMC). [1] http://incubator.apache.org/projects/asterixdb.html [2] https://s.apache.org/asterixdb-graduation-vote-result -- The proposed board resolution: Establish the Apache AsterixDB Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to parallel distributed data management technologies for semi-structured data, NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache AsterixDB Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache AsterixDB Project be and hereby is responsible for the creation and maintenance of software related to parallel distributed data management technologies for semi-structured data; and be it further RESOLVED, that the office of "Vice President, Apache AsterixDB" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache AsterixDB Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache AsterixDB Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache AsterixDB Project: * Abdullah Alamoudi * Ate Douma * Cameron Samak * Chen Li * Chris Hillery * Chris Mattmann * Heri Ramampiaro * Ian Maxon * Ildar Absalyamov * Jianfeng Jia * Jochen Wiedmann * Keren Ouaknine * Michael Blow * Mike Carey * Murtadha Hubail * Pouria Pirzadeh * Preston Carman * Raman Grover * Sattam Alsubaiee * Steven Jacobs * Taewoo Kim * Ted Dunning * Till Westmann * Vassilis Tsotras * Vinayak Borkar * Yingyi Bu * Young-Seok Kim * Zach Heilbron NOW, THEREFORE, BE IT FURTHER RESOLVED, that Till Westmann be appointed to the office of Vice President, Apache AsterixDB, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache AsterixDB PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache AsterixDB Project; and be it further RESOLVED, that the Apache AsterixDB Project be and hereby is tasked with the migration and rationalization of the Apache Incubator AsterixDB podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator AsterixDB podling encumbered upon the Apache Incubator Project are hereafter discharged. --
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-14 17:14, David Nalley wrote: On Wed, Sep 14, 2016 at 9:10 AM, Bertrand Delacretaz wrote: Hi, On Wed, Sep 14, 2016 at 2:57 PM, Geertjan Wielenga wrote: ...there is no code on plugins.netbeans.org at all. No one can donate any code from anywhere on plugins.netbeans.org to anyone else. It simply contains binaries... Thanks for the clarification. This confirms my view, I don't think we should make hosting plugins.netbeans.org part of the incubation plan. That hosting might happen later, separately, but it's IMO not a condition for a successful move of NetBeans to Apache and much better discussed separately, once the project starts. -Bertrand While it may not be a requirement to enter incubation, I do want us to understand plugins.netbeans.org (and any other pieces of their infrastructure) I admit it's been some years since I have used Netbeans in anger, but plugins are (or were) pretty important to the user community. I don't want us to defer the discussion for it to come back some years down the road, especially for something that I perceive is important for the user community. I just created an account on netbeans.org to get an understanding what plugins.netbeans.org 'portal' provides. AFAICT it provides 4 main features, see [1] and [2]: - register a plugin 'advertisement', meaning plugin documentation is provided through the plugins portal, which can include a link where users can find and download the plugin elsewhere. (note: I couldn't find an example nor can you specifically query on this) - register *and* upload a plugin which then can be downloaded from the plugin portal itself - "Plugin Update Center" service through which plugins hosted by the portal which also are verified against some criteria, are accessible and downloadable from within Netbeans itself. - a backend database / CMS to store and manage above metadata, as well as a frontend web application for managing and accessing this. Now, considering the above features the following idea is just a 'thinking out loud' brain fart for a possible solution which might make it feasible to host a Netbeans plugin portal by Apache itself, if: - It can/will use/support external hosting of 3rd party plugins (binaries). For example as Maven artifact at Maven Central. But Netbeans project provided/verified plugins could be hosted at Apache. - It just stores and provides editing capability for the meta-data concerning the plugins. This might even be stored 'statically', e.g. as plain text or json, or whatever, and even in a SCM if so desired. - It provides a specialized 'CMS' to allow (registered) end-users to add and maintain their own plugin documentation. Again, this content might be stored and served 'statically', kind of similar as we do for the Apache CMS. - It probably needs to support a separate 'end user' database and account management, maybe similar to what we use for MoinMoin today (file based)? - Finally, the "Plugin Update Center" likewise could be a lightweight 'service' just querying the already statically made available meta-data. It would be a major benefit if something like this can make it feasible to host (only) the portal and its meta-data at Apache, thereby ensuring control and oversight by the Netbeans project itself. That way there is no need to 'license' the Netbeans plugins management to a third party and have them administer it, like in the case of Maven Central as David explained below. Of course, externally hosted plugin binaries still remain external. But verified Apache compliant plugins could be hosted at Apache itself. As well as clearly marked in the plugin portal as such, further strengthening the project and community binding at Apache. Ate [1] http://wiki.netbeans.org/FaqPluginAdd [2] http://wiki.netbeans.org/FaqPluginUpdateCenter I think this is similar to Maven Central - yes, we license maven central to a third party and they administer the service. However, if the time comes that either Sonatype or the PMC kill that off, Maven Central can't just 'go away' - either a second third-party would have to come in, or the ASF will have to bear the responsibility. So even if someone else is licensed the ability to run plugins.netbeans.org - we need to understand the responsibilities, as it may come home to roost.[1] --David [1] http://idioms.thefreedictionary.com/come+home+to+roost - My apologies for the idiom. - 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: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-14 21:43, Ate Douma wrote: On 2016-09-14 17:14, David Nalley wrote: On Wed, Sep 14, 2016 at 9:10 AM, Bertrand Delacretaz wrote: Hi, On Wed, Sep 14, 2016 at 2:57 PM, Geertjan Wielenga wrote: ...there is no code on plugins.netbeans.org at all. No one can donate any code from anywhere on plugins.netbeans.org to anyone else. It simply contains binaries... Thanks for the clarification. This confirms my view, I don't think we should make hosting plugins.netbeans.org part of the incubation plan. That hosting might happen later, separately, but it's IMO not a condition for a successful move of NetBeans to Apache and much better discussed separately, once the project starts. -Bertrand While it may not be a requirement to enter incubation, I do want us to understand plugins.netbeans.org (and any other pieces of their infrastructure) I admit it's been some years since I have used Netbeans in anger, but plugins are (or were) pretty important to the user community. I don't want us to defer the discussion for it to come back some years down the road, especially for something that I perceive is important for the user community. I just created an account on netbeans.org to get an understanding what plugins.netbeans.org 'portal' provides. AFAICT it provides 4 main features, see [1] and [2]: - register a plugin 'advertisement', meaning plugin documentation is provided through the plugins portal, which can include a link where users can find and download the plugin elsewhere. (note: I couldn't find an example nor can you specifically query on this) - register *and* upload a plugin which then can be downloaded from the plugin portal itself - "Plugin Update Center" service through which plugins hosted by the portal which also are verified against some criteria, are accessible and downloadable from within Netbeans itself. - a backend database / CMS to store and manage above metadata, as well as a frontend web application for managing and accessing this. Now, considering the above features the following idea is just a 'thinking out loud' brain fart for a possible solution which might make it feasible to host a Netbeans plugin portal by Apache itself, if: - It can/will use/support external hosting of 3rd party plugins (binaries). For example as Maven artifact at Maven Central. But Netbeans project provided/verified plugins could be hosted at Apache. - It just stores and provides editing capability for the meta-data concerning the plugins. This might even be stored 'statically', e.g. as plain text or json, or whatever, and even in a SCM if so desired. - It provides a specialized 'CMS' to allow (registered) end-users to add and maintain their own plugin documentation. Again, this content might be stored and served 'statically', kind of similar as we do for the Apache CMS. - It probably needs to support a separate 'end user' database and account management, maybe similar to what we use for MoinMoin today (file based)? - Finally, the "Plugin Update Center" likewise could be a lightweight 'service' just querying the already statically made available meta-data. It would be a major benefit if something like this can make it feasible to host (only) the portal and its meta-data at Apache, thereby ensuring control and oversight by the Netbeans project itself. That way there is no need to 'license' the Netbeans plugins management to a third party and have them administer it, like in the case of Maven Central as David explained below. Of course, externally hosted plugin binaries still remain external. But verified Apache compliant plugins could be hosted at Apache itself. As well as clearly marked in the plugin portal as such, further strengthening the project and community binding at Apache. BTW: the above is just a wild idea for also bringing plugins.netbeans.org to Apache somewhere in the future. I also do agree with Bertrand we should not make this part of the incubation plan, or at least not as a condition for the move of Netbeans to Apache. Ate [1] http://wiki.netbeans.org/FaqPluginAdd [2] http://wiki.netbeans.org/FaqPluginUpdateCenter I think this is similar to Maven Central - yes, we license maven central to a third party and they administer the service. However, if the time comes that either Sonatype or the PMC kill that off, Maven Central can't just 'go away' - either a second third-party would have to come in, or the ASF will have to bear the responsibility. So even if someone else is licensed the ability to run plugins.netbeans.org - we need to understand the responsibilities, as it may come home to roost.[1] --David [1] http://idioms.thefreedictionary.com/come+home+to+roost - My apologies for the idiom. ---
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-14 21:49, Geertjan Wielenga wrote: I can't wait for that to happen! In the meantime, can we call NetBeans by its real name: NetBeans, with an uppercase N and an uppercase B? Shall we all start maintaining that, i.e., using the correct name, which is NetBeans or, better yet, Apache NetBeans? Sorry, guilty as charged. And as a proposed mentor: double penalty :-) I'll try to do better in the future! Yes, Oracle is handing over everything in terms of trademarks to Apache, let's put aside that discussion since it's true, if you can point in the proposal where this is not clear or can be clearer, tell me and we will change/add/whatever. FYI -- no one creating independent products based on Apache NetBeans cares what its name is. Only two things are in discussion right now: (1) licensing [which has been discussed quite a bit with Apache folks like Bertrand and Ate prior to the proposal being published and we are comfortable we'll be able to solve everything] and (2) infrastructure migration [which has been outlined already, though we are working on a lot more details at the moment so that everything will be crystal clear]. Cool! I think the proposal looks great and so far I see no issues to be considered blocking for entering the Incubator. Regards, Ate Thanks, Geertjan On Wed, Sep 14, 2016 at 8:40 PM, Roman Shaposhnik wrote: On Wed, Sep 14, 2016 at 11:34 AM, Wade Chandler wrote: Do you mean from the stand point of it being a Java based application, or that some how NetBeans and the Java TCK are related? I don’t think either is an impact on NetBeans IMHO; not any more than it is for the Eclipse IDE or IntelliJ. Do you mean because it is being contributed by Oracle perhaps? If so, does the donor have as much impact on contributions as that once adopted by Apache? I may be misunderstanding what you are asking. I am not an employee of Oracle; just an NB contributor. I think the question is more along the lines of what else would be required to produce a "canonical" release of Apache Netbeans. If everything that is required is being donated -- I think we're good. IOW, the project must be self-contained and not depend on anything still left behind the firewall to do on-going development and most important releases. E.g. if I send you a patch -- you can't reject it on the grounds that some test behind Oracle's frewall I've never seen failed. Stuff like that. On a related note, I haven't seen it explicitly mentioned in the proposal, but I hope you guys do realize that once this project is accepted the Netbeans brand belongs to Apache. IOW, if Oracle or anybody else ever want to have an independent product based on Apache Netbeans they will have to call it something else. Thanks, Roman. - 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: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-15 14:15, Bertrand Delacretaz wrote: Hi Incubator PMC, On Tue, Sep 13, 2016 at 9:40 AM, Geertjan Wielenga wrote: ... https://wiki.apache.org/incubator/NetBeansProposal ... At this point I ask anyone with concerns or questions that haven't been addressed so far and would prevent us from voting on this proposal to chime in. Based on the discussions in this thread we have added Mark Struberg and Jim Jagielski to the proposal as mentors. Daniel Gruno mentioned the need for someone from ASF infra as a mentor, if needed it's easy to add a mentor later, or Daniel just confirm if you want to join. Emmanuel Lécharny was unsure and hasn't confirmed AFAICS, he can also be removed from the list later on easily if he wants to leave, that's no big deal. I have changed the SIR03 special infrastructure requirement (migration of plugins.netbeans.org) to exclude it from the incubation process as discussed here - we have envisioned possible solutions and realized that incubating NetBeans is not necessarily dependent on that, and I think the project can address this in due time. One potential caveat is that plugins.netbeans.org, which is currently hosted by Oracle, will have to remain active as is, at least for the time being. But the transfer of the netbeans.org domain to the ASF also is part of the proposal. So, how will that work, and can (and will) Oracle remain hosting and managing it while the domain ownership has moved to Apache? Or maybe the domain transfer needs to be postponed, for this one reason? Furthermore, AFAICT all of the netbeans.org portal is hosted/running on Kenai. And Kenai is slated to be shutdown by Oracle next year April. So one way or the other, we (Apache, NetBeans project) will need to think of how to play this out. Are there other things to discuss that might affect our vote on accepting NetBeans? I'm planning to start the vote in about 24 hours unless things still need to be discussed. -Bertrand - 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
Fwd: [VOTE] Retire Apache Streams to the attic
FYI, I've started below vote to retire Apache Streams, after I first initiated a [discuss] thread more than a week ago, which resulted in zero feedback. Ate (Streams mentor) Forwarded Message Subject: [VOTE] Retire Apache Streams to the attic Date: Sun, 18 Sep 2016 23:27:11 +0200 From: Ate Douma To: d...@streams.incubator.apache.org As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://attic.apache.org/process.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Apache Streams to the attic
On 2016-09-19 15:44, John D. Ament wrote: Ate, Please also note the instructions from the incubator's retirement guide. http://incubator.apache.org/guides/retirement.html Right. Thanks for pointing this out John. I've never before had to handle a podling retirement and overlooked this requires different handling from a TLP retirement. And with slightly different consequences, e.g. website will be taken down, instead of flagged as being retired. So, to do this proper, I'll first cancel the vote thread on dev@streams and open a new [FINAL][DISCUSS] thread for retirement again, this time also pointing to the podling retirement page. This way at least everyone on that list will have a proper notice what the retirement entails. (not that I expect a different outcome, but there is no rush either) And after that I'll open the final [VOTE] for retirement here on general@ Ate John On Mon, Sep 19, 2016 at 6:37 AM Ate Douma wrote: FYI, I've started below vote to retire Apache Streams, after I first initiated a [discuss] thread more than a week ago, which resulted in zero feedback. Ate (Streams mentor) Forwarded Message Subject: [VOTE] Retire Apache Streams to the attic Date: Sun, 18 Sep 2016 23:27:11 +0200 From: Ate Douma To: d...@streams.incubator.apache.org As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://attic.apache.org/process.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate - 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] Retire Apache Streams to the attic
On 2016-09-19 16:33, Ate Douma wrote: On 2016-09-19 15:44, John D. Ament wrote: Ate, Please also note the instructions from the incubator's retirement guide. http://incubator.apache.org/guides/retirement.html Right. Thanks for pointing this out John. I've never before had to handle a podling retirement and overlooked this requires different handling from a TLP retirement. And with slightly different consequences, e.g. website will be taken down, instead of flagged as being retired. So, to do this proper, I'll first cancel the vote thread on dev@streams and open a new [FINAL][DISCUSS] thread for retirement again, this time also pointing to the podling retirement page. This way at least everyone on that list will have a proper notice what the retirement entails. (not that I expect a different outcome, but there is no rush either) Reading the podling retirement guide a bit more thoroughly, I think I it is sufficient to restart the [VOTE] thread for retirement on dev@streams with the link to the podling retirement guide. And after that I'll open the final [VOTE] for retirement here on general@ Ate John On Mon, Sep 19, 2016 at 6:37 AM Ate Douma wrote: FYI, I've started below vote to retire Apache Streams, after I first initiated a [discuss] thread more than a week ago, which resulted in zero feedback. Ate (Streams mentor) Forwarded Message Subject: [VOTE] Retire Apache Streams to the attic Date: Sun, 18 Sep 2016 23:27:11 +0200 From: Ate Douma To: d...@streams.incubator.apache.org As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://attic.apache.org/process.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate - 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] Retire Apache Streams to the attic
On 2016-09-19 17:09, Suneel Marthi wrote: I am sorry to be reading this, but I was at Steve Blackmon's talk last week in Berlin at Flink forward about using Streams + Flink. It was a very interesting talk and I chatted with Steve briefly about the Streams project. Good to hear that! I wasn't aware Steve was presenting about Streams in Berlin. Is there absolutely no chance of reviving this project or giving the project some more time before calling the attic ? Sure there is a chance, but for that the project needs active community involvement. Which has been lacking for quite a while now. Community building and involvement really is the primary problem for the project with only a single active member, which is not sustainable. However, if you are willing and able to get actively involved, and rally some additional community involvement as well, then I'd be happy to postpone/cancel the retirement VOTE for now. I suggest to head over to d...@streams.incubator.apache.org, let us know what you can and will do for the project, and see how that works out. Regards, Ate On Mon, Sep 19, 2016 at 4:58 PM, Ate Douma wrote: On 2016-09-19 16:33, Ate Douma wrote: On 2016-09-19 15:44, John D. Ament wrote: Ate, Please also note the instructions from the incubator's retirement guide. http://incubator.apache.org/guides/retirement.html Right. Thanks for pointing this out John. I've never before had to handle a podling retirement and overlooked this requires different handling from a TLP retirement. And with slightly different consequences, e.g. website will be taken down, instead of flagged as being retired. So, to do this proper, I'll first cancel the vote thread on dev@streams and open a new [FINAL][DISCUSS] thread for retirement again, this time also pointing to the podling retirement page. This way at least everyone on that list will have a proper notice what the retirement entails. (not that I expect a different outcome, but there is no rush either) Reading the podling retirement guide a bit more thoroughly, I think I it is sufficient to restart the [VOTE] thread for retirement on dev@streams with the link to the podling retirement guide. And after that I'll open the final [VOTE] for retirement here on general@ Ate John On Mon, Sep 19, 2016 at 6:37 AM Ate Douma wrote: FYI, I've started below vote to retire Apache Streams, after I first initiated a [discuss] thread more than a week ago, which resulted in zero feedback. Ate (Streams mentor) Forwarded Message Subject: [VOTE] Retire Apache Streams to the attic Date: Sun, 18 Sep 2016 23:27:11 +0200 From: Ate Douma To: d...@streams.incubator.apache.org As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://attic.apache.org/process.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate - 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] Retire Apache Streams to the attic
On 2016-09-21 18:28, apache wrote: I remain committed to building and sharing open-source software for social web data interoperability. Participating in the incubator process has taught me a lot, and I would like the keep the project operating at Apache, but as Ate points out the community around this podling has never been healthy and has all but disappeared in 2016. I would very much welcome anyone interested in this problem to volunteer as a mentor or contributor. With even a few new committed active participants I can envision the project graduating to TLP. Without fresh initiative, it should be retired. Perhaps some of the codebase will be useful elsewhere. Hi Steve, Although the retirement for Apache Streams hasn't been formally decided, as there hasn't been any further signal for support or initiative, it does look like we'll have to draw that conclusion soon. You really tried your best in making Apache Streams a success, and with the openness and focus fitting for the Apache Software Foundation. That it didn't work out as anticipated and hoped for is of course disappointing, but sometimes that's just the way things goes. I definitely hope you will stick to it and at the ASF, contributing to and joining other projects because you clearly demonstrated to be an fine Apache committer. And not just because you are a nice and really smart guy, but also as a great advocate of the Apache Way, at ApacheCons and other places! I’ll be submitting a (potentially final) release candidate later today. I'll take a look and review the release candidate over the weekend, which if OK and when receiving +3 from the IPMC, indeed might become a final incubating release for Apache Stream. I'll follow up later on the VOTE thread for the release candidate on d...@streams.incubator.apache.org Kind regards, Ate Steve Blackmon sblack...@apache.org On September 19, 2016 at 10:25:16 AM, Ate Douma (a...@douma.nu <mailto:a...@douma.nu>) wrote: On 2016-09-19 17:09, Suneel Marthi wrote: > I am sorry to be reading this, but I was at Steve Blackmon's talk last week > in Berlin at Flink forward about using Streams + Flink. > > It was a very interesting talk and I chatted with Steve briefly about the > Streams project. Good to hear that! I wasn't aware Steve was presenting about Streams in Berlin. > > Is there absolutely no chance of reviving this project or giving the > project some more time before calling the attic ? Sure there is a chance, but for that the project needs active community involvement. Which has been lacking for quite a while now. Community building and involvement really is the primary problem for the project with only a single active member, which is not sustainable. However, if you are willing and able to get actively involved, and rally some additional community involvement as well, then I'd be happy to postpone/cancel the retirement VOTE for now. I suggest to head over to d...@streams.incubator.apache.org, let us know what you can and will do for the project, and see how that works out. Regards, Ate > > > > > On Mon, Sep 19, 2016 at 4:58 PM, Ate Douma wrote: > >> On 2016-09-19 16:33, Ate Douma wrote: >> >>> On 2016-09-19 15:44, John D. Ament wrote: >>> >>>> Ate, >>>> >>>> Please also note the instructions from the incubator's retirement guide. >>>> >>>> http://incubator.apache.org/guides/retirement.html >>>> >>> >>> Right. >>> Thanks for pointing this out John. >>> >>> I've never before had to handle a podling retirement and overlooked this >>> requires different handling from a TLP retirement. >>> And with slightly different consequences, e.g. website will be taken down, >>> instead of flagged as being retired. >>> >>> So, to do this proper, I'll first cancel the vote thread on dev@streams >>> and open a new [FINAL][DISCUSS] thread for retirement again, this >>> time also pointing to the podling retirement page. >>> This way at least everyone on that list will have a proper notice what >>> the retirement entails. >>> (not that I expect a different outcome, but there is no rush either) >>> >> >> Reading the podling retirement guide a bit more thoroughly, I think I it is >> sufficient to restart the [VOTE] thread for retirement on dev@streams >> with the >> link to the podling retirement guide. >> >> >> >>> And after that I'll open the final [VOTE] for retirement here on general@ >>> >>> Ate >>> >>> >>>> John >>>> >>>> On Mon, Sep 19, 2016 at 6:37 AM Ate Douma wrote: >>>>
Re: [VOTE] Retire Apache Streams to the attic
Hi Benjamin, Thanks for chiming in, and not a bit too late :-) I think it would be great if the ActivityStreams 2.0 group and Apache Streams can work together and with the help of the W3C group might help 'reset' the project and move forwards again. I am really happy to cancel the vote for retirement in light of this potential new effort. I will do so shortly (on the d...@streams.incubator.apache.org list). And I invite you, and others interested from the W3C group to join the dev list as well to make contact and further discuss possible next steps. "pointing all W3C arrows this direction" already is a great way to start :-) Kind regards, Ate On 2016-09-23 17:45, Benjamin Young wrote: I am currently sitting in the W3C’s Social Web Working Group’s face-to-face meeting and have just finished discussing features of ActivityStreams 2.0: https://www.w3.org/TR/activitystreams-core/ The Social Web WG is nearing the end of it’s charter, and preparing to ship the AS2.0 spec—which could be an opportunity for the Apache Streams community to get back on its feet. Had I known this group was in danger of shut-down, I would have done more this week (at the W3C’s big face-to-face meeting: TPAC). I even gave a presentation on getting W3C folks involved in ASF projects and vice versa. There is great opportunity yet untapped for combining W3C and ASF activities, and I’d hate to see this project disappear before such a major moment in the chronology of ActivityStreams 2.0. To that end, I’d like to know how I might help “jump start” the Apache Streams (incubating) project and will certainly be pointing all W3C arrows this direction. So: Please don’t close this group before more cross engagement with the Social Web WG and the ActivityStreams 2.0 community has happened. Thanks! Benjamin -- http://bigbluehat.com/ http://linkedin.com/in/benjaminyoung *From: *apache <mailto:sblack...@apache.org> *Sent: *Friday, September 23, 2016 4:15 PM *To: *Ate Douma <mailto:a...@douma.nu>; d...@streams.incubator.apache.org <mailto:d...@streams.incubator.apache.org> *Cc: *general@incubator.apache.org <mailto:general@incubator.apache.org> *Subject: *Re: [VOTE] Retire Apache Streams to the attic On September 22, 2016 at 5:05:39 PM, Ate Douma (a...@douma.nu) wrote: On 2016-09-21 18:28, apache wrote: I remain committed to building and sharing open-source software for social web data interoperability. Participating in the incubator process has taught me a lot, and I would like the keep the project operating at Apache, but as Ate points out the community around this podling has never been healthy and has all but disappeared in 2016. I would very much welcome anyone interested in this problem to volunteer as a mentor or contributor. With even a few new committed active participants I can envision the project graduating to TLP. Without fresh initiative, it should be retired. Perhaps some of the codebase will be useful elsewhere. Hi Steve, Although the retirement for Apache Streams hasn't been formally decided, as there hasn't been any further signal for support or initiative, it does look like we'll have to draw that conclusion soon. You really tried your best in making Apache Streams a success, and with the openness and focus fitting for the Apache Software Foundation. That it didn't work out as anticipated and hoped for is of course disappointing, but sometimes that's just the way things goes. Thanks for saying so. There has been a lot of good work from the committers involved but not all efforts ultimately succeed. I definitely hope you will stick to it and at the ASF, contributing to and joining other projects because you clearly demonstrated to be an fine Apache committer. And not just because you are a nice and really smart guy, but also as a great advocate of the Apache Way, at ApacheCons and other places! Thanks for saying so. I’m not going anywhere. #bigdata is what I do and ASF is where it happens. I’ll be submitting a (potentially final) release candidate later today. I'll take a look and review the release candidate over the weekend, which if OK and when receiving +3 from the IPMC, indeed might become a final incubating release for Apache Stream. Thanks. I'll follow up later on the VOTE thread for the release candidate on d...@streams.incubator.apache.org Kind regards, Ate Steve Blackmon sblack...@apache.org On September 19, 2016 at 10:25:16 AM, Ate Douma (a...@douma.nu <mailto:a...@douma.nu>) wrote: On 2016-09-19 17:09, Suneel Marthi wrote: > I am sorry to be reading this, but I was at Steve Blackmon's talk last week > in Berlin at Flink forward about using Streams + Flink. > > It was a very interesting talk and I chatted with Steve briefly about the > Streams project. Good to hear that! I wasn't aware Steve was presenting about Streams in Berlin. > > Is
[CANCELLED][VOTE] Retire Apache Streams to the attic
In light of the positive feedback and input from Benjamin Young from W3C and Suneel Marthi which hopefully will lead to a renewal of activity and a move forwards for Apache Streams, I'm hereby cancelling this vote for retirement. I'm looking forward to the next steps! Kind regards, Ate On 2016-09-19 17:07, Ate Douma wrote: As was pointed out to me by the John Arment on general@, the process for retiring a podling is a bit more elaborate, and with different consequences compared to a TLP retirement (see incubator retierement guide link below). The most notable difference is that the podling website, in this case http://streams.apache.org, will be taken down as well. To make sure everyone has taken note, I'm hereby restarting the vote: As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://incubator.apache.org/guides/retirement.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate On 2016-09-18 23:27, Ate Douma wrote: As a final follow up on the earlier [discuss] thread, lets formally vote on retiring Apache Streams and move it to the attic. The process is described at http://attic.apache.org/process.html [ ] +1 Move Streams to the Attic [ ] ±0 Proceed according to the majority [ ] -1 Do not move Streams to the Attic, because... [please add justification] Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-25 05:22, Geertjan Wielenga wrote: It really is impossible for us to follow all the (in many cases contradictory) advice we have been given re the initial contributors list. Hi GeertJan, I've gone through this whole thread again and IMO there really isn't so much contradictory advice :-) The general advice really is, including from the NetBeans Champion and other mentors to not blow up the initial contributor list before the acceptance of the project. The argument Roman Shaposhnik brought forward about a past case where he had to deal with a single individual who felt left out, IMO is/was just a single case. Relevant for sure, but AFAIK also very uncommon and more like a one-off case. The other, and very valid, point brought from Roman was that it should be made very clear what criteria was used to select the initial committer list. Further down I'll provide *my view* on what that criteria is or should be. But I'll start with disagreeing with the second part of his point, that (quote): "IT MUST BE THE SAME for when somebody comes-a-knocking". Disagreeing with this might seems odd and at odds with how the ASF works, but I think it does not, or at least, it will not. For a project as large and with such a huge history as NetBeans, there is no way we (ASF) will be able to *judge* who is rightfully put on that list, nor who has been left out erroneously. Meaning: a 'complete' initial committer list (for such a project) never can be put together proper. Trying to do so, like by going through all the history and enumerating all past contributors, IMO is a bad idea and will make things worse and more unclear, even more 'unfair'. And such a list will most certainly NOT be proper from an ASF POV, in the sense that we strive for a healthy and active committers and (P)PPMC list of people seriously engaged NOW. Project members who actually "do" stuff (doers decide). Past contributors who do want to re-engage again most certainly need to be valued and be admitted to become committer, but IMO better do this *when* they come knocking (actively) than enlisting them upfront. Having to 'prune' a huge, and likely too huge, list of initial committers before NetBeans graduates to TLP is going to be far more 'painful' than voting in active contributors when they actively show up. Which also is far more in line with "the Apache Way", more 'fair' so to say. Coming back to the maybe odd POV that the selection criteria for initial commmitters list does not have to be the same as that for future committers. IMO it simply cannot be 'equal' for a project like NetBeans. The primary role and responsibility for such initial committers is to get the project rolling and admit new committers base on *their* judgement. So the most important, and IMO only crucial, criteria for selecting the initial committers list is that those people are trusted to "do this right". They can and will vote in new committers as soon as they come knocking, based on their past contribution *and* their (intended) active participation. Based on merit for the *new* Apache NetBeans project, not (just) their past contributions, no matter how small/large that might have been. And for that reason, an initial committers list must be fairly sized, with enough diversity, spread out interest, and with recognition and be trusted by the NetBeans community. And then: stop there. The initially proposed committers list IMO already was 'good enough' for this purpose. And AFAICT nobody questioned the list to be unfair or not 'good enough'. Of course adding one or two extra who were overlooked and are expected to help make a difference and speed up the process still is fine. So my strong advise is to stick to the original list. And to first discuss it with the Bertrand as Champion and the other mentors before modifying the proposal further. Kind regards, Ate Here's what I propose: 1. We make the initial contributors list as detailed as we can, i.e., I have already started doing this, grouping individual contributors in specific categories and also indicating which ones have contributed in the past, in most cases the recent past, i.e., these are the ones with most direct skills who are likely to begin contributing as soon as possible. Yes, most of these are from Oracle, which makes sense since we're moving to Apache precisely in order to open up the governance model so that more can participate. 2. When in doubt, we will follow the advice of our mentors over the advice of those who are not our mentors. 3. We will show in the initial contributors list what each of the initial contributors is planning to contribute, as concretely as possible, to show that we have a list of contributors who really want to and are planning to contribute as soon as they're able to do so. 4. I don't believ
Re: Request to join Apache Streams (Incubating) as Mentor
I'm happy to add and have Suneel join me as mentor for Apache Streams. I can't find anything about this: Is there any formal process or voting needed before I make this so? Ate On 2016-09-23 19:51, Suneel Marthi wrote: - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-25 12:15, Ate Douma wrote: On 2016-09-25 05:22, Geertjan Wielenga wrote: It really is impossible for us to follow all the (in many cases contradictory) advice we have been given re the initial contributors list. Hi GeertJan, I've gone through this whole thread again and IMO there really isn't so much contradictory advice :-) The general advice really is, including from the NetBeans Champion and other mentors to not blow up the initial contributor list before the acceptance of the project. The argument Roman Shaposhnik brought forward about a past case where he had to deal with a single individual who felt left out, IMO is/was just a single case. Relevant for sure, but AFAIK also very uncommon and more like a one-off case. The other, and very valid, point brought from Roman was that it should be made very clear what criteria was used to select the initial committer list. Further down I'll provide *my view* on what that criteria is or should be. But I'll start with disagreeing with the second part of his point, that (quote): "IT MUST BE THE SAME for when somebody comes-a-knocking". Disagreeing with this might seems odd and at odds with how the ASF works, but I think it does not, or at least, it will not. For a project as large and with such a huge history as NetBeans, there is no way we (ASF) will be able to *judge* who is rightfully put on that list, nor who has been left out erroneously. Meaning: a 'complete' initial committer list (for such a project) never can be put together proper. Trying to do so, like by going through all the history and enumerating all past contributors, IMO is a bad idea and will make things worse and more unclear, even more 'unfair'. And such a list will most certainly NOT be proper from an ASF POV, in the sense that we strive for a healthy and active committers and (P)PPMC list of people seriously engaged NOW. Project members who actually "do" stuff (doers decide). Past contributors who do want to re-engage again most certainly need to be valued and be admitted to become committer, but IMO better do this *when* they come knocking (actively) than enlisting them upfront. Having to 'prune' a huge, and likely too huge, list of initial committers before NetBeans graduates to TLP is going to be far more 'painful' than voting in active contributors when they actively show up. Which also is far more in line with "the Apache Way", more 'fair' so to say. Coming back to the maybe odd POV that the selection criteria for initial commmitters list does not have to be the same as that for future committers. IMO it simply cannot be 'equal' for a project like NetBeans. The primary role and responsibility for such initial committers is to get the project rolling and admit new committers base on *their* judgement. So the most important, and IMO only crucial, criteria for selecting the initial committers list is that those people are trusted to "do this right". And important for the community to realise: the IPMC and the assigned mentors are there to help them to do this right! They can and will vote in new committers as soon as they come knocking, based on their past contribution *and* their (intended) active participation. Based on merit for the *new* Apache NetBeans project, not (just) their past contributions, no matter how small/large that might have been. And for that reason, an initial committers list must be fairly sized, with enough diversity, spread out interest, and with recognition and be trusted by the NetBeans community. And then: stop there. The initially proposed committers list IMO already was 'good enough' for this purpose. And AFAICT nobody questioned the list to be unfair or not 'good enough'. Of course adding one or two extra who were overlooked and are expected to help make a difference and speed up the process still is fine. So my strong advise is to stick to the original list. And to first discuss it with the Bertrand as Champion and the other mentors before modifying the proposal further. Just to make sure: I'm not objecting against the proposal changes you made so far to further clarify initial committers affiliations. But (bold) marking people out who have provided code contribution in the past IMO isn't and shouldn't be seen as a single or even most important criteria. As mentioned before all forms of participation and contributions are valued within the ASF, and not all committers are required to commit :-) Ate Kind regards, Ate Here's what I propose: 1. We make the initial contributors list as detailed as we can, i.e., I have already started doing this, grouping individual contributors in specific categories and also indicating which ones have contributed in the past, in most cases the recent past, i.e., these are the ones with most direct skills who are likely
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On 2016-09-25 17:20, Geertjan Wielenga wrote: On Sun, Sep 25, 2016 at 1:03 PM, Ate Douma wrote: and not all committers are required to commit :-) That is interesting. Can you explain more about that? What I meant to say is that at the ASF we also value and honour merit based on things other than just churning code. So committers can be, and are, voted in because of other contributions like help organizing events, helping other community members, contributing to documentation, etc., in general supporting the project and community at large. Technically, an ASF account and membership of a project requires the 'commit' bit, hence be a committer. But I do know committers who never committed anything significantly, even have become ASF member without needing to. And that is perfectly fine. So my point was and is: not everyone on the initial committer list for NetBeans, nor in the future, should be required to have actually contributed code to be recognized and trusted by the community, or to become a committer in the future. Also, we have done a call for people who want to be added to the initial contributors list and will be adding a few more -- these are all well known and established people in the NetBeans community who it would make sense to include right away, rather than having to vote them in later. Sure, that is of course a good thing to do. I just wanted to make sure nobody misunderstands the purpose of the list. And that not being on that list says nothing about who will or will not be able to join afterwards. It looks to me we are ready for voting on this proposal, as soon as the infra assessment and discussion around it has been settled as well. Regards, Ate Thanks, Geertjan On Sun, Sep 25, 2016 at 1:03 PM, Ate Douma wrote: On 2016-09-25 12:15, Ate Douma wrote: On 2016-09-25 05:22, Geertjan Wielenga wrote: It really is impossible for us to follow all the (in many cases contradictory) advice we have been given re the initial contributors list. Hi GeertJan, I've gone through this whole thread again and IMO there really isn't so much contradictory advice :-) The general advice really is, including from the NetBeans Champion and other mentors to not blow up the initial contributor list before the acceptance of the project. The argument Roman Shaposhnik brought forward about a past case where he had to deal with a single individual who felt left out, IMO is/was just a single case. Relevant for sure, but AFAIK also very uncommon and more like a one-off case. The other, and very valid, point brought from Roman was that it should be made very clear what criteria was used to select the initial committer list. Further down I'll provide *my view* on what that criteria is or should be. But I'll start with disagreeing with the second part of his point, that (quote): "IT MUST BE THE SAME for when somebody comes-a-knocking". Disagreeing with this might seems odd and at odds with how the ASF works, but I think it does not, or at least, it will not. For a project as large and with such a huge history as NetBeans, there is no way we (ASF) will be able to *judge* who is rightfully put on that list, nor who has been left out erroneously. Meaning: a 'complete' initial committer list (for such a project) never can be put together proper. Trying to do so, like by going through all the history and enumerating all past contributors, IMO is a bad idea and will make things worse and more unclear, even more 'unfair'. And such a list will most certainly NOT be proper from an ASF POV, in the sense that we strive for a healthy and active committers and (P)PPMC list of people seriously engaged NOW. Project members who actually "do" stuff (doers decide). Past contributors who do want to re-engage again most certainly need to be valued and be admitted to become committer, but IMO better do this *when* they come knocking (actively) than enlisting them upfront. Having to 'prune' a huge, and likely too huge, list of initial committers before NetBeans graduates to TLP is going to be far more 'painful' than voting in active contributors when they actively show up. Which also is far more in line with "the Apache Way", more 'fair' so to say. Coming back to the maybe odd POV that the selection criteria for initial commmitters list does not have to be the same as that for future committers. IMO it simply cannot be 'equal' for a project like NetBeans. The primary role and responsibility for such initial committers is to get the project rolling and admit new committers base on *their* judgement. So the most important, and IMO only crucial, criteria for selecting the initial committers list is that those people are trusted to "do this right". And important for the community to realise: the IPMC and the assigned mentors are there to help them to do this right!
Re: Preliminary NetBeans cost findings
On 2016-09-25 17:45, Ross Gardler wrote: You seem to have taken my comment as an indication that I have concerns one way or the other. That is not the case. What I'm saying is that to make a case for extra budget there needs to be solid justification that a move to ASF will help the community grow. Ross, can you elaborate further on this? Your statement is rather confusing and AFAIK such a justification has never been put forward as a criteria for entering the ASF. The fact that NetBeans might need extra budget clearly makes it different than most other podlings, and as such it definitely requires extra attention. If you mean: expected grow of more active committers and more diversity among them, then that hardly looks like a problem to me. If anything, that *is* one of the primary reasons to move to the ASF. And while I agree with Geertjan that just looking at the Zeroturnaround productivity report is not a proper nor realistic measurement, if anything it shows there is still more than enough community using NetBeans today that we should not have to worry about a lack of that at all. I'd say on the contrary: it shows there is plenty to gain, and moving to the ASF can (and IMO will) be a great help in that direction. The ASF is not a magic bullet, there needs to be a plan coming from the incoming project. IMO the NetBeans proposal already provides the needed details for that plan. Including sound reasoning why they (and I) think the move to the ASF will benefit the project as well as the community. Nor have I have seen one single argument to the contrary. Regards, Ate The costings here are more than we usually get when a new podling is considered. This is a very good start. The data I refer to is only one data point. If you have data that contradicts it then provide it in your request for funds (yes this has been discussed to some extent across the main discuss thread, but it needs to be packaged up nicely for VP Infra, Prez and finally Board to consider. My one data point is http://pages.zeroturnaround.com/RebelLabs-Developer-Productivity-Report-2016.html?utm_source=rebellabs_allreports&utm_medium=rebellabs&utm_campaign=rebellabs (requires sign in). That reports shows a decline from 14% in 2012 to 10% today. To be fair that has been steady since 2014. The reason for my explicit request is that the foundation is currently running at a significant deficit. That's not a problem since we have many years of cash in the bank at the current deficit. However, we do need to plan for the future. So any new budget requests need to be fully justified. That's all I'm asking for. A "just because" is not sufficient. Like you and others have said there needs to be evidence to back up claims, simply adopting the apache way does not mean that NetBeans will be successful as an Apache project. If my data (limited to the above single data point) is inaccurate/invalid/not representative then you should have no problem providing evidence to the contrary when you ask for this budget. One final note, back in Jan 2015 the board approved a limited experiment with directed sponsorship to help alleviate issues like this. Maybe this would be useful to the NetBeans community. See presidents report here: http://apache.org/foundation/records/minutes/2015/board_minutes_2015_01_21.txt Ross -Original Message- From: m...@wadechandler.com [mailto:m...@wadechandler.com] On Behalf Of Wade Chandler Sent: Saturday, September 24, 2016 8:04 PM To: general@incubator.apache.org Subject: Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal) First, I think we need to see the data you are referring to. Anecdotally the NB community seems to be growing. We are certainly competing with more projects such as VS Code and others in recent years. However, given reviews over the past many years of Java IDEs, NB has consistently been in the top 3. IntelliJ IDEA Ultimate is not an open source project by the way, so I suggest any comparisons to it, especially in the context of an organization such as Apache, is not relevant. Money being one thing, and everything else another, including OSS versus sort of OSS, I think it a fair question, but I hope not a subjective and biased one. Has moving to Apache ever reversed trends which you are referring? For instance, does Apache champion it's own model over others? Why should a project move to the Apache way? Us in the NB community have pushed Oracle to move to a more open and community focused model for years. This sounded like it was about to happen, and many were excited to hear Apache, but I don't know what goal post this is, and if realistic, and if this email is to be viewed negatively or not. It doesn't seem oriented towards analyzing statements of cost to be applied in support of other projects, or a way forward based on cost reduction or code sharing given the initial estima
Re: Request to join Apache Streams (Incubating) as Mentor
On 2016-09-26 09:42, Sergio Fernández wrote: How this vote relates with the other thread about retiring Apache Streams to the attic? https://lists.apache.org/thread.html/077e46f67271c2e2e2d406b8b1f8cf9ae633a71bccffefdfd206d0b4@%3Cgeneral.incubator.apache.org%3E I'm a bit confused... maybe I missed some mails. I guess so :-) There has been new feedback and input which potentially might bring this podling back on its feet. And the offer from Suneel to become mentor for Apache Streams is part of that. For these reasons I've cancelled the vote for retirement, for now. Concerning the process for assigning Suneel as mentor, can we assume lazy consensus and just 'make it so' in a few days, if nobody objects? Thanks, Ate On Sun, Sep 25, 2016 at 12:25 PM, Ate Douma wrote: I'm happy to add and have Suneel join me as mentor for Apache Streams. I can't find anything about this: Is there any formal process or voting needed before I make this so? Ate On 2016-09-23 19:51, Suneel Marthi wrote: - 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
Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]
Hi Mark, On 2016-09-26 17:22, Mark Struberg wrote: Stian, this is established practice in the ASF since the very early days of playing with GIT. It is used e.g. in the following TLPs: TomEE DeltaSpike Johnzon CouchDB Maven and many, many more! It also got discussed on members, infra and even board lists. The suggestion 'this' is established practice in the ASF made me wonder. So I tried to lookup some reference, background and/or discussion around it. But I have not been able to find anything! Of the above listed projects, only DeltaSpike actually has a page describing *what* to do, written by you, but otherwise: nothing AFAICT. I also briefly scanned the members and board lists, seeing if I somehow missed a crucial discussion about this in the last several years. But nothing jumped out to me what might be related. I haven't been really actively involved (much) in ASF projects using git so far, so it didn't really matter much to me yet until now. And I probably didn't try hard enough researching it either. But if this really is an established practice, then at least it should be easy to find and properly described, somewhere. Especially as some incubator guide. So where is or was this discussed, do you have some pointers? Thanks, Ate The nice thing about GIT is that it absolutely doesn't matter where I push the commit to as long as the sha1 of the commit later pushed to the ASF repo is the same. Regarding 'pushing something different'. I trust an ASF member that he doesn't do that. Plus we have the sha as explained before. Regarding 'not getting pushed at all': This would get catched pretty quickly as we would miss the version update ;) Also bear in mind that ASF projects do NOT vote on the tags nor branches - we solely vote on the release source distributable! branches are there to be created and removed again Branches in GIT _cannot_ get removed from any downstream repo! That's the whole point. And if you do RCs, then you actually would have to later do a NEW vote again with the 'RC' removed from the version. But who guarantees that the source tarball is the same now? What if someone changed the source in the meantime? You see, it also has flaws. Perhaps "git tag --sign" so you get a PGP-signed tag commit would be a good idea? Agree, would be a good idea! It happens that I wrote the Maven GIT integration somewhen in the 2000s... ;) We don't have the tagging feature yet. Could you please file a ticket against Maven SCM? txs and LieGrue, strub On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes wrote: On 26 September 2016 at 14:34, Mark Struberg wrote: We *never* push commits for in-progress votes to hte ASF repos when we use GIT! The reason is that we cannot get rid of those afterwards! Of course we can delete the branch/tag/commit from the ASF repo, but we cannot delete them from all the hundreds downstream repos which almost immediately pull those changes... You can think of pushing this to a private (but PMC owned!) github repo as kind of parallel to the Maven 'staging' process. Of course it is up to each project what particular release/tag practice they want to follow. Many projects do this classically even with git, e.g. using branches or tags like 0.4-RC1 - see for instance: https://lists.apache.org/list.html?d...@jena.apache.org:lte=10M:VOTE Some communities like Apache Commons even keep around all RC tags; then archived emails around failed RCs still have valid links - e.g. https://github.com/apache/commons-lang/releases I wouldn't personally see a problem with a RC branch showing up in forked repositories - branches are there to be created and removed again - if downstream want to keep them for archival purposes that's their choice - just like they can keep the commit emails. But if that's not your project's cup of tea, then I guess just a commit IDs and hashes in the email should work, no matter where the commit 'is' - in git the commit is hashed and it's not forgotten after the vote is passed. Perhaps "git tag --sign" so you get a PGP-signed tag commit would be a good idea? Without the commit ID or hashes in the email - then particularly for mutable release candidates tags hosted in third-party repositories, we don't have a record over exactly what was voted on and the commiter could easily by mistake push the 'wrong' RC commits or dists without anyone being able to notice or check later. In fact, this very vote shows two different commit IDs which this time luckily had the same content. Many projects posts RCs on https://dist.apache.org/repos/dist/dev/ - which is SVN-based - here the revision number and log is sufficient - we assume the ASF-hosted SVN repository to be 'trusted'. A closed Nexus repository is similarly tracked and immutable.
Re: Preliminary NetBeans cost findings
+1 Ate On 2016-09-27 14:23, Mark Struberg wrote: +1 LieGrue, strub On Tuesday, 27 September 2016, 14:11, Bertrand Delacretaz wrote: On Tue, Sep 27, 2016 at 2:06 PM, John D. Ament wrote: Sooo does anyone feel that this needs to wait longer before starting a vote?.. I'm +1 for starting the vote. -Bertrand - 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: Preliminary NetBeans cost findings
On 2016-09-27 18:12, Bertrand Delacretaz wrote: On Tue, Sep 27, 2016 at 5:52 PM, Geertjan Wielenga wrote: ...I think for a lot of (NetBeans) folks lurking in these threads, it will be useful to know what voting means, who can vote, what 'binding votes' are, etc etc... Ok we can add that info in concise form once the vote thread starts. Basically, only Incubator PMC members votes are binding (meaning "legally valid" as far as the ASF is concerned), people shouldn't hijack the VOTE thread for discussions (start new threads if needed) and that's a majority vote that lasts >= 72 hours. Votes from other people are welcome as an indication of peoples enthusiasm (or lack thereof). Geertjan, are you ok with starting the vote? I'm currently at a conference with little time, if another mentor wants to start it that's fine with me. Make sure to include the text of https://wiki.apache.org/incubator/NetBeansProposal If can send out the vote mail in about an hour or so if everyone is OK. Ate -Bertrand - 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
