Re: Lucene Solr 3.1 RC1
On Thu, 17 Mar 2011 23:36 -0400, Mark Miller markrmil...@gmail.com wrote: On Mar 17, 2011, at 11:13 PM, Chris Hostetter wrote: patches welcome! Sometimes you have to slash and burn to clean out the old under brush. My patch would simply excise forrest and the website. Then, reveling in the success of that great improvement, I'd sit back, take stalk and see what came along. But it looks like others are winding along on another track - so I'm happy to let them go about it and see where we land. Apache's home brew CMS scares me until proven otherwise. I hope to get to use the homebrew CMS soon. My impression from watching folks use it is that, while the (internal) interface isn't pretty, it simply does the job. That is, once people start using it, I don't hear any complaints. And for a relatively new piece of software, that strikes me as a success. Upayavira --- Enterprise Search Consultant at Sourcesense UK, Making Sense of Open Source - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 7:09 PM, Chris Hostetter hossman_luc...@fucit.org wrote: Lucene Artifacts... * ant javadocs fails because javadocs-all can't find prettify... BUILD FAILED /home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/lucene-3.1.0/build.xml:206: The following error occurred while executing this line: /home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/lucene-3.1.0/common-build.xml:744: /home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/dev-tools/prettify not found. ...this seems like a pretty fundemental problem since the lucene-src release doesn't include dev-tools at all (it's one level higher then what we package) We gotta figure out how to deal with this one, I don't like that the lucene build from the source release is broken. we can't let the official build depend on dev-tools. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Lucene Solr 3.1 RC1
On 3/18/2011 at 7:37 AM, Robert Muir wrote: I don't like that the lucene build from the source release is broken. https://issues.apache.org/jira/browse/LUCENE-2973 fixes it by including dev-tools (and everything else except solr/) we can't let the official build depend on dev-tools. Why not?
Re: Lucene Solr 3.1 RC1
On Fri, Mar 18, 2011 at 8:50 AM, Steven A Rowe sar...@syr.edu wrote: On 3/18/2011 at 7:37 AM, Robert Muir wrote: I don't like that the lucene build from the source release is broken. https://issues.apache.org/jira/browse/LUCENE-2973 fixes it by including dev-tools (and everything else except solr/) we can't let the official build depend on dev-tools. Why not? because the whole point of dev-tools is to be optionally maintained/as-is stuff for developers (e.g. IDE configuration files). if the stuff stops being maintained, the build continues to work. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Mar 17, 2011, at 11:36 PM, Mark Miller wrote: On Mar 17, 2011, at 11:13 PM, Chris Hostetter wrote: patches welcome! Sometimes you have to slash and burn to clean out the old under brush. My patch would simply excise forrest and the website. Then, reveling in the success of that great improvement, I'd sit back, take stalk and see what came along. But it looks like others are winding along on another track - so I'm happy to let them go about it and see where we land. Apache's home brew CMS scares me until proven otherwise. Nah, it's actually pretty nice. Dead simple: Markdown + SVN + some webbased management. We use it for OpenNLP. I have started the process of converting us, but need time to get Forrest's XDOC to Markdown figured out. From there, I want to move all the sites (Lucene, Solr, Open Rel and PyLucene) onto it and out into a single SVN tree structure separate from the dev trees. I've already scoped that part out. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Mar 17, 2011, at 11:05 PM, Chris Hostetter wrote: : The source is because I *think* we are required by the ASF to have yes. we are. Two thoughts on src distribution: Linux distributions, such as RedHat Debian, have a policy of building from pristine source. They want the official source for a release. For them it needs to be build-able. They don't redistribute the official bin jars. For my product usage, I grab the official bin jars and in order to use it easily use them for development within Eclipse, tie it to the src.zip(s). It is a tremendous help for that fully vetted and match the bin. I don't need it to be build-able or have resources, just the code. -- DM - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Mar 18, 2011, at 10:00 AM, DM Smith wrote: On Mar 17, 2011, at 11:05 PM, Chris Hostetter wrote: : The source is because I *think* we are required by the ASF to have yes. we are. Two thoughts on src distribution: Linux distributions, such as RedHat Debian, have a policy of building from pristine source. They want the official source for a release. For them it needs to be build-able. They don't redistribute the official bin jars. For my product usage, I grab the official bin jars and in order to use it easily use them for development within Eclipse, tie it to the src.zip(s). It is a tremendous help for that fully vetted and match the bin. I don't need it to be build-able or have resources, just the code. -- DM FYI, FWIW: Apache does require that we distrib the src and that it's buildable. - 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: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 7:09 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : I spent this morning reviewing the Solr tgz artifacts (will look at hte : lucene ones after lunch). Notes so far... Lucene Artifacts... # General concerns As mentioned before, there are a bunch of files only included in the src release that seem suspicious -- they should probably also be included in the binary release... contrib/analyzers/common: README.txt contrib/analyzers/common: SNOWBALL-LICENSE.txt contrib/benchmark: conf contrib/benchmark: scripts contrib/lucli: run.sh contrib/swing: docs contrib/xml-query-parser: docs contrib/xml-query-parser: LuceneContribQuery.dtd contrib/xml-query-parser: LuceneCoreQuery.dtd OK, these should be fixed now (except for the SNOWBALL-LICENSE.txt which should already be covered in our main NOTICE/LICENSE.) -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
Re: Lucene Solr 3.1 RC1
: We gotta figure out how to deal with this one, I don't like that the : lucene build from the source release is broken. At hte risk of sounding like a broken record: this type of problem would go away if we only had one source release, rooted at dev -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, 17 Mar 2011, Yonik Seeley wrote: : Date: Thu, 17 Mar 2011 23:36:33 -0400 : From: Yonik Seeley yo...@lucidimagination.com : To: Chris Hostetter hossman_luc...@fucit.org : Cc: Lucene Dev dev@lucene.apache.org : Subject: Re: Lucene Solr 3.1 RC1 : : On Thu, Mar 17, 2011 at 11:18 PM, Chris Hostetter : hossman_luc...@fucit.org wrote: : : : A 1.4.2 release in development, yes. That's the earliest point that : : the bug was fixed, and someone : : upgrading from 1.4.1 should look at everything after the 1.4.1 release. : : that makes no sense to me. even if a 1.4.2 release is going ot exist at : some hypothetical point in the future, it doesn't exist *now* when the 3.1 : release is coming out. CHANGES.txt should only list real changes since : real releases. : : All of the things listed in the 1.4.2-dev section have actually been fixed : in the the 3.1 branch as well -- in fact, most of them (all but one i : think) are double listed in the 3.1 bug section of the CHANGES.txt : : We can't predict the future -- we don't know what else might get : included in a hypotheetical 1.4.2 release, so we're better off listing : nothing, then listing something that might be wrong. : : But it's listed as 1.4.2-dev (in development). : I'm not sure exactly what you have in mind, but feel free to fix it.. : it's a really minor issue to me. Committed revision 1083014. Committed revision 1083015. : I sort of adopted the lucene convention of how to deal with 3x and trunk. : If you fix something in trunk and are going to immediately merge back : to 3x, you put it in the 3x section of CHANGES in trunk and then merge : back. ...and that still makes no sense to me ... 3.x and 4.x releases are not going to be sequential, successor releases along a single branch of code in the same way that 2.4 was a successor to 2.3. a bug fix on the trunk is a differnet fix then a bug fic on the 3x branch, and they should be tracked accordingly. If a bug was fixed on trunk in time for 4.0, and also merged to the 3x branch in time for 3.2, and a user upgrades directly from 3.1 to 4.2, we're doing them a disservice if that bug fix is only listed in the 3.2 section of CHANGES.txt, because it implies that the fix in 3.2 is the fix they are getting, but it's not, they are not on a completley differnet code path (trunk), that may have been widely divergent from the 3x code at the time the bug fix was merged. Liwise: if we continue to have active bugfix release on the 3x branch while moving forward with 4x feature releases, the entire model of only list it in the section of earliest version it was backported to completley breaks down. a user upgrading from 4.1 to 4.2 should be able to look at the CHANGES section for 4.2 and know about ever change that was made -- they shouldn't have to guess that some changes aren't listed becuase they were backported to a 3.x.y bug fix that happened the same week. : Personally, I think it might be easiest to keep two files in trunk: : CHANGES_40 and CHANGES. : CHANGES would always be identical to 3x, and you would update that if : you were going to merge back to 3x. : When it's time for release, CHANGES_40 and CHANGES could be put together. why bother trying to track the stuff in two places? ... when 3.1 comes out we can completley blow away the 3.1 section of CHANGES.txt on trunk and cut/paste the whole thing in from the official release. the simplest solution is still to just commit to the top of CHANGES.txt on the branh where you commit the fix -- if you merge the fix to another branch, merge the CHANGES.txt entry too. then the CHANGES.txt of every release tracks exactly what changed on that code branch. I see no particular value in having the CHANGES.txt distributed with a rleeasee contain a historical archive of every CHANGE ever made in ever release, but if people really want that it can be solved by a copy/paste to all of the other active branches at the time of release. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
FYI, the placeholder for the CMS site is: http://svn.apache.org/repos/asf/lucene/cms/ You can simply check in there and you will see updates in the staging area. On Mar 18, 2011, at 5:47 AM, Upayavira wrote: On Thu, 17 Mar 2011 23:36 -0400, Mark Miller markrmil...@gmail.com wrote: On Mar 17, 2011, at 11:13 PM, Chris Hostetter wrote: patches welcome! Sometimes you have to slash and burn to clean out the old under brush. My patch would simply excise forrest and the website. Then, reveling in the success of that great improvement, I'd sit back, take stalk and see what came along. But it looks like others are winding along on another track - so I'm happy to let them go about it and see where we land. Apache's home brew CMS scares me until proven otherwise. I hope to get to use the homebrew CMS soon. My impression from watching folks use it is that, while the (internal) interface isn't pretty, it simply does the job. That is, once people start using it, I don't hear any complaints. And for a relatively new piece of software, that strikes me as a success. Upayavira --- Enterprise Search Consultant at Sourcesense UK, Making Sense of Open Source - 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: Lucene Solr 3.1 RC1
: This is just to make it easier for everyone to review the current : state of the packages (there were a lot of minor fixups since RC0) : and identify any other blockers. I spent this morning reviewing the Solr tgz artifacts (will look at hte lucene ones after lunch). Notes so far... Solr Artifacts... # General concerns As mentioned before, the following jars are not identical between the bin and src releases, I'm not sure if that's just becuase yonik didn't build them at the exact same time, or if we have a glitch in our build.xml that is modifying these files when it shouldn't be... contrib/analysis-extras/lucene-libs/lucene-icu-3.1.0.jar contrib/analysis-extras/lucene-libs/lucene-smartcn-3.1.0.jar contrib/analysis-extras/lucene-libs/lucene-stempel-3.1.0.jar example/exampledocs/post.jar ...using jarc to poke arround in post.jar the specific change seems to have been the Created-By variable in the manifest... lt; Created-By: 19.1-b02 (Sun Microsystems Inc.) --- gt; Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) I'm not entirely sure why the other three jars are included in the src release at all ... contrib/analysis-extras/lucene-libs gets removed by ant clean, and the jars are rebuilt as part of the build process, so shouldn't they be excluded from the src artifacts? ## src-tgz Things I tested that worked great... * Building the example * Running the main example * Running the DIH examples Problems I noticed... * nothing in README or ant -p about how to build the non-javadocs (ie: tutorial) * while in the solr directory ant javadoc produced this warning... [javadoc] /home/hossman/tmp/lucene3.1rc/3.1.rc1/s-src-tgz/apache-solr-3.1.0/solr/src/java/org/apache/solr/schema/IndexSchema.java:105: warning - Tag @link: can't find IndexSchema(SolrConfig, String, InputStream) in org.apache.solr.schema.IndexSchema * after that warning ant javadoc (in solr dir) failed with DocletAbortException ... [javadoc] javadoc: error - java.io.FileNotFoundException: /home/hossman/tmp/lucene3.1rc/3.1.rc1/s-src-tgz/apache-solr-3.1.0/solr/build/docs/api/solr/prettify/stylesheet+prettify.css (No such file or directory) encountered while [javadoc] performing copy. * CHANGES.txt says we are using Tika 0.8-SNAPSHOT and UIMA 2.3.1-SNAPSHOT, but when i look at the actual jars there is no indication that these are snapshots... * CHANGES.txt has a 1.4.2-dev section listing bug fixes ... as if that were a release after 1.4.1 and before the current 3.1 release. ## bin-tgz Things I tested that worked great... * Reading the docs and javadocs * Running the main example * Running the DIH examples Problems I noticed... * tutorial still indicates it's about a non released version ... as i mentioned to yonik on irc, i think we should just rip these forrest variables out completley. they've always been finicy to get just right in a release. * ditto comments about CHANGES.txt from src artifact -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Mar 17, 2011, at 3:53 PM, Chris Hostetter wrote: * CHANGES.txt says we are using Tika 0.8-SNAPSHOT and UIMA 2.3.1-SNAPSHOT, but when i look at the actual jars there is no indication that these are snapshots... It should be TIKA-0.8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 3:53 PM, Chris Hostetter hossman_luc...@fucit.org wrote: [javadoc] /home/hossman/tmp/lucene3.1rc/3.1.rc1/s-src-tgz/apache-solr-3.1.0/solr/src/java/org/apache/solr/schema/IndexSchema.java:105: warning - Tag @link: can't find IndexSchema(SolrConfig, String, InputStream) in org.apache.solr.schema.IndexSchema * after that warning ant javadoc (in solr dir) failed with DocletAbortException ... Good catch on this one - dev-tools was missing a lot of files. I think I've fixed it. -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Wed, Mar 16, 2011 at 10:13 PM, Chris Hostetter hossman_luc...@fucit.org wrote: %% diff -r s-bin-tgz/apache-solr-3.1.0/ s-src-tgz/apache-solr-3.1.0/solr/ Binary files s-bin-tgz/apache-solr-3.1.0/contrib/analysis-extras/lucene-libs/lucene-icu-3.1.0.jar and s-src-tgz/apache-solr-3.1.0/solr/contrib/analysis-extras/lucene-libs/lucene-icu-3.1.0.jar differ Binary files s-bin-tgz/apache-solr-3.1.0/contrib/analysis-extras/lucene-libs/lucene-smartcn-3.1.0.jar and s-src-tgz/apache-solr-3.1.0/solr/contrib/analysis-extras/lucene-libs/lucene-smartcn-3.1.0.jar differ Binary files s-bin-tgz/apache-solr-3.1.0/contrib/analysis-extras/lucene-libs/lucene-stempel-3.1.0.jar and s-src-tgz/apache-solr-3.1.0/solr/contrib/analysis-extras/lucene-libs/lucene-stempel-3.1.0.jar differ ... Binary files s-bin-tgz/apache-solr-3.1.0/example/exampledocs/post.jar and s-src-tgz/apache-solr-3.1.0/solr/example/exampledocs/post.jar differ OK, I've excluded these jars from the source release. Man... it would be so much easier (and less error prone) to just do the source release manually... svn export ... tar cvzf ... -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
: I spent this morning reviewing the Solr tgz artifacts (will look at hte
: lucene ones after lunch). Notes so far...
Lucene Artifacts...
# General concerns
As mentioned before, there are a bunch of files only included in the src
release that seem suspicious -- they should probably also be included in
the binary release...
contrib/analyzers/common: README.txt
contrib/analyzers/common: SNOWBALL-LICENSE.txt
contrib/benchmark: conf
contrib/benchmark: scripts
contrib/lucli: run.sh
contrib/swing: docs
contrib/xml-query-parser: docs
contrib/xml-query-parser: LuceneContribQuery.dtd
contrib/xml-query-parser: LuceneCoreQuery.dtd
## src-tgz
Things I tested that worked great...
* compiled and ran all tests using java 1.5
* ran ant to build the core jar
* ran ant build-contrib to build the contrib jars
* ran the demo to index/search lucene source code
Problems I noticed...
* the BUILD.txt file only instructs you to run ant to build Lucene, this
in turn runs jar-core which builds the core jar but none of the
contribs. (Because the demo is a contrib there is no obvious indication
from BUILD.txt how to build the demo). we should probably at least
mention ant -p but ironicly the package target (which is the closets
thing we have for building all jars w/o tgz or ziping them up) doesn't
have a description -- but at least people would see build-contrib.
* demo.html says...
You need two JARs: the Lucene JAR, and the Lucene demo JAR. You should
see the Lucene JAR file in the directory you created when you extracted
the archive -- it should be named something like
lucene-core-{version}.jar. You should also see a file called
contrib/demo/lucene-demo-{version}.jar
But that's not where either of those jars are found if you build from
source ... they are both in build/
* ant javadocs fails because javadocs-all can't find prettify...
BUILD FAILED
/home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/lucene-3.1.0/build.xml:206:
The following error occurred while executing this line:
/home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/lucene-3.1.0/common-build.xml:744:
/home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/dev-tools/prettify not
found.
...this seems like a pretty fundemental problem since the lucene-src
release doesn't include dev-tools at all (it's one level higher then what
we package)
## bin-tgz
Everything looks great. The README.txt is consistent with the contents,
the demo runs, the docs all look good and the links between them all work.
The only thing that seemed fishy is that we ship the javadocs as well as
javadoc jars. not sure if we really need both.
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
: * nothing in README or ant -p about how to build the non-javadocs (ie: : tutorial) we could add a one liner about this to the README.txt... Run the forrest command in the src/site directory to build the tutorial ...but the more i think about it the more i'm convinced that we should just include the pre-build site directory in the source packages this is consistent with what we do for the lucene source packages -- we actually have the html/pdf versions of hte lucene forrest docs in the solr source packages, but not the solr forrest docs. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
IMO, I think our source release should be what you get when you do a checkout from SVN. Building from source is more expert level, and one needs (minimally) ant set up. If I do another RC, I'm half-way convinced I should just do an svn export and tar it up. No .zip... anyone handling a source release should know what to do with a .tgz Attempting to automate it by yanking just the right stuff out of a superset is just so error prone. As far as docs - I think most people look online first? They would certainly look online if they didn't see anything local. -Yonik On Thu, Mar 17, 2011 at 8:47 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : * nothing in README or ant -p about how to build the non-javadocs (ie: : tutorial) we could add a one liner about this to the README.txt... Run the forrest command in the src/site directory to build the tutorial ...but the more i think about it the more i'm convinced that we should just include the pre-build site directory in the source packages this is consistent with what we do for the lucene source packages -- we actually have the html/pdf versions of hte lucene forrest docs in the solr source packages, but not the solr forrest docs. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
: IMO, I think our source release should be what you get when you do a : checkout from SVN. : Building from source is more expert level, and one needs (minimally) ant set up. meh. i don't really disagree with you, this is one of hte points i was trying to make about wondering why we had two distinct source releases instead of just one at the dev route. my comment was based on the rc1 as it existing -- that the solr source releases didn't have any clear indication of how to build the forrest docs. (and in every past release, we didn't need any indication, because they were already included pre-built) FWIW: if you do an svn checkout, you *do* get the pre-built HTML versions of the forrest documents... https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_3_1/solr/site/ https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_3_1/lucene/docs/ ...hence my point that it seemed silly we weren't including them in the rc1 src packages. : As far as docs - I think most people look online first? They would : certainly look online if they didn't see anything local. by thta same rationale, we don't need to include javadocs in any release, because you could always find them online (and if i wanted to be snarky: you could always go find the java source itself online too) In any case: we don't (yet) have version specific copies of the solr forrest docs online. the point behind having the docs in the releases has always been so that you had a copy that matched the copy of the code you were using. leaving the pre-built docs in the src release seems like a pretty simple and easy short term win. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 9:45 PM, Chris Hostetter hossman_luc...@fucit.org wrote: by thta same rationale, we don't need to include javadocs in any release, because you could always find them online (and if i wanted to be snarky: you could always go find the java source itself online too) Absolutely. The source is because I *think* we are required by the ASF to have source for a release (but we can have as many other artifacts as we want to). Otherwise I'd say yeah, dump the source release, use svn. Providing source releases as opposed to git or svn URLs is getting close to being an anachronism. -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
Re: Lucene Solr 3.1 RC1
On Mar 17, 2011, at 9:45 PM, Chris Hostetter wrote: by thta same rationale, we don't need to include javadocs in any release, because you could always find them online (and if i wanted to be snarky: you could always go find the java source itself online too) I'm tempted to +1 both those things. But okay - lets distrib all this crap and provide it online as well - and lets dance and juggle to get one form to the other - but please, oh please, can we stop distributing the website in the release. Including the PDF's of the website. This is a pain in the ass to have to update and then include in the release as an RM - it's not worth its weight IMO. Disengage from Forrest ... disengage - mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 3:53 PM, Chris Hostetter hossman_luc...@fucit.org wrote: * CHANGES.txt has a 1.4.2-dev section listing bug fixes ... as if that were a release after 1.4.1 and before the current 3.1 release. A 1.4.2 release in development, yes. That's the earliest point that the bug was fixed, and someone upgrading from 1.4.1 should look at everything after the 1.4.1 release. -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
Re: Lucene Solr 3.1 RC1
: The source is because I *think* we are required by the ASF to have yes. we are. : source for a release (but we can have as many other artifacts as we : want to). Otherwise I'd say yeah, dump the source release, use svn. : Providing source releases as opposed to git or svn URLs is getting : close to being an anachronism. svn is a work in progress, svn tags can be moved. signed release artifacts are the only true release. these things aren't really subject to debate -- they are what they are. the only question is how the tutorial should be available to people who download a source relase: I arguee that we should include the prebuilt versions, you argue that the source release should mimic what you get if you do an svn export -- since the prebuilt HTML/PDF files are what you get if you do an svn export, we have no disagreement. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
: one form to the other - but please, oh please, can we stop distributing : the website in the release. Including the PDF's of the website. This is : a pain in the ass to have to update and then include in the release as : an RM - it's not worth its weight IMO. Disengage from Forrest ... : disengage I've already contributed a patch in SOLR-2434 to completley decouple the need to do any special website building from the release process. if you want to help reduce the pain in the ass factor, please review the patch and vote to backport it to the 3_1 branch. as for why the website is include in still included in the release -- it's because no one has ever gotten arround to rolling up their sleeves and cleaning up solr's website. There's no seperation of generic docs (commiters list, front page news, etc..) from version specific docs (tutorial) like lucene-java did a long time ago; it's never been integrated with the lucen-javae website since we did the dev merge; and it's never been migrated to the new CMS. if we start using the CMS (LUCENE-2748), and migrate everything except the tutorial to the main lucene site, we could throw away forrest completley and just leave the tutorial as one simple HTML doc included with the javadocs using doc-files. patches welcome! -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Mar 17, 2011, at 11:13 PM, Chris Hostetter wrote: patches welcome! Sometimes you have to slash and burn to clean out the old under brush. My patch would simply excise forrest and the website. Then, reveling in the success of that great improvement, I'd sit back, take stalk and see what came along. But it looks like others are winding along on another track - so I'm happy to let them go about it and see where we land. Apache's home brew CMS scares me until proven otherwise. - mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Solr 3.1 RC1
On Thu, Mar 17, 2011 at 11:18 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : A 1.4.2 release in development, yes. That's the earliest point that : the bug was fixed, and someone : upgrading from 1.4.1 should look at everything after the 1.4.1 release. that makes no sense to me. even if a 1.4.2 release is going ot exist at some hypothetical point in the future, it doesn't exist *now* when the 3.1 release is coming out. CHANGES.txt should only list real changes since real releases. All of the things listed in the 1.4.2-dev section have actually been fixed in the the 3.1 branch as well -- in fact, most of them (all but one i think) are double listed in the 3.1 bug section of the CHANGES.txt We can't predict the future -- we don't know what else might get included in a hypotheetical 1.4.2 release, so we're better off listing nothing, then listing something that might be wrong. But it's listed as 1.4.2-dev (in development). I'm not sure exactly what you have in mind, but feel free to fix it.. it's a really minor issue to me. (this, for the record, is one of hte potential problems i've brought up several times about having 3x stuff listed in the CHANGES.txt on 4x, nad what happens if there are overlapping releases. it's why i argued that the 3x CHANGES.txt should *only* include things commited to the 3x branch (nothing from solr 1.4 or lucene 2.9) I sort of adopted the lucene convention of how to deal with 3x and trunk. If you fix something in trunk and are going to immediately merge back to 3x, you put it in the 3x section of CHANGES in trunk and then merge back. Personally, I think it might be easiest to keep two files in trunk: CHANGES_40 and CHANGES. CHANGES would always be identical to 3x, and you would update that if you were going to merge back to 3x. When it's time for release, CHANGES_40 and CHANGES could be put 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
