Re: Incubator PMC/Board report for February 2010 (Lucene Connector Framework Developers connectors-dev@incubator.apache.org)
I'll take care of this early next week. On Feb 1, 2010, at 9:00 AM, Incubator PMC wrote: Dear Lucene Connector Framework Developers, 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, 17 February 2010, 12 pm Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. 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 one week 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/February2010 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 -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
Corporate CLA Reminder
Per the IP Clearance form (see the Incubator website) I'm filling out for processing the Metacarta grant: Remind active committers that they are responsible for ensuring that a Corporate CLA is recorded if such is required to authorize their contributions under their individual CLA. Consider yourself reminded! If you think that might apply to you, check with your corporate attorney. I'm not in a position to say whether you need it or not, I'm just here to remind you that it is your responsibility to make such a determination. If you have questions on it, ask on legal-disc...@a.o. Cheers, Grant
Re: Mailing archives and project logo
On Feb 2, 2010, at 4:17 PM, Lukáš Vlček wrote: Hi, I noticed that mailing list archives linked here: http://incubator.apache.org/connectors/mail.html are not working yet (404). Is it that they haven't been setup yet? (I would like to go through history of email, as of now I found markmail.com helpful) Website error, I'll upload a fix. There seem to be running early discussion about project logo: http://cwiki.apache.org/confluence/display/CONNECTORS/Possible+Logos Are there any known requirements? Especially the final project name? Will it be Lucene Connector Framework or Apache Lucene Connector Framework? It was now always clear whether Apache word should be integrated in the logo (e.g. Lucene and Mahout does not have it, Solr and Droids does). I suppose the name is officially Apache Lucene Conn. Framework, but Lucene Conn. Framework is fine too. I'm also OK w/ LCF.
Re: Mailing archives and project logo
On Feb 2, 2010, at 4:17 PM, Lukáš Vlček wrote: Hi, I noticed that mailing list archives linked here: http://incubator.apache.org/connectors/mail.html are not working yet (404). Is it that they haven't been setup yet? (I would like to go through history of email, as of now I found markmail.com helpful) Should be fixed, but will take some time to propagate. In the meantime, see http://mail-archives.apache.org/mod_mbox/ for a list -Grant
Re: Connector building and distribution under Apache
On Feb 8, 2010, at 3:46 PM, Karl Wright wrote: Grant Ingersoll wrote: Inline On Feb 6, 2010, at 6:02 AM, Karl Wright wrote: Hi all, I have been thinking long and hard in terms of how, exactly, we may deliver all of the connectors in a manner compatible with Apache principles, and without violating copyrights/license agreements of all parties. The proposed strategy would be for Apache to provide the sources and ant build scripts that would produce all the proper connector jars, but only if the prerequisite non-Apache client jars or wsdls were supplied to ant. So, the ant build would conditionally detect whether it could indeed build each connector, based on what it was supplied. Some background first... As Grant is aware, the connectors fall into three basic categories: (a) those that are completely independent of any encumbered software from the system they are meant to connect to, (b) those that rely only on wsdls and xsds from the system they are connecting to, and (c) those that require compilation against client libraries that the target system vendor actively sells its clients for money. For the record, the connectors in category (a) are: file system (a test connector), jcifs connector (Windows share connector), jdbc connector, web connector, rss connector, and the lucene, gts, and null output connectors. The connectors in category (b) are the SharePoint connector and the Meridio connector. Category (c) contains connectors for LiveLink, Documentum, FileNet, and Memex. Obviously, the connectors in each class need to be handled in a manner consistent with that class's legal requirements. It seems clear that class (a) connectors will need no special handling. Class (b) merits much further discussion because SharePoint is a very popular repository these days. It seems to me that our choices for handling SharePoint or Meridio are as follows: (1) We get special permission from Microsoft and/or Meridio to distribute their wsdls and xsds - or we decide that we don't in fact need such permission, because we decide we can already distribute such interface specifications freely. You asked this over on legal-discuss@ right? I think the thinking was it was OK, right? That being said, we can likely contact the companies as well to get clarification. I know there are some MS contacts here at the ASF, so we can reach out to them. I can do this. Does anyone have Meridio contacts? Do you have links to the actual license agreements for these two connectors? Yes, I asked legal-discuss, although I did not get much of a response. In the end, we granted code plus directions as to how to obtain the proper wsdls. If non-response in legal-discuss is acquiescence, then we're good. I think there was finally a positive response that it was all right. As for Meridio contacts, that would probably best happen through m...@metacarta. But we don't have very good MS contacts. OK, how about you ask Meridio and I'll try to track down some MS contacts. (2) We purchase development licenses for Apache for such systems, make them open enough so that the wsdls can be accessed by anyone, and point maven and/or our build documentation at the appropriate urls. (In case you are unaware, in .NET development wsdls and xsds that a web service implements can be downloaded via http from the web service in question.) Not ideal due to the fact that it limits development to only committers. (3) The developers obtain the appropriate wsdls and xsds themselves, through whatever means available to them, and use axis and castor to generate appropriate java code, and then check the java code that was generated into apache svn. This could work, but has the same issue as #2. We should make as much of it automated as possible. Once the generated java code is checked in, then anyone can work on it, no? The only time it would need updating is when MS or Meridio releases a new version. (4) We treat the wsdls just like client libraries - see below. For class (c) connectors, we have the following realistic choices: (1) We release sources for the connectors, and instructions for populating the appropriate build areas with the required client jars. For this to work, developers for these connectors will need licensed access to the appropriate client jars themselves, This is the only short term solution. Agreed. and the details of the Apache release cycle for the connector may require purchase or donation of a target system development license for Apache itself. I doubt we will want to purchase these, as that won't be cost-effective. (2) We do a clean-room implementation of the client libraries in question, and distribute those. This is a last resort to me. I'd add #3 as another long term solution: Contact the various companies and make our case for why they should allow us to compile our
Re: Third tar.gz status?
That looks pretty good. Did you see my last question about the library dependencies? The Makefiles seem to be expecting them to be in /usr/share/... I think we need to include the dependencies ahead of time so we can make sure they are covered license wise. On Feb 9, 2010, at 7:42 AM, Karl Wright wrote: Hi Grant, Did you have a look at the third tar.gz I uploaded into the code-grant ticket? For this one, I used rat as you requested, and added licenses to all remaining jsp and java files. I'm not sure how those got missed; the engineer here who did the conversion in the first place is usually pretty thorough that way. There are still a few outstanding files of different kinds that I've been loathe to touch. For example, there are a couple of purportedly XML files in the SharePoint MCPermissions web service build. These have some kind of lead-in, however, and they are used by Visual Studio, so I was not sure I could safely drop a copyright into them. Also, we included Sun jsp standard library tld's in the grant inadvertantly; these of course can be distributed but were not ours to grant in the first place. Karl
Re: Ant builds
On Feb 9, 2010, at 9:21 AM, Karl Wright wrote: I'm looking at what is required for ant builds of LCF, and for this I sort of want to understand accepted practices for Apache builds of this kind. (1) Structure LCF will build many distinct jars, which need to be kept distinct because not all deployments can build or include all functionality. So there will be, at minimum: - A set of jars representing the framework itself - A set of jars for each connector I say a set here, because some components (e.g. the framework and the documentum connector) do in fact contain multiple sub-components. The question is - do we want a single ant build for the whole thing? Or independent ant builds for each major component? Based on the way it's packaged in debian for MetaCarta, independent components would be better. Is that acceptable? (2) Dependencies LCF requires upstream dependencies, many from apache, others from third parties such as postgresql. The dependencies come in the following flavors: - Sun dependency (standard jsp tag library jars and tlds: jstl.jar, standard.jar, sql.tld, c.tld, fmt.tld, x.tld, and servlet.jar) Do you know which Sun licenses? There might be Apache equivalents here. - Apache dependency, unexceptional (commons-fileupload, commons-collections, commons-codec, commons-logging, log4j, axis, castor) - Apache dependency, requiring upstream modifications in order to build properly (commons-httpclient, xerces2-java) - LGPL dependency, possibly requiring upstream modifications in order to run properly (jcifs) OK, we can do LGPL via a download or via Maven. - LGPL dependency, not requiring upstream modifications in order to run properly (postgres jdbc driver) Postgres JDBC driver is BSD, right? http://jdbc.postgresql.org/license.html - BSD jar dependency (Bitstream pool driver, jdbcpool-0.99.jar) - Third party proprietary jars (not enumerated here) - Dependencies which will be immediately removed (metacarta-license.jar) I take it we'll just presume, for the purposes of ant, that the correctly generated jars are just dropped in the ant/lib area? What ant build strategy should we use for all of the above categories? We should have a lib dir under trunk that contains the files. Similar to Lucene/Solr (3) Axis/castor build items Connectors that build from wsdls or xsds use axis or castor to generate the appropriate java class code. Is there a standard Apache ant task that we can use for these? Thanks, Karl
Re: ant build scripts done; should be possible for others to build now
On Feb 17, 2010, at 6:55 AM, Karl Wright wrote: +1 for o.a.lcf +1
Re: Upstream diffs
On Feb 23, 2010, at 2:16 PM, Karl Wright wrote: Grant Ingersoll wrote: On Feb 23, 2010, at 12:58 PM, Karl Wright wrote: Hi Grant, I think we need to figure out how we're going to tackle LCF upstream submissions for commons-httpclient and xerces-j. The diffs in question are in trunk/upstream-diffs. In both cases, the changes represent significant feature additions, so there may well be some politics involved in getting them accepted in their current form. I guess I'd suggest that we submit patches and then also maintain our own versions as necessary by checking in the appropriate library as something like commons-httpclient-lcf (or something else that indicates we've changed it), either that or abstract them above the library as part of LCF code so that no modification of the actual library is required. Well, the changes involved can't be structured as wrapping, I'm afraid, or that's exactly how we'd have done it. I'll rename the two libraries that are checked in. The xerces feature was already rejected by one of the maintainers. It basically allows you to enable resilience in the face of encoding errors, which we found quite a number of times in various RSS feeds. For some reason they didn't see the point. That's fine. As long as the patch lives somewhere out in the open so that we can say: We applied patch XYZ (located at ...) to Xerces version A.B. The biggest problem with patches will be in commons-httpclient, because there are several different features involved. I'll try to tease them apart so they can be attached to independent JIRA tickets. The big one there is complete NTLMv1, v2, and NTLM2 Session support. I sent that one along at one point but got no response whatsoever. There was also a feature involving the ability to supply your own protocol factory and have that be used everywhere, which I didn't even try to submit after the experience with the first one. Same deal as above. I'll try it all again, see if anything different happens this time if I mention this is required by LCF. If you've already submitted them, then I wouldn't bother. However, it is often the case that Open Source libs find it hard to digest large patches, so if they can be split out to smaller ones, that might be better.
Apache Lucene EuroCon Call For Participation: Prague, Czech Republic May 20 21, 2010
Apache Lucene EuroCon Call For Participation - Prague, Czech Republic May 20 21, 2010 All submissions must be received by Tuesday, April 13, 2010, 12 Midnight CET/6 PM US EDT The first European conference dedicated to Lucene and Solr is coming to Prague from May 18-21, 2010. Apache Lucene EuroCon is running on on not-for-profit basis, with net proceeds donated back to the Apache Software Foundation. The conference is sponsored by Lucid Imagination with additional support from community and other commercial co-sponsors. Key Dates: 24 March 2010: Call For Participation Open 13 April 2010: Call For Participation Closes 16 April 2010: Speaker Acceptance/Rejection Notification 18-19 May 2010: Lucene and Solr Pre-conference Training Sessions 20-21 May 2010: Apache Lucene EuroCon This conference creates a new opportunity for the Apache Lucene/Solr community and marketplace, providing the chance to gather, learn and collaborate on the latest in Apache Lucene and Solr search technologies and what's happening in the community and ecosystem. There will be two days of Lucene and Solr training offered May 18 19, and followed by two days packed with leading edge Lucene and Solr Open Source Search content and talks by search and open source thought leaders. We are soliciting 45-minute presentations for the conference, 20-21 May 2010 in Prague. The conference and all presentations will be in English. Topics of interest include: - Lucene and Solr in the Enterprise (case studies, implementation, return on investment, etc.) - “How We Did It” Development Case Studies - Spatial/Geo search - Lucene and Solr in the Cloud - Scalability and Performance Tuning - Large Scale Search - Real Time Search - Data Integration/Data Management - Tika, Nutch and Mahout - Lucene Connectors Framework - Faceting and Categorization - Relevance in Practice - Lucene Solr for Mobile Applications - Multi-language Support - Indexing and Analysis Techniques - Advanced Topics in Lucene Solr Development All accepted speakers will qualify for discounted conference admission. Financial assistance is available for speakers that qualify. To submit a 45-minute presentation proposal, please send an email to c...@lucene-eurocon.org containing the following information in plain text: 1. Your full name, title, and organization 2. Contact information, including your address, email, phone number 3. The name of your proposed session (keep your title simple and relevant to the topic) 4. A 75-200 word overview of your presentation (in English); in addition to the topic, describe whether your presentation is intended as a tutorial, description of an implementation, an theoretical/academic discussion, etc. 5. A 100-200-word speaker bio that includes prior conference speaking or related experience (in English) To be considered, proposals must be received by 12 Midnight CET Tuesday, 13 April 2010 (Tuesday 13 April 6 PM US Eastern time, 3 PM US Pacific Time). Please email any questions regarding the conference to i...@lucene-eurocon.org. To be added to the conference mailing list, please email sig...@lucene-eurocon.org. If your organization is interested in sponsorship opportunities, email spon...@lucene-eurocon.org Key Dates 24 March 2010: Call For Participation Open 13 April 2010: Call For Participation Closes 16 April 2010: Speaker Acceptance/Rejection Notification 18-19 May 2010 Lucene and Solr Pre-conference Training Sessions 20-21 May 2010: Apache Lucene EuroCon We look forward to seeing you in Prague! Grant Ingersoll Apache Lucene EuroCon Program Chair www.lucene-eurocon.org
Registration is now open for Apache Lucene EuroCon - Prague, Czech Republic, 18-21 May, 2010.
(sorry for the miss post yesterday, this is what should have been sent) Registration is now open for Apache Lucene EuroCon - Prague, Czech Republic, 18-21 May, 2010. To sign up, please visit: http://lucene-eurocon.org/register.html. Sponsored by Lucid Imagination; all net proceeds benefit the Apache Software Foundation. Come join us as we explore Lucene and Solr in-depth, including keynotes, user talks, audience interaction, and training. Meet other members of the community, and learn from their experience. See solutions from ecosystem partners. Get answers to your questions - and tips tricks to help with your projects. Oh, and did we mention that the Czech Beer Festival is also happening that week? Early Registration for the conference starts at €395 and runs until April 18, so sign up soon. Two-day Solr and Lucene Bootcamps will be held on 18-19 May. These will be in-depth, hands-on classes targeted at developers who want to build Lucene and Solr-based search applications. The two day tutorials will cover key concepts, along with code examples, documentation and resources - and will help solve most common search application problems. Participants will gain practical hands-on experience with Lucene Solr and the know-how to develop killer search code. Lastly, a reminder: the Call for Participation is still open, accepting submissions until April 13th. Hope to see you there! Grant Ingersoll Apache Lucene EuroCon Program Chair www.lucene-eurocon.org Apache Lucene Eurocon is a not-for-profit conference sponsored by Lucid Imagination. All net proceeds benefit the Apache Software Foundation
Fwd: Incubator report reminders sent for April 2010
FYI Begin forwarded message: From: no-re...@apache.org Date: April 1, 2010 10:00:12 AM EDT To: priv...@incubator.apache.org Subject: Incubator report reminders sent for April 2010 Reply-To: priv...@incubator.apache.org The next board meeting is scheduled for Wed, 21 April 2010, 12 pm Pacific. I have just sent reminder emails to these addresses, requesting them to supply board reports one week before the above date: Ace Developers ace-...@incubator.apache.org BeanValidation Developers gene...@incubator.apache.org Bluesky Developers bluesky-...@incubator.apache.org Chemistry Developers chemistry-...@incubator.apache.org Empire-db Developers empire-db-...@incubator.apache.org Imperius Developers imperius-...@incubator.apache.org JSPWiki Developers jspwiki-...@incubator.apache.org Lucene Connector Framework Developers connectors-dev@incubator.apache.org Olio Developers olio-...@incubator.apache.org OODT Developers oodt-...@incubator.apache.org Shiro Developers shiro-...@incubator.apache.org SIS Developers sis-...@incubator.apache.org Socialsite Developers socialsite-...@incubator.apache.org Tashi Developers tashi-...@incubator.apache.org Thrift Developers thrift-...@incubator.apache.org Traffic Server Developers trafficserver-...@incubator.apache.org UIMA Developers uima-...@incubator.apache.org VXQuery Developers vxquery-...@incubator.apache.org Marvin - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org
Re: Apache Lucene EuroCon Call For Participation: Prague, Czech Republic May 20 21, 2010
Just a reminder, just over one week left open on the CFP. Some great talks entered already. Keep it up! On Mar 24, 2010, at 8:03 PM, Grant Ingersoll wrote: Apache Lucene EuroCon Call For Participation - Prague, Czech Republic May 20 21, 2010 All submissions must be received by Tuesday, April 13, 2010, 12 Midnight CET/6 PM US EDT The first European conference dedicated to Lucene and Solr is coming to Prague from May 18-21, 2010. Apache Lucene EuroCon is running on on not-for-profit basis, with net proceeds donated back to the Apache Software Foundation. The conference is sponsored by Lucid Imagination with additional support from community and other commercial co-sponsors. Key Dates: 24 March 2010: Call For Participation Open 13 April 2010: Call For Participation Closes 16 April 2010: Speaker Acceptance/Rejection Notification 18-19 May 2010: Lucene and Solr Pre-conference Training Sessions 20-21 May 2010: Apache Lucene EuroCon This conference creates a new opportunity for the Apache Lucene/Solr community and marketplace, providing the chance to gather, learn and collaborate on the latest in Apache Lucene and Solr search technologies and what's happening in the community and ecosystem. There will be two days of Lucene and Solr training offered May 18 19, and followed by two days packed with leading edge Lucene and Solr Open Source Search content and talks by search and open source thought leaders. We are soliciting 45-minute presentations for the conference, 20-21 May 2010 in Prague. The conference and all presentations will be in English. Topics of interest include: - Lucene and Solr in the Enterprise (case studies, implementation, return on investment, etc.) - “How We Did It” Development Case Studies - Spatial/Geo search - Lucene and Solr in the Cloud - Scalability and Performance Tuning - Large Scale Search - Real Time Search - Data Integration/Data Management - Tika, Nutch and Mahout - Lucene Connectors Framework - Faceting and Categorization - Relevance in Practice - Lucene Solr for Mobile Applications - Multi-language Support - Indexing and Analysis Techniques - Advanced Topics in Lucene Solr Development All accepted speakers will qualify for discounted conference admission. Financial assistance is available for speakers that qualify. To submit a 45-minute presentation proposal, please send an email to c...@lucene-eurocon.org containing the following information in plain text: 1. Your full name, title, and organization 2. Contact information, including your address, email, phone number 3. The name of your proposed session (keep your title simple and relevant to the topic) 4. A 75-200 word overview of your presentation (in English); in addition to the topic, describe whether your presentation is intended as a tutorial, description of an implementation, an theoretical/academic discussion, etc. 5. A 100-200-word speaker bio that includes prior conference speaking or related experience (in English) To be considered, proposals must be received by 12 Midnight CET Tuesday, 13 April 2010 (Tuesday 13 April 6 PM US Eastern time, 3 PM US Pacific Time). Please email any questions regarding the conference to i...@lucene-eurocon.org. To be added to the conference mailing list, please email sig...@lucene-eurocon.org. If your organization is interested in sponsorship opportunities, email spon...@lucene-eurocon.org Key Dates 24 March 2010: Call For Participation Open 13 April 2010: Call For Participation Closes 16 April 2010: Speaker Acceptance/Rejection Notification 18-19 May 2010 Lucene and Solr Pre-conference Training Sessions 20-21 May 2010: Apache Lucene EuroCon We look forward to seeing you in Prague! Grant Ingersoll Apache Lucene EuroCon Program Chair www.lucene-eurocon.org
Re: LCF security with Solr
You should also see SOLR-1834. More later. On Apr 6, 2010, at 9:24 AM, Karl Wright wrote: Hi, This post pertains to the integration between Lucene Connectors Framework and Solr. I don't know a ton about Solr, but one of the engineers here at MetaCarta has become quite familiar with it. So, I took some time to try and work through one of the outstanding LCF/Solr integration issues, which is how to enforce the LCF security model using Solr. As many may be aware, the LCF model relies on access tokens (e.g. active directory SIDs). There are allow tokens, and deny tokens. They are currently dropped on the floor when Solr is involved, but they can readily (and most naturally) be handled to Solr as metadata when a document is ingested. Read more about the LCF security model here: http://cwiki.apache.org/confluence/display/CONNECTORS/Lucene+Connectors+Framework+concepts My proposal is therefore to do the following: (1) Choose specific metadata names that LCF will use for allow tokens and deny tokens; (2) Write a Solr request handler, which would peel out the special headers that LCF's mod_authz_annotate module puts into the request, and put those into a Solr request object; (3) Write a Solr search component, which pulls out the access tokens from the Solr request object, and effectively wraps all incoming queries with the appropriate clauses that limit the results returned according to the appropriate allow and deny metadata matches. Some questions: (a) Is this the right approach (bearing in mind that the LCF security model is pretty deeply ingrained in LCF at this time, and is thus not subject to significant changes); (b) Where should all of this live? Should it be a component of Solr, or a component of LCF? (c) The access tokens used by LCF are arbitrary strings, which are usually alphanumeric, but do contain certain punctuation. Would this cause a problem? Thanks, Karl
Re: Documentation push to site
Please ping priv...@incubator.apache.org. Also, please subscribe w/ your new address so I don't have to keep moderating you through. By the looks of it, LCF has it's first large company user ;-) -Grant On Apr 16, 2010, at 3:39 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Hi Grant, I've done a fair bit of work on the end-user documentation, but it isn't regularly pushing out to the site. Can you kick it (or whatever it was you did last time)? They still haven't granted me incubator group membership, so I'm stuck. Karl
Re: Documentation push to site
I did. I wonder why it isn't getting picked up. I'm running: 04 5 * * * /home/gsingers/bin/exportLCFDocs.sh /tmp/connectors-nightly.log 21 The script is: #!/bin/sh umask 002 /usr/local/bin/svn export --force http://svn.apache.org/repos/asf/incubator/lcf/site/publish /www/incubator.apache.org/connectors/ #/usr/local/bin/svn export --force http://svn.apache.org/repos/asf/lucene/java/trunk/docs /www/lucene.apache.org/java/docs/nightly On Apr 16, 2010, at 3:39 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Hi Grant, I've done a fair bit of work on the end-user documentation, but it isn't regularly pushing out to the site. Can you kick it (or whatever it was you did last time)? They still haven't granted me incubator group membership, so I'm stuck. Karl -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
Re: LCF report missing
I filled it today. On Jun 14, 2010, at 11:22 AM, Jukka Zitting wrote: Hi, I guess nobody took up the task of writing an LCF report for this months board meeting [1]. I was quite busy last week so I unfortunately didn't notice this in time. Sorry about that. The missing report is not too big a deal, but we'll need to submit an extra report next month. [1] http://wiki.apache.org/incubator/June2010 BR, Jukka Zitting
Re: Incubator Board Report June 2010
was accepted into the incubator on 11 May 2010. Status information is available at http://incubator.apache.org/projects/whirr.html. Progress since entry into the incubator: All the initial Incubator infrastructure items are now complete. The code hosted in the Hadoop contrib area has been moved to Whirr's subversion tree. Associated JIRAs have been moved to Whirr's JIRA. Plans for the next period: * Import the Whirr Java source Top three items to resolve before graduation: * Increase community involvement in the project * Make several incubating releases * Support at least three services on Whirr Any Issues that the Incubator PMC (IPMC) or ASF Board need to be aware of? None at this time. = Zeta Components = Zeta Components is a high-quality library of loosely-coupled PHP components. It has entered incubation on 2010-05-21. Therefore the project is still in ramp up phase. 3 most important issues to be tackled: * Create initial incubating infrastructure. * Move project and community to ASF. * Get developement based in ASF moving again. Mailing lists have already been created. Available are: * dev zeta-...@incubator.apache.org * user zeta-comm...@incubator.apache.org * commits zeta-us...@incubator.apache.org * private zeta-priv...@incubator.apache.org Website space has been reserved. Jira has been requested. All CLAs have been sent. Most of them have been processed and therefore most user accounts have been requested. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
Re: JSON license
These questions should be asked on legal-disc...@a.o. The good/evil thing, while clearly seeming stupid, should be reviewed by someone on the legal committee at the ASF. I'll forward there. On Jul 11, 2010, at 7:03 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Is the JSON license acceptable by Apache? It seems to be a variant of the Berkeley license: Copyright (c) 2002 JSON.org Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The Software shall be used for Good, not Evil. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Karl
Re: Project status and name
I think it needs to be brought up on the gene...@incubator.a.o list. I'm not sure it's ever happened before. FWIW: I'm +1 on ACF. On Aug 15, 2010, at 5:16 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Grant, what are the next steps here? Karl -Original Message- From: Wright Karl (Nokia-MS/Cambridge) Sent: Friday, August 13, 2010 5:53 PM To: connectors-dev@incubator.apache.org Subject: RE: Project status and name I don't think the name change is tied at all to the incubation status. Are we ready to call a vote? After much consideration, +1 for ACF. Karl From: ext Jack Krupansky [jack.krupan...@lucidimagination.com] Sent: Friday, August 13, 2010 5:51 PM To: connectors-dev@incubator.apache.org Subject: Re: Project status and name Any consensus on the name change? I am okay with either name. ACF should be fine. Presumably the nominal name change is contingent on its project status as no longer incubating under Lucene? -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 10, 2010 5:19 PM To: connectors-dev@incubator.apache.org Subject: Re: Project status and name I'd leave it open for another day or two. -Grant On Aug 10, 2010, at 2:16 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Shall we call a vote on the name change? Or should we leave the floor open for other proposals for a while? Karl -Original Message- From: ext Grant Ingersoll [mailto:gsing...@apache.org] Sent: Tuesday, August 10, 2010 2:09 PM To: connectors-dev@incubator.apache.org Subject: Re: Project status and name On Aug 10, 2010, at 8:05 AM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Folks, Lucene Connectors Framework is currently an incubating subproject of Lucene. The PMC has indicated that it's not thrilled with the idea of LCF being a subproject, Minor clarification: The PMC hasn't said no at this point, but it also hasn't been discussed. Given some of the recent restructuring, I was merely speculating privately to Karl that it likely would not accept it, but that is not anything official. Not that it needs to be decided now anyway. FWIW, the Board isn't usually happy w/ PMC's that are umbrella projects, with separate SVN, JIRA, etc. See the discussions in the archives around Mahout, Nutch, Lucy and Tika. When LCF was brought into incubation, there wasn't as much of a concern as there is now, so it is not that LCF did anything wrong. Besides, LCF is really independent of Lucene and useful w/o connecting to search and should have it's own management anyway. and that its status should change at some point in the future. Note that this status change would be theoretically independent of the project name, but potentially we'd consider changing the project name at that time as well. There's beginning to be a considerable amount of content floating around that talks about LCF. If there is a possibility of a name change for this project, I'd like to open the discussion as to whether we should change the name, and if so, what to. FWIW, the only other possibility I've heard mentioned so far is Apache Connectors Framework. I think this works well and abbreviates nicely to ACF (of course, I was the one who suggested it, so I'm biased). Note, there is no reason it can't be called the Lucene Connectors Framework, but that might pigeonhole it such that people think it only works with Lucene, which simply isn't true. I agree, we should do this change sooner rather than later, if it is going to be done. -Grant -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
Re: change the format of CHANGES.txt
On Aug 23, 2010, at 4:04 PM, Robert Muir wrote: Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. +1. We definitely should be giving credit to those who help.
Re: change the format of CHANGES.txt
I think this also underscores something we as an Incubating community should think about in terms of process. Obviously, it is great to give credit, but sometimes we also need to give people a chance to contribute, too. Even on seemingly trivial things (I don't have anything specific in mind) sometimes it makes sense to wait before making the change. For instance, say someone opens an issue, it might work to say something like Hey, great catch. Could you generate a patch? See https://cwiki.apache.org/confluence/display/CONNECTORS/HowToContribute for info on how to do that. If they do give one, then commit it promptly and give them credit. If not, let it sit for a few days before making the change to see if someone else steps up. Sure, it slows down some things, but it gives people a chance to help out and be involved. These smaller issues are also a great way for us newbie committers to get our hands dirty with the code. -Grant On Aug 23, 2010, at 4:46 PM, karl.wri...@nokia.com wrote: +1 from me. Karl -Original Message- From: ext Robert Muir [mailto:rcm...@gmail.com] Sent: Monday, August 23, 2010 4:05 PM To: connectors-dev@incubator.apache.org Subject: change the format of CHANGES.txt Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. -- Robert Muir rcm...@gmail.com
Re: Name change official
Scratch that. There seems to be some consternation on gene...@incubator about the name, saying it's too generic. Ugh. On Aug 19, 2010, at 4:27 PM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Apparently we are green to go ahead with the proposed name change. I'd like to propose at this time that no actual source code or packages be changed. I suggest instead that the name change occur to the site materials, documentation, and collateral materials exclusively. Any thoughts? Karl -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
Re: [VOTE]: Change svn root for Apache Connectors Framework?
You should be subscribed to gene...@incubator.apache.org. At any rate, it's not clear yet. -Grant On Aug 25, 2010, at 9:25 AM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: I'm not subscribed to that list - I've been going on what Grant posted to connectors-dev about the decision being made. If it's going to be undone I'd sure like to know. Karl -Original Message- From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com] Sent: Wednesday, August 25, 2010 9:17 AM To: connectors-dev@incubator.apache.org Subject: Re: [VOTE]: Change svn root for Apache Connectors Framework? I am in favor of the change assuming the name change is officially official despite the chatter on gene...@incubator.apache.org, but I'd like to see some confirmation that the grumbling has subsided over there. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Wednesday, August 25, 2010 8:23 AM To: connectors-dev connectors-dev@incubator.apache.org Subject: [VOTE]: Change svn root for Apache Connectors Framework? Vote +1 to change the root of the svn repository for Apache Connectors Framework from: https://svn.apache.org/repos/asf/incubator/lcf to: https://svn.apache.org/repos/asf/incubator/acf Vote will remain open until 5:00 PM Friday, August 27th, Boston time (EDT). (I'm trying to do this right this time, so let me know if I still don't have the process quite correct.) Thanks, Karl -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
Re: About name change
On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
Re: About name change
FWIW, I like Jack's suggestion of Apache Yukon, but we probably should see if there are any confusingly similar names out there (i.e. connector software named Yukon). On Aug 26, 2010, at 9:04 AM, Jack Krupansky wrote: Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
Re: About name change
Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
Done. I'll keep you posted. On Sep 13, 2010, at 2:25 PM, Karl Wright wrote: +1 to both. Karl On Mon, Sep 13, 2010 at 2:22 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search
Re: [RESULT][VOTE] Pick your preferred name
https://issues.apache.org/jira/browse/LEGAL-80 has been created to track the NTLM issue. Sam Ruby is working w/ the ASF attorneys on this. I don't know how long it will take. In a separate thread, we should discuss workarounds/fallback plans so that we are prepared either way. -Grant On Sep 13, 2010, at 2:25 PM, Karl Wright wrote: +1 to both. Karl On Mon, Sep 13, 2010 at 2:22 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
News should be posted on the JIRA issue. For now, it's being handled internally. Seems we aren't the only ones w/ the issue and apparently MINA has been shipping with it. -Grant On Sep 15, 2010, at 5:51 PM, Karl Wright wrote: Any news on this? Karl On Tue, Sep 14, 2010 at 9:42 AM, Grant Ingersoll gsing...@apache.orgwrote: https://issues.apache.org/jira/browse/LEGAL-80 has been created to track the NTLM issue. Sam Ruby is working w/ the ASF attorneys on this. I don't know how long it will take. In a separate thread, we should discuss workarounds/fallback plans so that we are prepared either way. -Grant On Sep 13, 2010, at 2:25 PM, Karl Wright wrote: +1 to both. Karl On Mon, Sep 13, 2010 at 2:22 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search
Re: [RESULT][VOTE] Pick your preferred name
The general consensus from Board members expressing an opinion (and it was not a call for a binding vote, so it is not officially a Board decision, but is rather the opinion of a couple of Board members) was that the name is less than ideal, but no action by the Board should be taken to stop it. That being said, those who did express an opinion felt the name was less than ideal. Several other ASF Members also felt it was a less than ideal name. Also, my two cents: The views of these Board members at this time should not be construed to be the views of some future Board reviewing a TLP Graduation request. In other words, the Board is elected once a year. Opinions could change enough that they could still say no to the name in the future. Short of graduation vote, I don't see a way around that. I don't think you would get the Board to vote on a future event of this nature that binds some future Board to a particular position. So, I guess it is up to the community at this point. I personally feel ManifoldCF is the best choice at this point, as it removes the risk around the genericness of ACF and also removes the trademark concern around the 2nd most popular name choice of Manifold. I don't like Yukon or Macon as I think they are too generic in the broader world (GMC Yukon, Yukon Territories, Macon GA) such that our SEO is limited, thereby making it harder for people to find us. At the same time, the current vote has passed not just here, but also up the chain, so if it goes forward, so be it. -Grant On Sep 20, 2010, at 6:03 AM, Karl Wright wrote: Any news from the board? Karl On Thu, Sep 16, 2010 at 6:00 AM, Karl Wright daddy...@gmail.com wrote: Yes, I've been following the JIRA issue. I'm actually more curious about the board's opinion of the name choice. Karl On Wed, Sep 15, 2010 at 10:05 PM, Grant Ingersoll gsing...@apache.org wrote: News should be posted on the JIRA issue. For now, it's being handled internally. Seems we aren't the only ones w/ the issue and apparently MINA has been shipping with it. -Grant On Sep 15, 2010, at 5:51 PM, Karl Wright wrote: Any news on this? Karl On Tue, Sep 14, 2010 at 9:42 AM, Grant Ingersoll gsing...@apache.orgwrote: https://issues.apache.org/jira/browse/LEGAL-80 has been created to track the NTLM issue. Sam Ruby is working w/ the ASF attorneys on this. I don't know how long it will take. In a separate thread, we should discuss workarounds/fallback plans so that we are prepared either way. -Grant On Sep 13, 2010, at 2:25 PM, Karl Wright wrote: +1 to both. Karl On Mon, Sep 13, 2010 at 2:22 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [VOTE] Select a name to possibly replace Apache Connectors Framework
ManifoldCF -Grant On Sep 23, 2010, at 5:28 PM, Karl Wright wrote: Folks, Grant feels we would have a better chance of graduating from incubation without changes if we adopt a new name. There will thus be two votes. First vote is designed to arrive at a name, and the second vote will be on whether to use that highest-point name instead of Apache Connectors Framework. Because the list is quite long this time, please select your favorite 8 choices, in order of preference. If you submit duplicate choices, only the first of each duplicate will be counted, and the others will receive zero points. So it is in your interest to not select any duplicates. All of these choices have been already screened to fulfill specific criteria, such as avoidance of trademarks or heavily used words. The list of candidates is: Ayvitraya Conex Connex Connie Connx Contango Conton Contor Contour Conx Heterolink Heterosource Heteroweb Manicon ManifoldCF Manifolio Manilink Maniplex Manisource Maniweb Multicon Multiconnect Multiconnex Ralph Reconto RepoMan Repositor Recon Reconex Reconn Reconnex Reconnx Reconx Let the voting begin! Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: Naming status?
It's up to the community. I'm not the authority. If the vote passed, let's just go with it. -Grant On Oct 16, 2010, at 7:15 AM, Jack Krupansky wrote: I'd prefer that Grant close the deal on the name since he is the one with clout at Apache, but you could do it as well, I suppose - I don't know how these things really work yet. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Saturday, October 16, 2010 7:04 AM To: connectors-dev@incubator.apache.org Subject: Re: Naming status? The vote made it official, as far as I can tell. If you are referring to incubator-general, someone probably should post, yes, but given that the name originally came from there I think that's a formality. Do you or Grant want to do this? Or shall I? Changing the wiki name requires a ticket to be entered for INFRASTRUCTURE. No other problem with doing it. Changing the repository name will yank any changed workareas out from under the committers, and people who have checkouts. I believe you can fix this with svn switch. On the other hand, I'd prefer to finish off a few things first, so I don't risk losing them. Changing mailing lists and JIRA base name is much more problematic since we'd lose tickets and history, I think. So I'd prefer to leave those alone if we can. Karl On Sat, Oct 16, 2010 at 6:57 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: Where are we as far as making the ManifoldCF name official? Or is it merely a matter of posting it on the general list and seeing if anybody has any major objection? Some other name references that presumably simply await making the name official: 1. The repository is still lcf. 2. The wiki top level name is Apache Connectors Framework on the Apache Dashboard. 3. The mailing list names are connectors-. 4. The Jira name is CONNECTORS. Are there any risks with changing the latter two? -- Jack Krupansky -- Grant Ingersoll http://www.lucidimagination.com
Re: Naming status?
I meant to say, I think we met the concerns of others. I don't think we need to go rehash it again. On Oct 16, 2010, at 7:15 AM, Jack Krupansky wrote: I'd prefer that Grant close the deal on the name since he is the one with clout at Apache, but you could do it as well, I suppose - I don't know how these things really work yet. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Saturday, October 16, 2010 7:04 AM To: connectors-dev@incubator.apache.org Subject: Re: Naming status? The vote made it official, as far as I can tell. If you are referring to incubator-general, someone probably should post, yes, but given that the name originally came from there I think that's a formality. Do you or Grant want to do this? Or shall I? Changing the wiki name requires a ticket to be entered for INFRASTRUCTURE. No other problem with doing it. Changing the repository name will yank any changed workareas out from under the committers, and people who have checkouts. I believe you can fix this with svn switch. On the other hand, I'd prefer to finish off a few things first, so I don't risk losing them. Changing mailing lists and JIRA base name is much more problematic since we'd lose tickets and history, I think. So I'd prefer to leave those alone if we can. Karl On Sat, Oct 16, 2010 at 6:57 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: Where are we as far as making the ManifoldCF name official? Or is it merely a matter of posting it on the general list and seeing if anybody has any major objection? Some other name references that presumably simply await making the name official: 1. The repository is still lcf. 2. The wiki top level name is Apache Connectors Framework on the Apache Dashboard. 3. The mailing list names are connectors-. 4. The Jira name is CONNECTORS. Are there any risks with changing the latter two? -- Jack Krupansky -- Grant Ingersoll http://www.lucidimagination.com
LEGAL-80 (NTLM)
Looks like we've been given the green light for NTLM inclusion. See https://issues.apache.org/jira/browse/LEGAL-80
Release?
Now that we have NTLM figured out and the Memex stuff behind us, how do people feel about working towards a release? -Grant
Re: Release?
that, but I agree with Jack that 0.1 would be useful if we only get that far. Thoughts? Karl On Tue, Nov 9, 2010 at 8:58 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: At least get a release 0.1 dry-run with code as-is out ASAP to flush out release process issues. This would help to send out a message to the rest of the world that MCF is an available product rather than purely development/incubation. Then come up with a list of issues that people strongly feel need to be resolved before a true, squeaky-clean 1.0 release. Maybe that is the original list of tasks, including better testing, but some review/decisions are probably needed. That will be the ultimate target. Then decide on a close enough subset of issues that would constitute what people consider a solid beta and target that as a release 0.5 and focus on that as the near-term target (after getting 0.1 out ASAP.) I personally do not have any major issues on the top of my head that I would hold out as blockers for a 0.5. Or, get 0.1 out and then move on to a 0.2, etc. on a monthly/bi-monthly basis as progress is made. In short, get MCF as-is 0.1 out ASAP, have a very short list for MCF 0.5 to get it out reasonably soon, and then revisit what 1.0 really means versus 0.6, etc. -- Jack Krupansky -Original Message- From: Grant Ingersoll Sent: Tuesday, November 09, 2010 8:38 AM To: connectors-dev@incubator.apache.org Subject: Release? Now that we have NTLM figured out and the Memex stuff behind us, how do people feel about working towards a release? -Grant -- Grant Ingersoll http://www.lucidimagination.com
Re: Release?
On Nov 9, 2010, at 1:56 PM, Karl Wright wrote: Proposal: Release to consist of two things: tar and zip of a complete source tree, and tar and zip of the modules/dist area after the build. The implied way people are to work with this is: - to use just the distribution, untar or unzip the distribution zip/tar into a work area, and either use the multiprocess version, or the quickstart example. - to add a connector, untar or unzip the source zip/tar into a work area, and integrate your connector into the build. Is this acceptable for a 0.1 release? I think so. This first release is about getting something out there that people can dig into a bit. It also is about laying the legal groundwork (NOTICE.txt, licenses, etc.) to show that we know how to do releases. -Grant
Re: Release?
On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check it out and try it as there will likely be issues for the first release. Once we all feel we have a decent candidate, we can call a vote, which should be a formality. See http://apache.org/dev/#releases for more info. Karl On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright daddy...@gmail.com wrote: The build changes are complete. I removed the modules level from the hierarchy because it served no useful purpose and complicated matters. The outer level build.xml now allows you build code, docs, and run tests separately from one another, and gives you help as a default. ant image builds you the deliverable .zip and tar.gz files. Online site has been polished so that it now contains complete javadoc, as does the built and delivered .zip and tar.gz's. In short, we *could* actually do a release now, if only we had (and incorporated) the KEYS file I alluded to earlier, which I do not know how to build or obtain. I believe this needs to be both generated and registered. The site also needs to refer to a download location/list of mirrors before it could go out the door. Help? Grant? Karl On Wed, Nov 17, 2010 at 9:50 PM, Karl Wright daddy...@gmail.com wrote: Hearing nothing, went ahead and made the port of documentation to the site official. I also now include the generated site in the release tar.gz and .zip. Issues still to address before release: (1) source tar.gz and zip in outer-level build.xml, which I will try to address shortly. (2) vehicle for release downloads, and naming thereof. In short, where do I put these things so people can download them?? (3) Voting procedures for release. I've seen this done as a vote in gene...@incubator.org - is that actually necessary? (4) Release branch and tag. Do we want both? What is the correct naming for each in apache? (5) Legal requirements. CHANGES.txt, LICENSE.txt, etc. Do these need to be included in the release tar.gz, or just the source tar.gz? I suspect both, but please confirm. Also, if there is a typical organization of the release tar.gz in relation to the source tar.gz this would be a good time to make that known. Thanks, Karl On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright daddy...@gmail.com wrote: What I've done here is taken all the pages that I originally put in the Wiki, describing how to set up and run ManifoldCF, and converted them to xdocs that are part of the ManifoldCF site. These documents have no user content other than stuff Grant or I added, according to their logs, so I feel that is safe to do. I've left the wiki pages around but am thinking we'll want them to go away at some point. Not sure exactly what to do with all the user comments to them, however. Is this a reasonable way to proceed? We should avoid using the wiki in the future for documentation, seems to me, but otherwise I can see no issues here. Karl On Tue, Nov 16, 2010 at 5:36 PM, Grant Ingersoll gsing...@apache.org wrote: On Nov 15, 2010, at 1:23 PM, Jack Krupansky wrote: I didn't mean to imply that the wiki needs to be physically included in the release zip/tar, just that snapshotting and versioning of the wiki should be done, if feasible, so that a user who is on an older release can still see the doc for that release. I am just thinking ahead for future releases. So, 0.1 does not need this right now. Right, and I'm saying that we can't include user generated content in a release unless we have explicitly asked for permission on it in the form of patches and then committed by a committer. Since we don't lock down our wiki, we can't do it. -- Jack Krupansky -Original Message- From: Grant Ingersoll Sent: Monday, November 15, 2010 10:23 AM To: connectors-dev@incubator.apache.org Subject: Re: Release? On Nov 10, 2010, at 1:22 AM, Jack Krupansky wrote: And the wiki doc is also part of the release. Does this stuff get a version/release as well? Presumably we want doc for currently supported releases, and the doc can vary between releases. Can we easily snapshot the wiki? You can't put Wiki in a release, as their is no way to track whether the person has permission to donate it.. Will we have nightly builds in place? I think a 0.1 can get released without a nightly build, but it would be nice to say
Re: Release?
I'll take a look, but it won't likely be until Tuesday (extended Turkey going on here!) On Nov 24, 2010, at 8:39 AM, Karl Wright wrote: Uploaded RC1. Karl On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright daddy...@gmail.com wrote: A problem with the FileNet connector has caused me to build an RC1. It's uploading now. Karl On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the hardest of the work. I'm busy on some other things right now, but maybe next week I can take a look. -- Jack Krupansky -Original Message- From: Karl Wright Sent: Tuesday, November 23, 2010 1:00 PM To: connectors-dev@incubator.apache.org Subject: Re: Release? While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check it out and try it as there will likely be issues for the first release. Once we all feel we have a decent candidate, we can call a vote, which should be a formality. See http://apache.org/dev/#releases for more info. Karl On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright daddy...@gmail.com wrote: The build changes are complete. I removed the modules level from the hierarchy because it served no useful purpose and complicated matters. The outer level build.xml now allows you build code, docs, and run tests separately from one another, and gives you help as a default. ant image builds you the deliverable .zip and tar.gz files. Online site has been polished so that it now contains complete javadoc, as does the built and delivered .zip and tar.gz's. In short, we *could* actually do a release now, if only we had (and incorporated) the KEYS file I alluded to earlier, which I do not know how to build or obtain. I believe this needs to be both generated and registered. The site also needs to refer to a download location/list of mirrors before it could go out the door. Help? Grant? Karl On Wed, Nov 17, 2010 at 9:50 PM, Karl Wright daddy...@gmail.com wrote: Hearing nothing, went ahead and made the port of documentation to the site official. I also now include the generated site in the release tar.gz and .zip. Issues still to address before release: (1) source tar.gz and zip in outer-level build.xml, which I will try to address shortly. (2) vehicle for release downloads, and naming thereof. In short, where do I put these things so people can download them?? (3) Voting procedures for release. I've seen this done as a vote in gene...@incubator.org - is that actually necessary? (4) Release branch and tag. Do we want both? What is the correct naming for each in apache? (5) Legal requirements. CHANGES.txt, LICENSE.txt, etc. Do these need to be included in the release tar.gz, or just the source tar.gz? I suspect both, but please confirm. Also, if there is a typical organization of the release tar.gz in relation to the source tar.gz this would be a good time to make that known. Thanks, Karl On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright daddy...@gmail.com wrote: What I've done here is taken all the pages that I originally put
FYI, Incubator Status Page
I have updated our Incubation status page to reflect ManifoldCF instead of LCF. It should propagate through the system in the next few hours. -Grant
Re: Release?
Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check it out and try it as there will likely be issues for the first release. Once we all feel we have a decent candidate, we can call a vote, which should be a formality. See http://apache.org/dev/#releases for more info. Karl On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright daddy...@gmail.com wrote: The build changes are complete. I removed the modules level from the hierarchy because it served no useful purpose and complicated matters. The outer level build.xml now allows you build code, docs, and run tests separately from one another, and gives you help as a default. ant image builds you the deliverable .zip and tar.gz files. Online site has been polished so that it now contains complete javadoc, as does the built and delivered .zip and tar.gz's. In short, we *could* actually do a release now, if only we had (and incorporated) the KEYS file I alluded to earlier, which I do not know how to build or obtain. I believe this needs to be both generated and registered. The site also needs to refer to a download location/list of mirrors before it could go out the door. Help? Grant? Karl On Wed, Nov 17, 2010 at 9:50 PM, Karl Wright daddy...@gmail.com wrote: Hearing nothing, went ahead and made the port of documentation to the site official. I also now include the generated site in the release tar.gz and .zip. Issues still to address before release: (1) source tar.gz and zip in outer-level build.xml, which I will try to address shortly. (2) vehicle for release downloads, and naming thereof. In short, where do I put these things so people can download them?? (3) Voting procedures for release. I've seen this done as a vote in gene...@incubator.org - is that actually necessary? (4) Release branch and tag. Do we want both? What is the correct naming for each in apache? (5) Legal requirements. CHANGES.txt, LICENSE.txt, etc. Do these need to be included in the release tar.gz, or just the source tar.gz? I suspect both, but please confirm. Also, if there is a typical organization of the release tar.gz in relation to the source tar.gz this would be a good time to make that known. Thanks, Karl On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright daddy...@gmail.com wrote: What I've done here is taken all the pages that I originally put in the Wiki, describing how to set up and run ManifoldCF, and converted them to xdocs that are part of the ManifoldCF site. These documents have no user content other than stuff Grant or I added, according to their logs, so I feel that is safe to do. I've left the wiki pages around but am thinking we'll want them to go away at some point. Not sure exactly what to do with all the user comments to them, however. Is this a reasonable way to proceed? We should avoid
Re: Release?
Hmm, for some reason I can't import the KEYS file gpg --import KEYS On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright daddy...@gmail.com wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll gsing...@apache.org wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check it out and try it as there will likely be issues for the first release. Once we all feel we have a decent candidate, we can call a vote, which should be a formality. See http://apache.org/dev/#releases for more info. Karl On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright daddy...@gmail.com wrote: The build changes are complete. I removed the modules level from the hierarchy because it served no useful purpose and complicated matters. The outer level build.xml now allows you build code, docs, and run tests separately from one another, and gives you help as a default. ant image builds you the deliverable .zip and tar.gz files. Online site has been polished so that it now contains complete javadoc, as does the built and delivered .zip and tar.gz's. In short, we *could* actually do a release now, if only we had (and incorporated) the KEYS file I alluded to earlier, which I do not know how to build or obtain. I believe this needs to be both generated and registered. The site also needs to refer to a download location/list of mirrors before it could go out the door. Help? Grant? Karl On Wed, Nov 17, 2010 at 9:50 PM, Karl Wright daddy...@gmail.com wrote: Hearing nothing, went ahead and made the port of documentation to the site official. I also now include the generated site in the release tar.gz and .zip. Issues still to address before release: (1) source tar.gz and zip in outer-level build.xml, which I will try to address shortly. (2) vehicle for release downloads, and naming thereof. In short, where do I put these things so people can download them?? (3) Voting procedures for release. I've seen this done as a vote in gene...@incubator.org - is that actually necessary? (4) Release branch and tag. Do we want both? What is the correct naming for each in apache? (5) Legal requirements. CHANGES.txt, LICENSE.txt, etc. Do these need to be included in the release tar.gz, or just the source tar.gz? I suspect both, but please confirm. Also, if there is a typical organization of the release tar.gz in relation to the source tar.gz this would be a good time to make that known. Thanks, Karl On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright daddy...@gmail.com wrote: What I've done here is taken all the pages that I originally put in the Wiki, describing how to set up and run ManifoldCF, and converted them to xdocs that are part of the ManifoldCF site
Re: Release?
On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named apache-manifoldcf-0.1. You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll gsing...@apache.org wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? 7. I still see Memex stuff in connectors dir. I didn't check other places. 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers Other than that, some other eyes on it would be good. -Grant On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright daddy...@gmail.com wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll gsing...@apache.org wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check it out and try it as there will likely be issues for the first release. Once we all feel we have a decent candidate, we can call a vote, which should be a formality. See http://apache.org/dev/#releases for more info. Karl On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright daddy...@gmail.com wrote: The build changes are complete. I removed the modules level from the hierarchy because it served no useful purpose and complicated matters. The outer level build.xml now allows you build code, docs, and run tests separately from one another, and gives you help as a default. ant image builds you the deliverable .zip and tar.gz files. Online site has been polished so
Re: Release?
On Dec 2, 2010, at 9:58 PM, Karl Wright wrote: For your questions (6) and (7): The json code we use comes from www.json.org, and there is no prebuilt jar from that source, just source files. Hmmm. OK. The license on it is fine, but we should make sure it is properly attributed. Either that or just build the jar offline, put a note as to where to get the source and package the jar. We therefore build it ourselves. For the memex connector, we still have all the build machinery in place, on the chance that somebody will supply the connector code. It is conditional in any case, so there is no harm in maintaining it there. The files that Memex wanted removed are not included. OK. That sounds fine.
Re: Release?
I added the RAT stuff ant rat-sources It can be refined a bit to exclude some things, but running it shows a whole lot of stuff that doesn't have headers. Also, I noticed we have a whole lot of files that refer to Metacarta still. I think those need to be changed. -Grant On Dec 2, 2010, at 11:11 PM, Karl Wright wrote: Great! Karl On Thu, Dec 2, 2010 at 10:20 PM, Grant Ingersoll gsing...@apache.org wrote: I can hook up the RAT stuff. On Dec 2, 2010, at 10:02 PM, Karl Wright wrote: OK, so I will do the appropriate things to make (1), (4), and maybe (5) happen. Does anyone want to help with (2), (3), and (8)? Karl On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll gsing...@apache.org wrote: On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named apache-manifoldcf-0.1. You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll gsing...@apache.org wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? 7. I still see Memex stuff in connectors dir. I didn't check other places. 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers Other than that, some other eyes on it would be good. -Grant On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright daddy...@gmail.com wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll gsing...@apache.org wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather
Re: Release?
On Dec 3, 2010, at 8:32 AM, Karl Wright wrote: Can you be more specific about the files that refer to metacarta? Or does Rat know to look for MetaCarta? I just happened to notice them in the RAT output. It looked like properties files. Examples: /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings FYI, to run RAT, you need to download the JARs and place them in your ANT lib. http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
Re: Release?
FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz -Grant On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: ... going twice ... Karl On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright daddy...@gmail.com wrote: I'm done with (1), (4), and (5). Still waiting for help with (2) and (3)... going once Karl On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright daddy...@gmail.com wrote: OK, so I will do the appropriate things to make (1), (4), and maybe (5) happen. Does anyone want to help with (2), (3), and (8)? Karl On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll gsing...@apache.org wrote: On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named apache-manifoldcf-0.1. You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll gsing...@apache.org wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? 7. I still see Memex stuff in connectors dir. I didn't check other places. 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers Other than that, some other eyes on it would be good. -Grant On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright daddy...@gmail.com wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll gsing...@apache.org wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for me, so I'll clearly have to find another way. Karl On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright daddy...@gmail.com wrote: I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available? Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll gsing...@apache.org wrote: On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: I've created a signing key, and checked in a KEYS file. Apache instructions for this are actually decent, so I didn't have to make much stuff up. Glad about that. Yep, sorry, have been in meetings. Last remaining release issue is getting the release files to a download mirror. Maybe I can find some doc for that too. Next steps would be to generate a candidate release which the rest of us can download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a note to the list saying where to locate it. Rather than call a vote right away, just ask us to check
Re: [RESULT][VOTE] Release ManifoldCF 0.1?
Sorry for the long delay. I think we are in pretty good shape as far as the legal bits go. I also did an ant test and went over the signatures, LICENSE.txt, NOTICE.txt and checked out the license headers via RAT. For a 0.1 release, here's my +1. For the record, Karl, you can vote and it is binding. Other PPMC members are the committers, so they should check it out and vote too. -Grant On Jan 3, 2011, at 6:11 AM, Karl Wright wrote: Any news on this front? Karl On Sun, Dec 26, 2010 at 6:27 PM, Karl Wright daddy...@gmail.com wrote: I hope we can scrape together two more votes. Who else is on the PPMC for ManifoldCF? That's never been clear to me. Karl On Fri, Dec 24, 2010 at 4:04 PM, Grant Ingersoll gsing...@apache.org wrote: Yeah, sorry. It is the holidays for me. I hope to look at it on Monday. For the record, we need 3 votes from the PPMC and then I think we need to go to the Incubator PMC and vote there, but I will read up on it. On Dec 24, 2010, at 11:17 AM, Jack Krupansky wrote: It's most likely the holidays. Too much of a mad rush, either to leave early or to get real work done to try to leave early. Sorry I wasn't able to find time to try out the RC. Hopefully... next week will be slow and I'll have better luck finding a few minutes of quiet time. -- Jack Krupansky -Original Message- From: Karl Wright Sent: Friday, December 24, 2010 11:09 AM To: connectors-dev Subject: [RESULT][VOTE] Release ManifoldCF 0.1? There were zero votes in favor, and zero against. I feel little uncomfortable voting myself, since I put together the release. Therefore, the vote effectively fails. Karl On Sun, Dec 19, 2010 at 7:33 PM, Karl Wright daddy...@gmail.com wrote: +1 if you think ManifoldCF 0.1 is ready for release, -1 if not. (If this vote passes, I believe we will still need to hold a vote in the incubator general list.) Thanks, Karl -- Grant Ingersoll http://www.lucidimagination.com -- Grant Ingersoll http://www.lucidimagination.com
Re: [VOTE] Release Apache ManifoldCF 0.1 Incubating, RC8
+1. Checked sigs, ran the tests, looked at CHANGES, etc. On Jan 17, 2011, at 3:04 AM, Karl Wright wrote: C'mon, guys - we just need two more binding PMC votes... Karl On Tue, Jan 11, 2011 at 10:19 PM, Karl Wright daddy...@gmail.com wrote: RC8 is ready. This fixes the problems found in CONNECTORS-149. Find it at: http://people.apache.org/~kwright/apache-manifoldcf-0.1-incubating The svn tag URL is http://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.1-incubating-RC8 Please evaluate the candidate, and if you find it OK then vote. I've completed my review of the deletion/expiration code, and although there are a couple of other tickets from that review, they do not (in my opinion) warrant holding the release. +1 from me. Karl -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search
Re: Next release?
0.2 makes sense. I think we need to figure out how to attract more contribution. It may have been a mistake to have separate user and dev lists at this point in the game. We need users to also be contributors. -Grant On Feb 20, 2011, at 9:20 PM, Karl Wright wrote: A lot of fairly critical fixes and changes have already taken place since ManifoldCF 0.1 went out. When do you think we should try to release ManifoldCF 0.2? Or, do you think a 0.1.1 release would be the right approach? Karl -- Grant Ingersoll http://www.lucidimagination.com
Re: Incubator PMC/Board report for March 2011 (connectors-dev@incubator.apache.org)
On Mar 1, 2011, at 11:30 AM, Karl Wright wrote: Karl, what do you think we can do to make it easier for people to get into the code? Are other people putting up patches? What's been happening is that we do indeed get code from contributors, but the contributors in question seem like they are new to open-source. I usually have to provide quite a bit of process advice, and explain the steps, and even sometimes do a chunk of the code myself. So we definitely are not at the point yet where we have knowledgeable developers contributing regularly. We should document on the wiki the steps for contributing patches, like we do for Lucene, et. al. This generally helps and gives us something to point people to in the future. Also, if we get a few patches from one or two people on a regular basis, we should look to add them as committers (discussion on specific people should be handled on the project PMC list). Also, what do people think about collapsing c-dev@ and c-user@ into just connectors-dev@? -Grant
Fwd: Google Summer of Code 2011 is almost there
Begin forwarded message: From: Ulrich Stärk u...@apache.org Date: March 8, 2011 5:41:56 PM EST To: p...@apache.org Cc: d...@community.apache.org Subject: Google Summer of Code 2011 is almost there Reply-To: priv...@mahout.apache.org Hello PMCs, Google Summer of Code is the ideal opportunity for you to attract new contributors to your projects. If you want to participate with your project you now need to - understand what it means to be a mentor [1] - propose your project ideas. Just label your issues with gsoc2011 in JIRA and they will show up at [2]. See also [1]. - subscribe to code-awa...@apache.org (restricted to mentors, meant to be used as a private list - general discussions on the public d...@community.apache.org list as much as possible please) The ASF has applied as a participating organization with GSoC, your project doesn't need to do that. See [3] for more information. Note that the ASF isn't accepted yet, nevertheless you *really* should start recording your ideas now. Last year we had 39 students completing GSoC successfully, some of which are now active contributors to the projects they worked on. Let's make this a success again this year! On behalf of the GSoC 2011 admins, Uli [1] http://community.apache.org/guide-to-being-a-mentor.html [2] http://s.apache.org/gsoc2011tasks [3] http://community.apache.org/gsoc.html -- Grant Ingersoll http://www.lucidimagination.com
Re: [VOTE] Release Apache ManifoldCF 0.2-incubating, RC2
+1 On Apr 26, 2011, at 6:12 PM, Karl Wright wrote: The RC2 of the 0.2-incubating release is now up on http://people.apache.org/~kwright. The svn tag is at https://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.2-incubating-RC2. Please vote! Karl
