Re: [VOTE] Release Lucene/Solr 3.1
: >> So I don't think this is useful: dev-tools is for developers, ... : So now its a broken build system if it DOESNT include a working : ide-configurator? This is what I meant by slippery slope We need to be clear on the scope of comments so as to reduce confusion... the "build system" (ie: ant) is currently broken, because in the solr-src packages, the top level build.xml has targets that do not work (because they expect dev-tools to exist) and these targets are explicitly mentioned in the top level README.txt that does not mean there is anything broken about the lucene-src packages. nor does it mean that we *have* to have an ide-configurator in any src package. This problem is orthoginal to the questions of: * should there be a distinct src release for just lucene-java, and should that distinct src release include an ?ide-configurator for the orthoginal questions, i'm of the opinion that there should be one src release for the entire dev tree, but that's not important right now -- what's important is that whatever we ship, should have ant targets that work; and at this stage i think we should make the minimal number of changes to the 3_1 branch (and the release process) to get artifacts where everything listed in the README.txt and "ant -p" works out of the box. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 11:15 AM, Robert Muir wrote: > On Fri, Mar 25, 2011 at 11:11 AM, Grant Ingersoll wrote: > >> No, as Hoss pointed out, it's broken now w/o the ide configurator! > > Right, but my original suggestion (include dev-tools in the solr > release, because its the whole trunk) will fix that. > Alternatively we could remove the mention of dev-tools from the > README.txt file anyway, its duplicated from HowToContribute which the > README.txt links to already. > OK. > Lucene wouldnt have any refs to dev-tools so how is it broken by not > including dev-tools? > You are correct, it is not. I was just commenting on all the artifacts. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Fri, Mar 25, 2011 at 11:11 AM, Grant Ingersoll wrote: > No, as Hoss pointed out, it's broken now w/o the ide configurator! Right, but my original suggestion (include dev-tools in the solr release, because its the whole trunk) will fix that. Alternatively we could remove the mention of dev-tools from the README.txt file anyway, its duplicated from HowToContribute which the README.txt links to already. Lucene wouldnt have any refs to dev-tools so how is it broken by not including dev-tools? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 11:07 AM, Robert Muir wrote: > On Fri, Mar 25, 2011 at 11:04 AM, Grant Ingersoll wrote: > >>> >>> So I don't think this is useful: dev-tools is for developers, >> > > So now its a broken build system if it DOESNT include a working > ide-configurator? This is what I meant by slippery slope No, as Hoss pointed out, it's broken now w/o the ide configurator! - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Fri, Mar 25, 2011 at 11:04 AM, Grant Ingersoll wrote: >> >> So I don't think this is useful: dev-tools is for developers, > So now its a broken build system if it DOESNT include a working ide-configurator? This is what I meant by slippery slope - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 10:57 AM, Robert Muir wrote: >> > > This is becoming a slippery slope fast... Uwe's perspective is > starting to become much more attractive. And what is that? I've yet to see it written down.
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 10:57 AM, Robert Muir wrote: > On Fri, Mar 25, 2011 at 10:45 AM, Grant Ingersoll wrote: > >> I do think we need standalone artifacts. So, I suppose if we do that, then >> we can't just svn export, b/c we would need to separate dev tools per >> project. But, then again, why can't we have: >> /dev-tools/ >> /lucene/dev-tools >> /solr/dev-tools >> >> The top level just creates IDE that includes the lower ones, but the lower >> ones can each be standalone. (This goes for the Maven stuff too). >> >> I realize, of course, this is work, so my suggestion would be we do 3.1 w/ >> it included as is and then fix in the next release. >> > > I would be against this. currently to fix eclipse i just copy the > .classpath file to /dev-tools/eclipse/dot.classpath and commit. This > makes it significantly harder. > Additionally I don't see how this could possibly work: a "standalone" > solr would use lucene jar files since it doesnt include the lucene > source. > Because of this, a "top-level" dev-tools eclipse configuration would > not be the composition of lucene+solr, instead it would be a totally > different thing. Solr would just include the whole tree. Lucene could then just deliver Lucene. > > So I don't think this is useful: dev-tools is for developers, Right. People who take the source are developers, no? As it is now, we ship them a broken build system. > and > developers are all using the big /trunk checkout, so we don't need > dev-tools at a lower level, for no good reason. > > Honestly I could care less about making it easy for someone to > configure lucene or solr by itself in their IDE. I did the eclipse > work (for example) to make it easier for people to contribute to > lucene/solr, I could care less about making it easier for people to > configure their "own private copies" of lucene or solr easier, and I'm > definitely not going to let it make it *harder* on us to support > contributions (the top-level /dev-tools). > Yes, but isn't the way people start making contributions at first by taking the source from a release and working on it?Isn't that the point of the src release? (Other than the ASF requires it) > This is becoming a slippery slope fast... Uwe's perspective is > starting to become much more attractive. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Fri, Mar 25, 2011 at 10:45 AM, Grant Ingersoll wrote: > I do think we need standalone artifacts. So, I suppose if we do that, then > we can't just svn export, b/c we would need to separate dev tools per > project. But, then again, why can't we have: > /dev-tools/ > /lucene/dev-tools > /solr/dev-tools > > The top level just creates IDE that includes the lower ones, but the lower > ones can each be standalone. (This goes for the Maven stuff too). > > I realize, of course, this is work, so my suggestion would be we do 3.1 w/ it > included as is and then fix in the next release. > I would be against this. currently to fix eclipse i just copy the .classpath file to /dev-tools/eclipse/dot.classpath and commit. This makes it significantly harder. Additionally I don't see how this could possibly work: a "standalone" solr would use lucene jar files since it doesnt include the lucene source. Because of this, a "top-level" dev-tools eclipse configuration would not be the composition of lucene+solr, instead it would be a totally different thing. So I don't think this is useful: dev-tools is for developers, and developers are all using the big /trunk checkout, so we don't need dev-tools at a lower level, for no good reason. Honestly I could care less about making it easy for someone to configure lucene or solr by itself in their IDE. I did the eclipse work (for example) to make it easier for people to contribute to lucene/solr, I could care less about making it easier for people to configure their "own private copies" of lucene or solr easier, and I'm definitely not going to let it make it *harder* on us to support contributions (the top-level /dev-tools). This is becoming a slippery slope fast... Uwe's perspective is starting to become much more attractive. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 10:27 AM, Robert Muir wrote: > On Fri, Mar 25, 2011 at 10:18 AM, Mark Miller wrote: >> Well, actually I think we should just make it completely unsupported. These >> are our dev tools - don't count on them for crap. No reason to exclude them >> from the src IMO. >> > > For the solr release, I think I could be ok with that (my concerns are > more that later someone will say, how did this eclipse stuff etc slip > into the release?). I know some people hesitated to add support for > IDEs for this reason, I was for it as I want to make contributions > easier, but I don't want us to look at it as making releasing harder. > +1 > For the lucene release, I'm definitely against it: nothing in there > will work at all because the lucene release doesn't include the solr > bits. I know its been mentioned in this thread that maybe we should > look at a single source artifact for everything, I don't think we > should do this either. I do think we need standalone artifacts. So, I suppose if we do that, then we can't just svn export, b/c we would need to separate dev tools per project. But, then again, why can't we have: /dev-tools/ /lucene/dev-tools /solr/dev-tools The top level just creates IDE that includes the lower ones, but the lower ones can each be standalone. (This goes for the Maven stuff too). I realize, of course, this is work, so my suggestion would be we do 3.1 w/ it included as is and then fix in the next release. > > I think its important that lucene stays a standalone search engine > library from the artifact point of view, even if our development is in > sync with solr. > I agree. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 24, 2011, at 5:27 PM, Uwe Schindler wrote: > OK, let's vote. My vote: -1 Care to say why? Standard practice for a -1 is to say why you don't want it so that it might be possible to address the concerns you have. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Fri, Mar 25, 2011 at 10:18 AM, Mark Miller wrote: > Well, actually I think we should just make it completely unsupported. These > are our dev tools - don't count on them for crap. No reason to exclude them > from the src IMO. > For the solr release, I think I could be ok with that (my concerns are more that later someone will say, how did this eclipse stuff etc slip into the release?). I know some people hesitated to add support for IDEs for this reason, I was for it as I want to make contributions easier, but I don't want us to look at it as making releasing harder. For the lucene release, I'm definitely against it: nothing in there will work at all because the lucene release doesn't include the solr bits. I know its been mentioned in this thread that maybe we should look at a single source artifact for everything, I don't think we should do this either. I think its important that lucene stays a standalone search engine library from the artifact point of view, even if our development is in sync with solr. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 10:16 AM, Mark Miller wrote: > > On Mar 25, 2011, at 8:22 AM, Grant Ingersoll wrote: > >> Mine is +1 as long as we mark it as experimental. > > +1 > Well, actually I think we should just make it completely unsupported. These are our dev tools - don't count on them for crap. No reason to exclude them from the src IMO. - Mark Miller lucidimagination.com Lucene/Solr User Conference May 25-26, San Francisco www.lucenerevolution.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 25, 2011, at 8:22 AM, Grant Ingersoll wrote: > Mine is +1 as long as we mark it as experimental. +1 - Mark Miller lucidimagination.com Lucene/Solr User Conference May 25-26, San Francisco www.lucenerevolution.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 24, 2011, at 5:27 PM, Uwe Schindler wrote: > OK, let's vote. My vote: -1 Mine is +1 as long as we mark it as experimental. > > If we resping, can we commit the last changes from branch 3.x that are bugs? I would think so. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -Original Message- >> From: Grant Ingersoll [mailto:gsing...@apache.org] >> Sent: Thursday, March 24, 2011 10:09 PM >> To: dev@lucene.apache.org >> Subject: Re: [VOTE] Release Lucene/Solr 3.1 >> >> So, my sense is here that we should fix these minor documentation issues >> and decide on dev-tools and spin a new RC and get this sucker out the > door. >> I think I have some time tomorrow, I can generate the artifacts. >> >> Shall we vote on inclusion of dev-tools? >> >> -Grant >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem docs using Solr/Lucene: http://www.lucidimagination.com/search - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 3.1
OK, let's vote. My vote: -1 If we resping, can we commit the last changes from branch 3.x that are bugs? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Grant Ingersoll [mailto:gsing...@apache.org] > Sent: Thursday, March 24, 2011 10:09 PM > To: dev@lucene.apache.org > Subject: Re: [VOTE] Release Lucene/Solr 3.1 > > So, my sense is here that we should fix these minor documentation issues > and decide on dev-tools and spin a new RC and get this sucker out the door. > I think I have some time tomorrow, I can generate the artifacts. > > Shall we vote on inclusion of dev-tools? > > -Grant > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
So, my sense is here that we should fix these minor documentation issues and decide on dev-tools and spin a new RC and get this sucker out the door. I think I have some time tomorrow, I can generate the artifacts. Shall we vote on inclusion of dev-tools? -Grant - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Mar 23, 2011, at 6:14 PM, Chris Hostetter wrote: > > : Please vote to release the artifacts at > : http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 > > -0 > > I can't in good conscience vote for these artifacts. > > For the most part, there only only a few minor hicups -- but the big > blocker (in my opinion) is that since RC1, dev-tools has been removed from > the solr src packages and this causes the top level build.xml (and > instructions for IDE users in the top level README.txt file) to be broken. > > My detailed notes below... > > ## > ### apache-solr-3.1.0-src.tgz > > dev-tools isn't in here -- this totally boggles my mind, particularly > since there was a deliberate and concious switch to make the source > releases match what you get when doing an "svn export" > > because dev-tools is missing, 3 of the top level ant targets advertised > using "ant -p" don't work; including 'ant idea' and 'ant eclipse' which > are also explicitly mentioned in the top level README.txt as how people > using those IDEs should get started developing the code. > > This seems like a major issue to me. Yeah, I really don't get why we can't include them either in the source release. > > we're setting ourselves up to make the release look completely broken > right out of the gate for anyone using one of those IDEs. > > Ask about this on IRC. yonik & ryan indicated that a couple of folks had > said they would veto any release with dev-tools in it because that stuff > is suppose to be "unsupported" ... this makes no sense to me as we have > lots of places in the code base where things are documented as being > experimental, subject to change, and/or for developer use only. i don't > relaly see how dev-tools should be any different. > > if there is really such violent oposition to including dev-tools in src > releases, then the top level build.xml should not depend on it, and the > top level README.txt should not refer to it (except maybe with something > like "people interested in hacking on the src should use svn which > includes some unofficial 'dev-tools'" > --- > > Now that the src packages are driven by svn exports, more files exist then > were in RC1 and some of the changes we made to the solr/README.txt based > on the earlier release candidates are missleading. > > In particular a lot of things are listed as being in the "docs" directory > of a binary distribution, but those files *do* exist in the src packages > -- if you look in the "site" directory. This seems silly, but at no point > is the README.txt factually incorrect, so I guess it's not a big enough > deal to worry about. > > --- > > running all tests, running the example, and building the javadocs all > worked fine. > > ## > ### apache-solr-3.1.0.tgz > > docs look good, basic example usage works fine. > > ## > ### apache-solr-3.1.0.zip > > Diffing the contents of apache-solr-3.1.0.tgz with apache-solr-3.1.0.zip > (using "diff --ignore-all-space --strip-trailing-cr -r") turned up a quite > a fiew instances where the CRLF fixing in build.xml seems to have > corrupted some non-ascii characters in a few files > > contrib/dataimporthandler/lib/activation-LICENSE.txt > contrib/dataimporthandler/lib/mail-LICENSE.txt > docs/skin/CommonMessages_de.xml > docs/skin/CommonMessages_es.xml > docs/skin/CommonMessages_fr.xml > example/solr/conf/velocity/facet_dates.vm > > ...but these changes don't seem to have substantively harmed the files. > > ## > ### lucene-3.1.0-src.tar.gz > > tests and javadocs worked fine. > > ## > ### lucene-3.1.0.tar.gz > > docs look good, demo runs fine. > > ## > ### lucene-3.1.0.zip > > no differences found with lucene-3.1.0.tar.gz > > > > > > -Hoss > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Grant Ingersoll http://www.lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
> > I don't think someone should have to deal with maven to get the lucene > source release... I think lucene should have its own artifacts as in > the past (the source code being the most important). > sorry, did not mean to muddy the water with maven discussion... ignore my comment when you say "lucene should have its own artifacts" do you mean lucene w/o solr? or could a single source artifact include everything? (making the release process easier and apparently cleaner) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
On Thu, Mar 24, 2011 at 12:18 AM, Ryan McKinley wrote: > > I don't want to suggest anything to slow down the release... but if > the problems are with the source release, what about just doing a > single source release for lucene+solr? > > We currently have: > > lucene-solr-3.1RC2/lucene/ > lucene-solr-3.1RC2/lucene/lucene-3.1.0-src.tar.gz > lucene-solr-3.1RC2/lucene/... > lucene-solr-3.1RC2/solr/ > lucene-solr-3.1RC2/solr/apache-solr-3.1.0-src.tgz > lucene-solr-3.1RC2/solr/... > > Why not: > lucene-solr-3.1RC2/lucene-3.1.0-src.tar.gz > lucene-solr-3.1RC2/lucene/... > lucene-solr-3.1RC2/solr/... > > and let the src release be as close to svn export as possible? This > will make sure the result builds just as it does when we actually > build it! > > With the maven artifacts, we have source for each jar: > http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2/solr/maven/org/apache/solr/solr-core/3.1.0/solr-core-3.1.0-sources.jar > > http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2/lucene/maven/org/apache/lucene/lucene-queries/3.1.0/lucene-queries-3.1.0-sources.jar > > I'm not sure the exact ASF source requirements, but maybe the maven > source.jar files are good enough? > I don't think someone should have to deal with maven to get the lucene source release... I think lucene should have its own artifacts as in the past (the source code being the most important). - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
> > : Please vote to release the artifacts at > : http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 > > -0 > > I can't in good conscience vote for these artifacts. > I don't want to suggest anything to slow down the release... but if the problems are with the source release, what about just doing a single source release for lucene+solr? We currently have: lucene-solr-3.1RC2/lucene/ lucene-solr-3.1RC2/lucene/lucene-3.1.0-src.tar.gz lucene-solr-3.1RC2/lucene/... lucene-solr-3.1RC2/solr/ lucene-solr-3.1RC2/solr/apache-solr-3.1.0-src.tgz lucene-solr-3.1RC2/solr/... Why not: lucene-solr-3.1RC2/lucene-3.1.0-src.tar.gz lucene-solr-3.1RC2/lucene/... lucene-solr-3.1RC2/solr/... and let the src release be as close to svn export as possible? This will make sure the result builds just as it does when we actually build it! With the maven artifacts, we have source for each jar: http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2/solr/maven/org/apache/solr/solr-core/3.1.0/solr-core-3.1.0-sources.jar http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2/lucene/maven/org/apache/lucene/lucene-queries/3.1.0/lucene-queries-3.1.0-sources.jar I'm not sure the exact ASF source requirements, but maybe the maven source.jar files are good enough? Again, I don't think this should be a blocker, but it would be nice to have things simplified for the next release -- gasp. ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
: Please vote to release the artifacts at : http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 -0 I can't in good conscience vote for these artifacts. For the most part, there only only a few minor hicups -- but the big blocker (in my opinion) is that since RC1, dev-tools has been removed from the solr src packages and this causes the top level build.xml (and instructions for IDE users in the top level README.txt file) to be broken. My detailed notes below... ## ### apache-solr-3.1.0-src.tgz dev-tools isn't in here -- this totally boggles my mind, particularly since there was a deliberate and concious switch to make the source releases match what you get when doing an "svn export" because dev-tools is missing, 3 of the top level ant targets advertised using "ant -p" don't work; including 'ant idea' and 'ant eclipse' which are also explicitly mentioned in the top level README.txt as how people using those IDEs should get started developing the code. This seems like a major issue to me. we're setting ourselves up to make the release look completely broken right out of the gate for anyone using one of those IDEs. Ask about this on IRC. yonik & ryan indicated that a couple of folks had said they would veto any release with dev-tools in it because that stuff is suppose to be "unsupported" ... this makes no sense to me as we have lots of places in the code base where things are documented as being experimental, subject to change, and/or for developer use only. i don't relaly see how dev-tools should be any different. if there is really such violent oposition to including dev-tools in src releases, then the top level build.xml should not depend on it, and the top level README.txt should not refer to it (except maybe with something like "people interested in hacking on the src should use svn which includes some unofficial 'dev-tools'" --- Now that the src packages are driven by svn exports, more files exist then were in RC1 and some of the changes we made to the solr/README.txt based on the earlier release candidates are missleading. In particular a lot of things are listed as being in the "docs" directory of a binary distribution, but those files *do* exist in the src packages -- if you look in the "site" directory. This seems silly, but at no point is the README.txt factually incorrect, so I guess it's not a big enough deal to worry about. --- running all tests, running the example, and building the javadocs all worked fine. ## ### apache-solr-3.1.0.tgz docs look good, basic example usage works fine. ## ### apache-solr-3.1.0.zip Diffing the contents of apache-solr-3.1.0.tgz with apache-solr-3.1.0.zip (using "diff --ignore-all-space --strip-trailing-cr -r") turned up a quite a fiew instances where the CRLF fixing in build.xml seems to have corrupted some non-ascii characters in a few files contrib/dataimporthandler/lib/activation-LICENSE.txt contrib/dataimporthandler/lib/mail-LICENSE.txt docs/skin/CommonMessages_de.xml docs/skin/CommonMessages_es.xml docs/skin/CommonMessages_fr.xml example/solr/conf/velocity/facet_dates.vm ...but these changes don't seem to have substantively harmed the files. ## ### lucene-3.1.0-src.tar.gz tests and javadocs worked fine. ## ### lucene-3.1.0.tar.gz docs look good, demo runs fine. ## ### lucene-3.1.0.zip no differences found with lucene-3.1.0.tar.gz -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
+1 * Ran Solr example * Perused entire structure of both binary and source distros Noticed the minor issues others have reported, to echo Ryan, none seem like blockers to me. And also to echo Ryan's thanks huge thanks to everyone's hard work on the 3.1 Lucene/Solr release(s). This is a big milestone for the technology and community. Erik On Mar 22, 2011, at 23:42 , Ryan McKinley wrote: > +1 > > * Walked through the solr example > * Tested a simple maven project, worked well > > I don't think the minor issues listed so far are blockers > > Thanks to everyone who worked on this! > > ryan > > > On Tue, Mar 22, 2011 at 10:21 AM, Yonik Seeley > wrote: >> Please vote to release the artifacts at >> http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 >> as Lucene 3.1 and Solr 3.1 >> >> Thanks for everyone's help pulling all this together! >> >> -Yonik >> http://www.lucenerevolution.org -- Lucene/Solr User Conference, May >> 25-26, San Francisco >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
+1 * Walked through the solr example * Tested a simple maven project, worked well I don't think the minor issues listed so far are blockers Thanks to everyone who worked on this! ryan On Tue, Mar 22, 2011 at 10:21 AM, Yonik Seeley wrote: > Please vote to release the artifacts at > http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 > as Lucene 3.1 and Solr 3.1 > > Thanks for everyone's help pulling all this together! > > -Yonik > http://www.lucenerevolution.org -- Lucene/Solr User Conference, May > 25-26, San Francisco > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
Overall, things look good to me. As discussed on IRC, one minor nit: 1. In the source bundle, the Changes.html is missing and so index.html has dead links. I know Changes.html is generated. We could just hook this into the svn export target and then I think the docs would be whole. I guess I'd say +1 at this point. Sigs look good, examples look good for both Solr and Lucene. Maven artifacts look reasonable at a glance. -Grant On Mar 22, 2011, at 10:21 AM, Yonik Seeley wrote: > Please vote to release the artifacts at > http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 > as Lucene 3.1 and Solr 3.1 > > Thanks for everyone's help pulling all this together! > > -Yonik > http://www.lucenerevolution.org -- Lucene/Solr User Conference, May > 25-26, San Francisco > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.1
Don't know how important this is, but: 1) I've just tried following the instructions from example/README.txt, under cygwin curl is not installed by default and post.sh assumes it is always available, resulting command-not-found ugliness. 2) example/solr/conf/solrconfig.xml states that:\ Not true, all the required JARs are included. None are blockers, I will fix #2 in the trunk, let me know if this should also be applied to the 3.x branch. Dawid On Tue, Mar 22, 2011 at 3:21 PM, Yonik Seeley wrote: > Please vote to release the artifacts at > http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 > as Lucene 3.1 and Solr 3.1 > > Thanks for everyone's help pulling all this together! > > -Yonik > http://www.lucenerevolution.org -- Lucene/Solr User Conference, May > 25-26, San Francisco > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 3.1
I found a few documentation issues in the binary Lucene .zip (these are not
blockers, IMHO):
Lucene binary .zip
--
A. README.txt:
1. "contrib/demo/lucene-demos-XX.jar"
("demos" should be "demo")
2. "See BUILD.txt for building a source distribution"
(there is no such file in the binary distribution)
3. No mention of the included test jar: lucene-core-3.1.0-tests.jar
4. No mention of the javadoc jars (one for the test jar, one for core jar)
B. Javadoc:
The Test Framework API home page is the same as the root home page.
(At a minimum, it should be blank, but better would be a
description of the test framework.)
Steve
> -Original Message-
> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Tuesday, March 22, 2011 10:21 AM
> To: dev@lucene.apache.org
> Subject: [VOTE] Release Lucene/Solr 3.1
>
> Please vote to release the artifacts at
> http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2
> as Lucene 3.1 and Solr 3.1
>
> Thanks for everyone's help pulling all this together!
>
> -Yonik
> http://www.lucenerevolution.org -- Lucene/Solr User Conference, May
> 25-26, San Francisco
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 3.1
Please vote to release the artifacts at http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2 as Lucene 3.1 and Solr 3.1 Thanks for everyone's help pulling all this together! -Yonik http://www.lucenerevolution.org -- Lucene/Solr User Conference, May 25-26, San Francisco - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
