Re: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread digy digy
No pre/post processing involved. They are just to see how the output of these tools looks like. DIGY On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser wrote: > > Also, was there any pre/post processing involved in these files? Was it > manual / scripts etc? Just trying to get a feel for the work

RE: Website

2011-01-02 Thread Prescott Nasser
The house CMS is brand spanking new, http://www.apache.org/dev/cms.html, and from my understanding it is what ASF would like to move everything towards. It looks flexible and easy to use, I really couldn't think of objections to using it.I actually built the skeleton files required and was hopi

Re: Proposal Stage: Documentation

2011-01-02 Thread Troy Howard
I did some learning about the details regarding project websites at the ASF. Looks like there are a number of options available. I looked over the websites for every Apache TLP and there are some basic consistencies... - Sites built with Apache Forrest (Lucene, Hadoop, WS) - Sites built with Mave

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Alex Thompson
I would lean towards open source conversion tools since having a robust one would be useful beyond Lucene. I haven't dug into the sharpen code yet to see what it would take but I could see creating our own fork of sharpen. The original conversion I did had a little pre-processing just to get aroun

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Prescott Nasser
Here is a Sharpen conversion Alex Thompson did in November: https://issues.apache.org/jira/secure/attachment/12459581/Lucene.Net.Sharpen20101114.zip >From my understanding there was no pre/post processing done. I also believe >it's 2.9.2, not 3.0.3 as Digy's are. Here is the JIRA issue for the a

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Prescott Nasser
I'm pretty sure Tangible does provide free licenses to open source projects - but they must be well and established, which I believe Lucene qualifies as. Regarding the methodology - I think based on free open source tools isn't required, as long as it's free to us, it should suit our purposes -

Re: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Troy Howard
One thing to note... Neither of those conversions create buildable code. The j2cstranslator version, for example, included Java language constructions like "import", "throws", etc.. which of course don't compile. The Tangible one has over 300 errors of various types. It's unclear how much manual

Re: Champion and Mentor

2011-01-02 Thread Troy Howard
Grant, Sounds great. We really appreciate your help! Thanks, Troy On Fri, Dec 31, 2010 at 11:50 AM, Grant Ingersoll wrote: > I'll Champion, but I don't think I will have time to mentor.  Once most of it > is fleshed out, let's ask on gene...@incubator.a.o for mentors. > > -Grant > > On Dec 30,

Re: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Troy Howard
For bug fix releases that need to come after a main release but can't increment the version number, then a build number is ok, but generally I prefer to just refer to them by name and revision number. eg: build 3.0.0.234 = 3.0.0 RTM (rev 100) build 3.0.0.446 = 3.0.0 HotFix1 (rev 123) etc... Thi

Re: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Troy Howard
I think Prescott explained it very well. I should not have specified a tool. Any tool that enables a 100% automated conversion will meet our needs. What we need is a methodology for conversion which meets these criteria: - Automated, Repeatable, and Well Documented (e.g. a script or build task wit

Re: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Michael Herndon
The complicated part about having a release for release is that there might be certain bugs that are only on our side, thus paying attention to the build interval becomes important for people. i.e. build 3.0.0.234 = 3.0.0 release build 3.0.0.446 = 3.0.0 hotfix Is there a better way of handling o

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Prescott Nasser
Also, was there any pre/post processing involved in these files? Was it manual / scripts etc? Just trying to get a feel for the work involved. > From: digyd...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: Proposal Stage: Backwards Compatibility / Support > Date: Sun, 2 Jan 20

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Prescott Nasser
I think the 100% Sharpen is more to mean, it should be 100% automatic conversion including pre/post processing scripts so that future translations can be quick, easy, and as error free as possible. If you replace 100% Sharpen with 100% Java 2 CSharp Translator I think Troy's intent stands. As f

RE: Proposal Stage: Backwards Compatibility / Support

2011-01-02 Thread Digy
> The 3.0.X ports should be 100% Sharpen Why? What about other alternatives? Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip ) DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Saturday, January 01, 2011 1

Re: Champion and Mentor

2011-01-02 Thread Grant Ingersoll
I'll Champion, but I don't think I will have time to mentor. Once most of it is fleshed out, let's ask on gene...@incubator.a.o for mentors. -Grant On Dec 30, 2010, at 6:32 PM, Troy Howard wrote: > Grant, > > I'm working on the proposal and have come to the final section where I > must list