Re: [VOTE] Lucene/Solr 4.3 RC1
On Apr 20, 2013, at 7:03 AM, Michael McCandless luc...@mikemccandless.com wrote: On Sat, Apr 20, 2013 at 2:43 AM, Steve Rowe sar...@gmail.com wrote: I think another smoke test might be useful: compare the claimed svn revision against the revision in the manifest of each archive to be released, e.g. from the RC2 lucene-core-4.3.0.jar: Implementation-Version: 4.3.0 1470054 - simonw - 2013-04-19 23:43:33 We would have to supply the revision on the cmdline to the smoke tester, for the case when the revision is not included in the base URL, and the RM would have to supply this info in the VOTE thread. Supplying an RC's source is a good idea anyway: here's an RC, it's built from svn rXXX (no need to supply rel branch since this is established convention). +1, this is a great idea. Do you want to add this? Or I can … (Looking back over this thread, I noticed that Uwe made the same suggestion - sorry Uwe, didn't mean to steal your thunder :) I'll work on it. RMs can easily get this by running svn info from where they build the release. buildAndPushRelease runs svnversion to get this. Hmm but it does not pass -c ... should it? The svn revision identifies a static sub-tree. The way Subversion works, though, for any given sub-tree, there may be many revisions that refer to this same static sub-tree - these are effectively aliases. While we *could* use 'svnversion -c' to find the first revision that identifies the static sub-tree from which a release is cut, I don't see much benefit in doing so - the svn revision that the RM happens to use can be used later to find this revision if we ever need it. In fact, I think it's a potential source of error to be referring to multiple revisions (the checked out revision and the most recent changed revision), so I'd prefer for buildAndPushRelease to stay as-is, and not pass -c to svnversion. I guess alternatively, we could ask RMs to always check out the revision of the most recent change to the release branch that the RM wants to include, in which case there would only one be one revision being used, but this seems to me to be an all-cost-no-benefit change, so here's my vote not to do that. About automation: Yes, things slip through the cracks. So we learn and add more checks. Not continuing this process is IMHO a mistake. I completely agree in general: we patch each crack whenever we fall in it. This is a powerful way to improve... But for this particular crack (verifying that the revision of the RC is the latest revision on the release branch) I couldn't see a simple way to do it, w/o having smokeTester make guesses about the name of the release branch ... such guessing/enforced convention crosses the line of what automation should be doing imo and the filled crack could be worse than the unfilled one. +1 Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Apr 19, 2013, at 6:44 PM, Michael McCandless luc...@mikemccandless.com wrote: On Fri, Apr 19, 2013 at 6:36 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : OK I think a WARNING in smokeTester makes sense ... : : But as Hoss said ... figuring out the release branch from smokeTester : ... isn't easy. Hmm. At a certain point, too much automation is too much. I already think the snoke tester is too complicated -- what tests the tester? It's great to automate any sanity checks thta can be reliably automated, but we have to remeber that each of us has to take resonsibiliity for hte fact that we are *personally* voting for hte release, and the smoke test scripts are just tools to help save us time doing verifying trivial things. We still need to be concious of what exactly is in the release, and wether it works, and wether the smoke testers SUCCESS was really a false positive, etc... smokeTestRelease.py don't vote to release; People vote to release. Yeah I agree ... I think we should leave this out of the snoke tester. buildAndPushRelease already svn ups for you … But not every RM will use that. I think another smoke test might be useful: compare the claimed svn revision against the revision in the manifest of each archive to be released, e.g. from the RC2 lucene-core-4.3.0.jar: Implementation-Version: 4.3.0 1470054 - simonw - 2013-04-19 23:43:33 We would have to supply the revision on the cmdline to the smoke tester, for the case when the revision is not included in the base URL, and the RM would have to supply this info in the VOTE thread. Supplying an RC's source is a good idea anyway: here's an RC, it's built from svn rXXX (no need to supply rel branch since this is established convention). RMs can easily get this by running svn info from where they build the release. About automation: Yes, things slip through the cracks. So we learn and add more checks. Not continuing this process is IMHO a mistake. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Apr 19, 2013, at 6:16 PM, Uwe Schindler u...@thetaphi.de wrote: I think, maybe Smoketester should compare the revision from the URL in the RC vote with the one recorded in the JAR files? Everything else makes no sense as the: a) The SVN server always replies with the latest committed version on the whole repository not the one of the newest file in the branch. I just noticed that 'svn info' provides the most recent revision for any given file or directory, e.g. for the top level trunk dir: Path: . Working Copy Root Path: /Users/sarowe/svn/lucene/dev/trunk URL: https://svn.apache.org/repos/asf/lucene/dev/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1469936 Node Kind: directory Schedule: normal Last Changed Author: rmuir Last Changed Rev: 1469889 Last Changed Date: 2013-04-19 11:20:04 -0400 (Fri, 19 Apr 2013) This command can be run recursively, and revisions collected, and the most recent one found, e.g.: PROMPT$ svn info -R | grep 'Last Changed Rev:' | cut -d' ' -f4 | sort -n | tail -1 1470088 The above command takes less than a second on my Macbook pro, and I don't see any network activity, so this info must be all locally cached. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene/Solr 4.3 RC1
svnversion -c Prints the last changed version after the :, e.g. compare these outputs: C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3svn info Path: . Working Copy Root Path: C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3 Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1470120 Node Kind: directory Schedule: normal Last Changed Author: simonw Last Changed Rev: 1470112 Last Changed Date: 2013-04-20 08:28:33 +0200 (Sa, 20 Apr 2013) C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3svnversion -c 442281:1470112 I have no idea what the first number means, it must have something to do with the first rev this branch was created or whatever. -c means last committed according to docs. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Saturday, April 20, 2013 9:11 AM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 On Apr 19, 2013, at 6:16 PM, Uwe Schindler u...@thetaphi.de wrote: I think, maybe Smoketester should compare the revision from the URL in the RC vote with the one recorded in the JAR files? Everything else makes no sense as the: a) The SVN server always replies with the latest committed version on the whole repository not the one of the newest file in the branch. I just noticed that 'svn info' provides the most recent revision for any given file or directory, e.g. for the top level trunk dir: Path: . Working Copy Root Path: /Users/sarowe/svn/lucene/dev/trunk URL: https://svn.apache.org/repos/asf/lucene/dev/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1469936 Node Kind: directory Schedule: normal Last Changed Author: rmuir Last Changed Rev: 1469889 Last Changed Date: 2013-04-19 11:20:04 -0400 (Fri, 19 Apr 2013) This command can be run recursively, and revisions collected, and the most recent one found, e.g.: PROMPT$ svn info -R | grep 'Last Changed Rev:' | cut -d' ' -f4 | sort -n | tail - 1 1470088 The above command takes less than a second on my Macbook pro, and I don't see any network activity, so this info must be all locally cached. Steve - 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] Lucene/Solr 4.3 RC1
If the revision number is not given, the script should at least check that all revision numbers in the JARs/WARs are identical. By this you can prevent bugs because somebody did not correctly do ant clean and only partially built the jars. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Saturday, April 20, 2013 8:43 AM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 On Apr 19, 2013, at 6:44 PM, Michael McCandless luc...@mikemccandless.com wrote: On Fri, Apr 19, 2013 at 6:36 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : OK I think a WARNING in smokeTester makes sense ... : : But as Hoss said ... figuring out the release branch from smokeTester : ... isn't easy. Hmm. At a certain point, too much automation is too much. I already think the snoke tester is too complicated -- what tests the tester? It's great to automate any sanity checks thta can be reliably automated, but we have to remeber that each of us has to take resonsibiliity for hte fact that we are *personally* voting for hte release, and the smoke test scripts are just tools to help save us time doing verifying trivial things. We still need to be concious of what exactly is in the release, and wether it works, and wether the smoke testers SUCCESS was really a false positive, etc... smokeTestRelease.py don't vote to release; People vote to release. Yeah I agree ... I think we should leave this out of the snoke tester. buildAndPushRelease already svn ups for you … But not every RM will use that. I think another smoke test might be useful: compare the claimed svn revision against the revision in the manifest of each archive to be released, e.g. from the RC2 lucene-core-4.3.0.jar: Implementation-Version: 4.3.0 1470054 - simonw - 2013-04-19 23:43:33 We would have to supply the revision on the cmdline to the smoke tester, for the case when the revision is not included in the base URL, and the RM would have to supply this info in the VOTE thread. Supplying an RC's source is a good idea anyway: here's an RC, it's built from svn rXXX (no need to supply rel branch since this is established convention). RMs can easily get this by running svn info from where they build the release. About automation: Yes, things slip through the cracks. So we learn and add more checks. Not continuing this process is IMHO a mistake. Steve - 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] Lucene/Solr 4.3 RC1
Cool, 'svnrevision -c' is recursive and provides a single result, unlike svn info when run recursively. On Apr 20, 2013, at 3:29 AM, Uwe Schindler u...@thetaphi.de wrote: svnversion -c Prints the last changed version after the :, e.g. compare these outputs: C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3svn info Path: . Working Copy Root Path: C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3 Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1470120 Node Kind: directory Schedule: normal Last Changed Author: simonw Last Changed Rev: 1470112 Last Changed Date: 2013-04-20 08:28:33 +0200 (Sa, 20 Apr 2013) C:\Users\Uwe Schindler\Projects\lucene\lucene_solr_4_3svnversion -c 442281:1470112 I have no idea what the first number means, it must have something to do with the first rev this branch was created or whatever. -c means last committed according to docs. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Sat, Apr 20, 2013 at 2:43 AM, Steve Rowe sar...@gmail.com wrote: On Apr 19, 2013, at 6:44 PM, Michael McCandless luc...@mikemccandless.com wrote: On Fri, Apr 19, 2013 at 6:36 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : OK I think a WARNING in smokeTester makes sense ... : : But as Hoss said ... figuring out the release branch from smokeTester : ... isn't easy. Hmm. At a certain point, too much automation is too much. I already think the snoke tester is too complicated -- what tests the tester? It's great to automate any sanity checks thta can be reliably automated, but we have to remeber that each of us has to take resonsibiliity for hte fact that we are *personally* voting for hte release, and the smoke test scripts are just tools to help save us time doing verifying trivial things. We still need to be concious of what exactly is in the release, and wether it works, and wether the smoke testers SUCCESS was really a false positive, etc... smokeTestRelease.py don't vote to release; People vote to release. Yeah I agree ... I think we should leave this out of the snoke tester. buildAndPushRelease already svn ups for you … But not every RM will use that. True. I think another smoke test might be useful: compare the claimed svn revision against the revision in the manifest of each archive to be released, e.g. from the RC2 lucene-core-4.3.0.jar: Implementation-Version: 4.3.0 1470054 - simonw - 2013-04-19 23:43:33 We would have to supply the revision on the cmdline to the smoke tester, for the case when the revision is not included in the base URL, and the RM would have to supply this info in the VOTE thread. Supplying an RC's source is a good idea anyway: here's an RC, it's built from svn rXXX (no need to supply rel branch since this is established convention). +1, this is a great idea. Do you want to add this? Or I can ... RMs can easily get this by running svn info from where they build the release. buildAndPushRelease runs svnversion to get this. Hmm but it does not pass -c ... should it? About automation: Yes, things slip through the cracks. So we learn and add more checks. Not continuing this process is IMHO a mistake. I completely agree in general: we patch each crack whenever we fall in it. This is a powerful way to improve... But for this particular crack (verifying that the revision of the RC is the latest revision on the release branch) I couldn't see a simple way to do it, w/o having smokeTester make guesses about the name of the release branch ... such guessing/enforced convention crosses the line of what automation should be doing imo and the filled crack could be worse than the unfilled one. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
+1 The smoker tester ran successful! On 19 April 2013 08:18, Simon Willnauer simon.willna...@gmail.com wrote: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Thanks everybody for the hard work! Smoke tester says: SUCCESS! Integration into ES is successful! there is my +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Met vriendelijke groet, Martijn van Groningen
RE: [VOTE] Lucene/Solr 4.3 RC1
Hi, I am still reviewing. I have one note about the changes.txt where we miss a backwards break: * https://issues.apache.org/jira/browse/LUCENE-4877 made the AnalysisFactories require to have a non-default ctor, otherwise a MethodNotFoundException is thrown on initializing the SPI. The new constructor needs to have MapString,String parameters containing the factory params (e.g. from schema.xml). This change affects all users that wrote own factories for their own analysis components, so this should really be mentioned in the Lucene changelog (maybe also in Solr). Unfortunately the changes entry in CHANGES.txt only contains a simple note: LUCENE-4877: Throw exception for invalid arguments in analysis factories., which does not even mention the backwards break. For me the existing factories failed to work, although they compiled (so it’s a deleayed problem). * The changes.txt also has 2 times the section API changes making the javascript behave wrong (it always opens the first section when you click on any of those). We should maybe add a check for this to the Changes-generator-Perl script (so it complains when processing changes.txt and it finds duplicate headers). These documentation bugs are not serious and may be put into the wiki after release (on the errata page of the release), but should be fixed if we respin. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Willnauer [mailto:simon.willna...@gmail.com] Sent: Friday, April 19, 2013 8:18 AM To: dev@lucene.apache.org Subject: [VOTE] Lucene/Solr 4.3 RC1 http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1- rev1469340/ Thanks everybody for the hard work! Smoke tester says: SUCCESS! Integration into ES is successful! there is my +1 - 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] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 8:25 AM, Uwe Schindler u...@thetaphi.de wrote: Hi, I am still reviewing. I have one note about the changes.txt where we miss a backwards break: * https://issues.apache.org/jira/browse/LUCENE-4877 made the AnalysisFactories require to have a non-default ctor, otherwise a MethodNotFoundException is thrown on initializing the SPI. The new constructor needs to have MapString,String parameters containing the factory params (e.g. from schema.xml). This change affects all users that wrote own factories for their own analysis components, so this should really be mentioned in the Lucene changelog (maybe also in Solr). Unfortunately the changes entry in CHANGES.txt only contains a simple note: LUCENE-4877: Give me a break. the factory api was *already* broken in 4.3 before I even did this issue, by those AttributeSource api changes. No need to single out and overreact to my change, no backwards break was necessary since it already existed from another change.
RE: [VOTE] Lucene/Solr 4.3 RC1
I don’t overreact. And please note: I was also involved in this issue. The break is: You have a factory as a Solr customer that worked in 4.2. The problem with the java language is the fact that you cannot enforce specific ctors in subclasses, so you simply have to do this by yourself. Unfortunately this is also not even fully documented (we have nothing that mentions this in the base class, like: “every XxxFactory needs at least one constructor taking MapString,String, so Lucene’s SPI framework can load it”). The compiler does not enforce it. You will find the bug only if you put your own factory into solr’s lib folder and then you get MethodNotFoundException on startup. I just said: We should mention this change if we respin, nothing more! And it is a break of some kind (because a method signature changed, in this case a required ctor signature). I just want to have one sentence in the documentation of the factories and another backwards break entry, maybe merged with the TokenizerFactory (needing AttributeSource) one. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Robert Muir [mailto:rcm...@gmail.com] Sent: Friday, April 19, 2013 2:45 PM To: dev@lucene.apache.org Cc: simon.willna...@gmail.com Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 On Fri, Apr 19, 2013 at 8:25 AM, Uwe Schindler u...@thetaphi.de wrote: Hi, I am still reviewing. I have one note about the changes.txt where we miss a backwards break: * https://issues.apache.org/jira/browse/LUCENE-4877 made the AnalysisFactories require to have a non-default ctor, otherwise a MethodNotFoundException is thrown on initializing the SPI. The new constructor needs to have MapString,String parameters containing the factory params (e.g. from schema.xml). This change affects all users that wrote own factories for their own analysis components, so this should really be mentioned in the Lucene changelog (maybe also in Solr). Unfortunately the changes entry in CHANGES.txt only contains a simple note: LUCENE-4877: Give me a break. the factory api was *already* broken in 4.3 before I even did this issue, by those AttributeSource api changes. No need to single out and overreact to my change, no backwards break was necessary since it already existed from another change.
Re: [VOTE] Lucene/Solr 4.3 RC1
Thanks Simon! Getting my smoke tester ready… - Mark On Apr 19, 2013, at 2:18 AM, Simon Willnauer simon.willna...@gmail.com wrote: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Thanks everybody for the hard work! Smoke tester says: SUCCESS! Integration into ES is successful! there is my +1 - 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] Lucene/Solr 4.3 RC1
+1 - somke tester passes for me. On Apr 19, 2013, at 2:18 AM, Simon Willnauer simon.willna...@gmail.com wrote: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Thanks everybody for the hard work! Smoke tester says: SUCCESS! Integration into ES is successful! there is my +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.orgwrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss
Re: [VOTE] Lucene/Solr 4.3 RC1
Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.orgwrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Lucene/Solr 4.3 RC1
@uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Lucene/Solr 4.3 RC1
Will fix soon! Uwe Simon Willnauer simon.willna...@gmail.com schrieb: @uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Lucene/Solr 4.3 RC1
thanks uwe... let me know I will run a new RC once you are done On Fri, Apr 19, 2013 at 11:11 PM, Uwe Schindler u...@thetaphi.de wrote: Will fix soon! Uwe Simon Willnauer simon.willna...@gmail.com schrieb: @uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
RE: [VOTE] Lucene/Solr 4.3 RC1
I’m done. The duplicate „API changes” section was fixed by hosman already. But its good that we have an issue now to prevent this in the future. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Simon Willnauer [mailto:simon.willna...@gmail.com] Sent: Friday, April 19, 2013 11:24 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 thanks uwe... let me know I will run a new RC once you are done On Fri, Apr 19, 2013 at 11:11 PM, Uwe Schindler u...@thetaphi.de wrote: Will fix soon! Uwe Simon Willnauer simon.willna...@gmail.com schrieb: @uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Lucene/Solr 4.3 RC1
thanks uwe... I started a new RC build simon On Fri, Apr 19, 2013 at 11:43 PM, Uwe Schindler u...@thetaphi.de wrote: I’m done. The duplicate „API changes” section was fixed by hosman already. But its good that we have an issue now to prevent this in the future. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Simon Willnauer [mailto:simon.willna...@gmail.com] Sent: Friday, April 19, 2013 11:24 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 thanks uwe... let me know I will run a new RC once you are done On Fri, Apr 19, 2013 at 11:11 PM, Uwe Schindler u...@thetaphi.de wrote: Will fix soon! Uwe Simon Willnauer simon.willna...@gmail.com schrieb: @uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
Hmm @hoss did you check this manually, I mean the revision? I think our smoketester should check the revision of the release branch and the revision of the RC to make sure this doesn't happen? simon On Fri, Apr 19, 2013 at 11:45 PM, Simon Willnauer simon.willna...@gmail.com wrote: thanks uwe... I started a new RC build simon On Fri, Apr 19, 2013 at 11:43 PM, Uwe Schindler u...@thetaphi.de wrote: I’m done. The duplicate „API changes” section was fixed by hosman already. But its good that we have an issue now to prevent this in the future. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Simon Willnauer [mailto:simon.willna...@gmail.com] Sent: Friday, April 19, 2013 11:24 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 thanks uwe... let me know I will run a new RC once you are done On Fri, Apr 19, 2013 at 11:11 PM, Uwe Schindler u...@thetaphi.de wrote: Will fix soon! Uwe Simon Willnauer simon.willna...@gmail.com schrieb: @uwe sure! On Fri, Apr 19, 2013 at 10:48 PM, Uwe Schindler u...@thetaphi.de wrote: Can we fix changes.txt before that? Uwe Simon Willnauer simon.willna...@gmail.com schrieb: ah man, good call! that is my fault. I know what went wrong here. Damned! ok that means I need to respin that one. This might take a while on my end. sorry about that. simon On Fri, Apr 19, 2013 at 10:25 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC1-rev1469340/ Hmmm? ... r1469340 is from Thu Apr 18 14:20:33 2013 UTC FWIW: There were several changes made after r1469340 (but well before the proposed Friday 36 hours from now) to try and clean up the release notes and fix some bugs. This is what's currently on the 4.3 branch that did *not* make it into RC1... hossman@frisbee:~/lucene/branch_4_3$ svn log -r 1469340:HEAD r1469510 | hossman | 2013-04-18 11:13:19 -0700 (Thu, 18 Apr 2013) | 1 line improve upgrading instructions for 4.3 ... grouped by theme, and more focused on what people need to be concerned with instead of just cut/paste the changes entry for each jira. (merge r1469508) r1469534 | hossman | 2013-04-18 12:30:12 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4729: testcase for catchall copyField (merge r1469529) r1469606 | hossman | 2013-04-18 15:31:47 -0700 (Thu, 18 Apr 2013) | 1 line 4.3 CHANGES fix up: consolidate multiple 'API Changes' sections and move to just below backcompat so it's more obvious (merge r1469600) r1469677 | markrmiller | 2013-04-18 20:44:21 -0700 (Thu, 18 Apr 2013) | 1 line SOLR-4716,SOLR-4584: SolrCloud request proxying does not work on Tomcat and perhaps other non Jetty containers. -Hoss -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 6:07 PM, Simon Willnauer simon.willna...@gmail.com wrote: Hmm @hoss did you check this manually, I mean the revision? I think our smoketester should check the revision of the release branch and the revision of the RC to make sure this doesn't happen? SmokeTester might be too anal? Like sometimes we backport stuff to the release branch just in case another RC is cut ... But I think buildAndPushRelease is a good place to do it? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene/Solr 4.3 RC1
I think, maybe Smoketester should compare the revision from the URL in the RC vote with the one recorded in the JAR files? Everything else makes no sense as the: a) The SVN server always replies with the latest committed version on the whole repository not the one of the newest file in the branch. b) We can have changes in the RC branch after RC started - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Saturday, April 20, 2013 12:12 AM To: dev@lucene.apache.org; simon.willna...@gmail.com Cc: Uwe Schindler Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 On Fri, Apr 19, 2013 at 6:07 PM, Simon Willnauer simon.willna...@gmail.com wrote: Hmm @hoss did you check this manually, I mean the revision? I think our smoketester should check the revision of the release branch and the revision of the RC to make sure this doesn't happen? SmokeTester might be too anal? Like sometimes we backport stuff to the release branch just in case another RC is cut ... But I think buildAndPushRelease is a good place to do it? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 6:12 PM, Michael McCandless luc...@mikemccandless.com wrote: On Fri, Apr 19, 2013 at 6:07 PM, Simon Willnauer simon.willna...@gmail.com wrote: Hmm @hoss did you check this manually, I mean the revision? I think our smoketester should check the revision of the release branch and the revision of the RC to make sure this doesn't happen? SmokeTester might be too anal? Like sometimes we backport stuff to the release branch just in case another RC is cut ... But I think buildAndPushRelease is a good place to do it? Actually, bpRelease already does svn up before ant prepare... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
keep in mind there may not be one in the URL. Its nice to smoke-test before uploading to your home directory. also its useful to run 'ant nightly-smoke' and run a smoke test, and if someone commits something while this is happening, its no problem. jenkins does this automatically too. so can we have not a failure but a warning, like: ***WARNING***: not the latest SVN version On Fri, Apr 19, 2013 at 6:16 PM, Uwe Schindler u...@thetaphi.de wrote: I think, maybe Smoketester should compare the revision from the URL in the RC vote with the one recorded in the JAR files? Everything else makes no sense as the: a) The SVN server always replies with the latest committed version on the whole repository not the one of the newest file in the branch. b) We can have changes in the RC branch after RC started - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Saturday, April 20, 2013 12:12 AM To: dev@lucene.apache.org; simon.willna...@gmail.com Cc: Uwe Schindler Subject: Re: [VOTE] Lucene/Solr 4.3 RC1 On Fri, Apr 19, 2013 at 6:07 PM, Simon Willnauer simon.willna...@gmail.com wrote: Hmm @hoss did you check this manually, I mean the revision? I think our smoketester should check the revision of the release branch and the revision of the RC to make sure this doesn't happen? SmokeTester might be too anal? Like sometimes we backport stuff to the release branch just in case another RC is cut ... But I think buildAndPushRelease is a good place to do it? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
: Hmm @hoss did you check this manually, I mean the revision?
ironically, i noticed because i initially tried running the 4x version of
the smoke tester again the RC, and it complained about the duplicated
changes sections. At which point i starting thinking that it was my fault
for using the 4x smoke tester instead of the 4_3 smoke tester, because
clearly the changes.txt fix to go along with the smoke tester fix probably
only made it to the 4_x branch -- then i remembered *I* was the one that
fixed CHANGES.txt, yesterday, and i knew for a fact i had put it on the
4_3 branch.
then i had that entire conversation over again in my head because it still
didn't make any sense to me. then i looked at the revision number.
: I think our smoketester should check the revision of the release branch and
: the revision of the RC to make sure this doesn't happen?
1) i'm not sure how it would do that, it doesn't currently know anything
about branches does it?
2) it would make it really hard for people to keep testing an RC${X} to
look for more problems after it was already decided there should be
an RC{$X+1} and someone had commited something for that.
If we don't do so already though, it would definitely be good to have the
release scripts force an svn update though in case the RM ddin't realize
their working dir was stale (i realize that's not what happened in this
case, but still -- good idea.)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 6:16 PM, Uwe Schindler u...@thetaphi.de wrote: I think, maybe Smoketester should compare the revision from the URL in the RC vote with the one recorded in the JAR files? Hmmm OK ... though, buildAndPushRelease computed that URL from the svn checkout it build the release from ... so now I'm confused how the two were out of sync here ... maybe a bug in buildAndPushRelease? Simon did you use it or did you run your own steps (I know the GPG password isn't working right so maybe you fell back on your own steps...). Everything else makes no sense as the: a) The SVN server always replies with the latest committed version on the whole repository not the one of the newest file in the branch. Apparently svn log -r BASE:HEAD is sort of the equivalent of hg/git incoming. b) We can have changes in the RC branch after RC started Right. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 6:19 PM, Robert Muir rcm...@gmail.com wrote: keep in mind there may not be one in the URL. Its nice to smoke-test before uploading to your home directory. also its useful to run 'ant nightly-smoke' and run a smoke test, and if someone commits something while this is happening, its no problem. jenkins does this automatically too. so can we have not a failure but a warning, like: ***WARNING***: not the latest SVN version OK I think a WARNING in smokeTester makes sense ... But as Hoss said ... figuring out the release branch from smokeTester ... isn't easy. Hmm. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
: OK I think a WARNING in smokeTester makes sense ... : : But as Hoss said ... figuring out the release branch from smokeTester : ... isn't easy. Hmm. At a certain point, too much automation is too much. I already think the snoke tester is too complicated -- what tests the tester? It's great to automate any sanity checks thta can be reliably automated, but we have to remeber that each of us has to take resonsibiliity for hte fact that we are *personally* voting for hte release, and the smoke test scripts are just tools to help save us time doing verifying trivial things. We still need to be concious of what exactly is in the release, and wether it works, and wether the smoke testers SUCCESS was really a false positive, etc... smokeTestRelease.py don't vote to release; People vote to release. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene/Solr 4.3 RC1
On Fri, Apr 19, 2013 at 6:36 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : OK I think a WARNING in smokeTester makes sense ... : : But as Hoss said ... figuring out the release branch from smokeTester : ... isn't easy. Hmm. At a certain point, too much automation is too much. I already think the snoke tester is too complicated -- what tests the tester? It's great to automate any sanity checks thta can be reliably automated, but we have to remeber that each of us has to take resonsibiliity for hte fact that we are *personally* voting for hte release, and the smoke test scripts are just tools to help save us time doing verifying trivial things. We still need to be concious of what exactly is in the release, and wether it works, and wether the smoke testers SUCCESS was really a false positive, etc... smokeTestRelease.py don't vote to release; People vote to release. Yeah I agree ... I think we should leave this out of the snoke tester. buildAndPushRelease already svn ups for you ... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
