http://permalink.gmane.org/gmane.comp.apache.commons.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.commons.general/2184 <pre>All, Over the past few weeks, our MoinMoin Wiki has increasingly become the target for spam. It turns out that the Wiki only contains a single page with content that doesn't need to be preserved: http://wiki.apache.org/axis/FrontPage?action=LocalSiteMap Also note that we own another Confluence Wiki. If there are no objections, I will request infra to shut down the MoinMoin wiki. Andreas </pre> Andreas Veithen 2013-04-20T08:16:01 http://permalink.gmane.org/gmane.comp.apache.commons.general/2180 <pre> On Apr 1, 2013, at 6:28 PM, Benson Margulies wrote: For whatever it's worth, I'd like to participate in such an effort in whatever role would be useful. I've written a thing or two, and can also assist in arranging already-written content into coherent shapes. You know, assuming Shane was mistaken. ;-) </pre> Rich Bowen 2013-04-03T13:34:53 http://permalink.gmane.org/gmane.comp.apache.commons.general/2178 <pre> Oh, drat. I was really starting to get excited about this project - having one set of documentation that explains to normal humans how we work would be amazingly cool! Then I realized what the date is, and now I know that this must really be some complex April Fool's hoax. - Shane </pre> Shane Curcuru 2013-04-02T00:56:38 http://permalink.gmane.org/gmane.comp.apache.commons.general/2175 <pre> This came up about a year ago on the IPMC and I pushed back. At the time people were calling for the IPMC to be disbanded. I brought the idea to ComDev but made it clear that I was concerned it was simply moving the problem. The ComDev PMC seemed happy to allow me to push back. I did, however, commit to revisiting this if the IPMC got its house in order. In many ways the IPMC has got its house in order. Podlings are graduating and the oversight role of the IPMC is now well managed. It's for this reason that I bring this up again. I agree (mostly) with Shane's observations below. That doesn't mean it is necessarily a good idea, but it does mean it is one worth looking at. I also agree with Martijn who said: "Because 150+ people tasked with oversight, documentation of processes and procedures of podlings, TLPs and themselves, discussing different views of the past, present and future might not be able to agree to anything, but a small team tasked with just documenting process might get the job done withou</pre> Ross Gardler 2013-04-01T22:22:55 http://permalink.gmane.org/gmane.comp.apache.commons.general/2174 <pre> If the budget is not a pre-requisite, how do envision a small PMC like ComDev, taking responsibility of a big task, that the current owner and a much larger PMC has not been able to handle ? </pre> Luciano Resende 2013-04-01T18:19:00 http://permalink.gmane.org/gmane.comp.apache.commons.general/2172 <pre> Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? </pre> Luciano Resende 2013-04-01T17:27:49 http://permalink.gmane.org/gmane.comp.apache.commons.general/2170 <pre>Hi folks We started using the default implementation of MLT (org.apache.solr.handler.MoreLikeThisHandler) recently and found that there are a couple of things it lacks: 1. Searching for terms in the same field as the original document: - the current implementation picks the top field to search an interesting term in based on docFreq, however this can give bad results if say original product is from brand:"RED Valentino", and we end up searching red in color field. 2. Phrase boosts: - if product name is "business cards", then it makes sense to give a boost to the phrase boost to products which are also business cards. 3. Support for bq, bf, fq, multiplicative boost: - you might want to filter out_of_stock products, give a multiplicative boost to a product based on their price similarity / launch date. 4. Support of explainOther We had a use case for each of these and i ended up writing my own MLTQueryParser which builds the MLT query for a g</pre> Gagandeep singh 2013-03-31T05:18:30 http://permalink.gmane.org/gmane.comp.apache.commons.general/2159 <pre> No offense taken. I think this is indeed the intention of initial and follow-up emails. There need to be a bit more coordination between the two, so BigTop's branches can be set in advance to churn stack builds and validations with underlying Hadoop RCs or even before; and Hadoop RM - and potentially downstream components - have more time to react to the problems. One of the issues here is a difference in the release schedule between the two. Perhaps we can setup a validation branch in the bigtop to help with releases. This is something that needs to be decided within the project apparently, but the it might work. Cos </pre> Konstantin Boudnik 2013-03-06T18:19:33 http://permalink.gmane.org/gmane.comp.apache.commons.general/2155 <pre>That is a great point. I have been meaning to set up the Jenkins build for branch-2 for a while, so I took the 10 mins and just did it. https://builds.apache.org/job/Hadoop-Common-2-Commit/ Don't let the name fool you, it publishes not just common, but HDFS, YARN, MR, and tools too. You should now have branch-2 SNAPSHOTS updated on each commit to branch-2. Feel free to bug me if you need more integration points. I am not an RE guy, but I can hack it to make things work :) --Bobby On 3/5/13 12:15 AM, "Konstantin Boudnik" &lt;cos-1oDqGaOF3Lkdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Evans 2013-03-05T15:18:01 http://permalink.gmane.org/gmane.comp.apache.commons.general/2153 <pre> Replies inline. As you yourself noted later, the pain is part of the 'alpha' status of the release. We are targeting one of the immediate future releases to be a beta and so these troubles are really only the short term. You should see the other discussion where we discussed about this very question of stability of our immediate future releases. I think there is a fundamental problem with the interaction of Bigtop with the downstream projects, if nothing else, with Hadoop. We never formalized on the process, will BigTop step in after an RC is up for vote or before? As I see it, it's happening after the vote is up, so no wonder we are in this state. Shall we have a pre-notice to Bigtop so that it can step in before? This is overblown, we've been working with various downstream projects - Hbase, Hive, Pig, Oozie to help them transition them to 2.x and I believe we've made significant progress already. Sure enough, there are continuing pains, but these are part of the alpha status. If we are </pre> Vinod Kumar Vavilapalli 2013-03-01T20:23:19 http://permalink.gmane.org/gmane.comp.apache.commons.general/2152 <pre>I feel this is being blown out of proportion. Integration is high on the list of *every* release. In future, if anyone or bigtop wants to help, running integration tests on a hadoop RC and providing feedback would be very welcome. I'm pretty sure I will stop an RC if it means it breaks and Oozie or HBase or Pig or Hive and re-spin it. For e.g. see recent efforts to do a 2.0.4-alpha. With hadoop-2.0.3-alpha we discovered 3 *bugs* - making it sound like we intentionally disregard integation issues is very harsh. Please also see other thread where we discussed stabilizing APIS, protocols etc. for the next 'beta' release. Arun On Feb 26, 2013, at 5:43 PM, Roman Shaposhnik wrote: </pre> Arun C Murthy 2013-03-01T18:58:39 http://permalink.gmane.org/gmane.comp.apache.commons.general/2141 <pre> My point exactly. Stop talking about "sub-projects" because the Board does not like them. Integrate Curator into Zookeeper, rather than creating an entirely separate community. I see no explanation for why Curator is/will be a separate community. All that said, if ZK feels that the direction espoused by Curator is something they do not feel is appropriate, and that they reject... then, okay. Let Curator blossom as a contrary example to ZK's clients. Cheers, -g </pre> Greg Stein 2013-02-26T07:30:58 http://permalink.gmane.org/gmane.comp.apache.commons.general/2140 <pre> The Curator library is built upon the current ZooKeeper client libraries. They are an extension that implements higher level use cases (what we call "recipes" in ZK) whereas the ZK libraries implement lower level primitives. An analogy might be Apache Crunch (recently graduated to TLP) and MapReduce. Also, not everyone agrees with Jordan's assessment that Curator is 'better" than (or a replacement for) the existing client libraries. The ZK community discussed incorporating the Curator code about a year ago. At that time there wasn't interest to adopt these libraries into ZK itself. My belief is that if Curator were to go through incubation the ZK community would be more likely to adopt it. Similar to how HCatalog spun off to work on the metastore and recently merged back into Hive. If there's significant overlap in the Curator podling community and the ZK community that will be a strong indication that they should be merged (my belief). If not it would have the opportunity to go TLP. Here's my report (Zoo</pre> Patrick Hunt 2013-02-26T06:10:36 http://permalink.gmane.org/gmane.comp.apache.commons.general/2139 <pre>My concern is that we're looking at two "new" committers, rather than a Curator community. Following normal Incubator work, Curator would build a community for itself. But then we'd have a community *distinct* from that of Zookeeper. And it really looks like this should be part of Zookeeper itself -- a more capable and easier-to-use client. So I question the incubation of this. Why do we want to build a new/separate project? Why isn't this just part of Zookeeper right from the start? I would suggest that this work is placed on a branch within Zookeeper. That Jordan and Jay become committers on that branch (not necessarily Zookeeper trunk). Over time, the branch can be folded into trunk, along with all the various tests, doc, and other artifacts that I see in the GitHub repository. And hopefully that Jordan and Jay become regular committers (and PMC members!) of the Zookeeper project itself. The current Zookeeper client can remain for backwards compat, and the Curator work can become the next-gen client. </pre> Greg Stein 2013-02-26T03:10:50 http://permalink.gmane.org/gmane.comp.apache.commons.general/2138 <pre>Sigh. No bad joke goes unpunished. That's an intentional mistake, to play off of the word 'capricious'. On Tue, Feb 19, 2013 at 10:39 AM, &lt;donald_harbison-r/Jw6+rmf7HQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: </pre> Benson Margulies 2013-02-20T03:39:55 http://permalink.gmane.org/gmane.comp.apache.commons.general/2134 <pre>Hi Benson, Looking really good! You may consider adding a flow chart/diagram showing the Incubator process but other than that, I don't have any suggestions. Wonderful! Cheers, Chris On 2/16/13 10:54 AM, "Benson Margulies" &lt;bimargulies-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Mattmann, Chris A (388J 2013-02-16T23:49:05 http://permalink.gmane.org/gmane.comp.apache.commons.general/2133 <pre>Great slides. A few comments for you to take on board or ignore at your pleasure (they are opinion not fact so you may not agree)... Slide 5: personally I avoid 'viral' and still k to 'reciprocal' no need to further alienate those who have a preference for reciprocal licences (I.e use passive rather than aggressive language). By the same token I'd say "not only about" as opposed to "not about". Personally I prefer things to be free, but I'm pragmatic and recognise that sometimes freedom will need to be compromised. Our licence is ideal for this, it provides choice and uses economics to drive freedom. Slide 9: I guess it depends on how you deliver this slide whether I agree or not. The foundation will provide any "exotic" infrastructure that can be justified. I remember telling a podling they couldn't have Git, for example. I immediately went to infra and with the support of Jukka we got permission for that podling to be the first one to adopt Git. Perhaps just add the word "unjustified", it's. Less final.</pre> Ross Gardler 2013-02-16T20:08:06 http://permalink.gmane.org/gmane.comp.apache.commons.general/2132 <pre>For gathering wide area comments, gdocs rule. On Sat, Feb 16, 2013 at 11:54 AM, Benson Margulies &lt;bimargulies-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Ted Dunning 2013-02-16T19:20:09 http://permalink.gmane.org/gmane.comp.apache.commons.general/2117 <pre> http://lucenerevolution.org/ Lucene Revolution 2013 will take place at The Westin San Diego on April 29 - May 2, 2013. Many of the brightest minds in open source search will convene at this 4th annual Lucene Revolution to discuss topics and trends driving the next generation of search. The conference will be preceded by two days of Apache Lucene, Solr and Big Data training. The event’s agenda will be comprised of Apache Lucene/Solr and Big Data tutorials and speaker sessions, creating opportunities for developers, technologists and business leaders to explore and gain deeper understandings of the technologies connected with open source search. Individuals are encouraged to submit proposals for technical talks that focus on Apache Lucene and Solr in the enterprise, Big Data, case studies, large-scale search, and data integration. Guidelines for submissions... http://lucenerevolution.org/2013/call-for-papers -Hoss</pre> Chris Hostetter 2012-12-06T18:30:33 http://permalink.gmane.org/gmane.comp.apache.commons.general/2116 <pre>Hi Guys, Same goes for Apache OODT -- I think it will be a good tie in. Cheers, Chris On Dec 3, 2012, at 8:25 AM, Suresh Marru wrote: </pre> Mattmann, Chris A (388J 2012-12-04T06:21:04 http://permalink.gmane.org/gmane.comp.apache.commons.general/2115 <pre>Hi Jim, Its great to hear you will be able me make it. I am sure NSF will greatly appreciate your perspectives. We will be happy to provide a case study from Airavata. Suresh On Dec 3, 2012, at 11:12 AM, Jim Jagielski &lt;jim-skr26eCJtH5BDgjK7y7TUQ&lt; at &gt;public.gmane.org&gt; wrote: </pre> Suresh Marru 2012-12-03T16:25:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.commons.general