Smiley, David W.
2012-04-05, 21:42
Robert Muir
2012-04-05, 21:45
Mark Miller
2012-04-05, 22:05
Andi Vajda
2012-04-05, 23:11
Tommaso Teofili
2012-04-06, 07:17
Christian Moen
2012-04-06, 08:58
Uwe Schindler
2012-04-06, 10:35
Robert Muir
2012-04-06, 10:43
Uwe Schindler
2012-04-06, 10:55
Robert Muir
2012-04-06, 11:22
Robert Muir
2012-04-06, 11:28
Robert Muir
2012-04-06, 11:35
Uwe Schindler
2012-04-06, 11:35
Martijn v Groningen
2012-04-06, 11:37
Robert Muir
2012-04-06, 11:37
Uwe Schindler
2012-04-06, 11:39
Robert Muir
2012-04-06, 11:40
Uwe Schindler
2012-04-06, 11:40
Robert Muir
2012-04-06, 11:42
Uwe Schindler
2012-04-06, 11:47
Robert Muir
2012-04-06, 11:50
Uwe Schindler
2012-04-06, 11:55
Robert Muir
2012-04-06, 12:12
Walter Underwood
2012-04-06, 13:15
Robert Muir
2012-04-06, 13:48
-
Re: VOTE: Lucene/Solr 3.6Smiley, David W. 2012-04-05, 21:42
On Apr 5, 2012, at 5:22 PM, Robert Muir wrote:
> On Thu, Apr 5, 2012 at 5:03 PM, Smiley, David W. <[EMAIL PROTECTED]> wrote:
>> There is a lingering discussion that comes to mind here:
>> https://issues.apache.org/jira/browse/SOLR-2724
>> Title: Deprecate defaultSearchField and defaultOperator defined in schema.xml
>> Essentially I committed this to 3x and trunk, trunk was subsequently reverted due to something else entirely,
>
> I don't think it was entirely unrelated, if my memory serves, this was
> last minute shoving at midnight before the code freeze (without
> running tests) that broke the build.
This didn't break the build but triggered SOLR-3292 which wasn't tested. Yes it was last minute, although the issue already had discussion.
>
>> but before I re-committed to trunk, Yonik pipes in and says he doesn't agree with their deprecation (no vote up/down though). So… now what?
>>
>
> you undeprecate it in 4.0.
So it stays deprecated in 3.6 but not deprecated in 4.x? That doesn't sound right. Perhaps someone with specific comments about SOLR-2724 should add to this discussion.
~ David
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-05, 21:45
On Thu, Apr 5, 2012 at 5:42 PM, Smiley, David W. <[EMAIL PROTECTED]> wrote:
> So it stays deprecated in 3.6 but not deprecated in 4.x? That doesn't sound right. Perhaps someone with specific comments about SOLR-2724 should add to this discussion.
>
Its too late to discuss this issue for 3.6 (only blocker changes,
broken packaging, legal issues at this point, in which case we very
carefully fix the bugs and respin): you either reach concensus towards
removing whatever you wanted to remove in trunk, or you don't and you
add a note to 4.0's CHANGES.txt that it was undeprecated.
--
lucidimagination.com
---------------------------------------------------------------------
> So it stays deprecated in 3.6 but not deprecated in 4.x? That doesn't sound right. Perhaps someone with specific comments about SOLR-2724 should add to this discussion.
>
Its too late to discuss this issue for 3.6 (only blocker changes,
broken packaging, legal issues at this point, in which case we very
carefully fix the bugs and respin): you either reach concensus towards
removing whatever you wanted to remove in trunk, or you don't and you
add a note to 4.0's CHANGES.txt that it was undeprecated.
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Mark Miller 2012-04-05, 22:05
On Apr 5, 2012, at 5:45 PM, Robert Muir wrote:
> Its too late to discuss this issue for 3.6
+1. We don't even know *what* will end up happening on trunk until 4 is released. Let's not get all bent out of shape here when we might undeprecate it and then just remove it later anyway. I believe there is a wiki release errata type page that we can use to clarify if we need to. Otherwise the worst that happens is that some people move to using the params rather than the xml files - no big deal. If we end up removing it, they are good. If we don't, they are still good. This is a tiny issue that I don't believe will change any of the votes already given.
- Mark Miller
lucidimagination.com
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Andi Vajda 2012-04-05, 23:11
On Thu, 5 Apr 2012, Robert Muir wrote:
> Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
>
> I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources
> on both source releases, tested solr example, and reviewed packaging
> contents (http://people.apache.org/~rmuir/36_review/)
>
> Here's my +1.
I built PyLucene from tip of the branch_3x sources and all tests passed.
The ivy-bootstrap error message is a very helpful and welcome response to
"why did the build break ??" question one inevitably asks oneself when
building for the very first time. Very well done, thank you !
+1 !
Andi..
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Tommaso Teofili 2012-04-06, 07:17
+1 for the release and I agree with Mark and Robert's points.
Tommaso
2012/4/6 Mark Miller <[EMAIL PROTECTED]>
>
> On Apr 5, 2012, at 5:45 PM, Robert Muir wrote:
>
> > Its too late to discuss this issue for 3.6
>
> +1. We don't even know *what* will end up happening on trunk until 4 is
> released. Let's not get all bent out of shape here when we might
> undeprecate it and then just remove it later anyway. I believe there is a
> wiki release errata type page that we can use to clarify if we need to.
> Otherwise the worst that happens is that some people move to using the
> params rather than the xml files - no big deal. If we end up removing it,
> they are good. If we don't, they are still good. This is a tiny issue that
> I don't believe will change any of the votes already given.
>
> - Mark Miller
> lucidimagination.com
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Tommaso
2012/4/6 Mark Miller <[EMAIL PROTECTED]>
>
> On Apr 5, 2012, at 5:45 PM, Robert Muir wrote:
>
> > Its too late to discuss this issue for 3.6
>
> +1. We don't even know *what* will end up happening on trunk until 4 is
> released. Let's not get all bent out of shape here when we might
> undeprecate it and then just remove it later anyway. I believe there is a
> wiki release errata type page that we can use to clarify if we need to.
> Otherwise the worst that happens is that some people move to using the
> params rather than the xml files - no big deal. If we end up removing it,
> they are good. If we don't, they are still good. This is a tiny issue that
> I don't believe will change any of the votes already given.
>
> - Mark Miller
> lucidimagination.com
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
Re: VOTE: Lucene/Solr 3.6Christian Moen 2012-04-06, 08:58
Hello again Robert,
I've been doing some end-to-end testing on Kuromoji using the release candidate build and things look good to me.
I've also done the testing described on SOLR-3282 earlier using a branch_3x build from last week. That also looks good.
I have one legal question:
In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
Christian Moen
http://www.atilika.com
On Apr 6, 2012, at 12:25 AM, Christian Moen wrote:
> Robert,
>
> Great work getting everything ready and reworking the build system as well. I'll take Kuromoji for a spin and provide feedback tomorrow (Japanese time).
>
>
> Christian
> http://www.atilika.com
>
> On Apr 5, 2012, at 1:45 PM, Robert Muir wrote:
>
>> Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
>>
>> I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources
>> on both source releases, tested solr example, and reviewed packaging
>> contents (http://people.apache.org/~rmuir/36_review/)
>>
>> Here's my +1.
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
---------------------------------------------------------------------
I've been doing some end-to-end testing on Kuromoji using the release candidate build and things look good to me.
I've also done the testing described on SOLR-3282 earlier using a branch_3x build from last week. That also looks good.
I have one legal question:
In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
Christian Moen
http://www.atilika.com
On Apr 6, 2012, at 12:25 AM, Christian Moen wrote:
> Robert,
>
> Great work getting everything ready and reworking the build system as well. I'll take Kuromoji for a spin and provide feedback tomorrow (Japanese time).
>
>
> Christian
> http://www.atilika.com
>
> On Apr 5, 2012, at 1:45 PM, Robert Muir wrote:
>
>> Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
>>
>> I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources
>> on both source releases, tested solr example, and reviewed packaging
>> contents (http://people.apache.org/~rmuir/36_review/)
>>
>> Here's my +1.
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 10:35
Hi,
I tested Lucene and Solr builds:
- The tgz files unzip fine with Linux/Cygwin tar, but with latest Windows 7-Zip Filemanager it says (when opening the inner TAR file): "data after end of tar file" (or like that). As the fixes extract correctly on Linux, I think that might be a bug in 7-Zip, but never happened with any releases before.
- URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a major problem, as this is a huge change and people used to building Lucene from source only looking into CHANGES.txt will fail to build without inspecting BUILD.txt. We have changes entries for the refactoring of the build directory structure (by Steven), but not for the Ivy change. Very bad! We must at least tell people about that in the release notes, otherwise -1.
- PANGAEA huge index checks: No VInt bugs or similar on checkindex and anywhere else (Java 1.7.0_03). Now runs in production, very nice. Not even a need to recompile the whole stuff needed, fine backwards!
- JAR files build with JDK 1.5.0_22 - That’s really nice, thanks Robert (and important in my opinion, I was missing that in previous releases).
- Binary Javadocs still Geocities-like, it's no problem, but was it not planned to use Java 7? - It's of course fine!
- Lucene Source package builds and tests fine.
- Solr Source package builds fine (I only ran the build inside solr/ folder to test this actually works)
- Solr tests ran fine on second run, in the first run (Java 5) I hit the famous XALAN XSLTC bug with turkish locale in the internal XALAN XSLTC processor fork *) -- This is a well-known Java 5 (XALAN XSLTC) bug and Turkish people who use XSL script know that this bug is existent, they would have seen the bug without Solr, too.
My +0.5 for the release, I would wish we fix CHANGES.txt before release - then I would give +1!
Uwe
*) See the bug, we also hit it in Lucene before: https://issues.apache.org/jira/browse/LUCENE-2685, https://issues.apache.org/jira/browse/XALANJ-2420, https://issues.apache.org/bugzilla/show_bug.cgi?id=38787 - In later Java 6 this seems fixed (although it still contains XSLTC, but they may use use newer BCEL).
[junit] java.lang.RuntimeException: Instruction unknown: load?nstruction
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.mapName(InstructionFinder.java:138)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.compilePattern(InstructionFinder.java:170)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:218)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:264)
[junit] at com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.peepHoleOptimization(Mode.java:1444)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2012 6:45 AM
> To: [EMAIL PROTECTED]
> Subject: VOTE: Lucene/Solr 3.6
>
> Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
>
> I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources on both
> source releases, tested solr example, and reviewed packaging contents
> (http://people.apache.org/~rmuir/36_review/)
>
> Here's my +1.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
I tested Lucene and Solr builds:
- The tgz files unzip fine with Linux/Cygwin tar, but with latest Windows 7-Zip Filemanager it says (when opening the inner TAR file): "data after end of tar file" (or like that). As the fixes extract correctly on Linux, I think that might be a bug in 7-Zip, but never happened with any releases before.
- URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a major problem, as this is a huge change and people used to building Lucene from source only looking into CHANGES.txt will fail to build without inspecting BUILD.txt. We have changes entries for the refactoring of the build directory structure (by Steven), but not for the Ivy change. Very bad! We must at least tell people about that in the release notes, otherwise -1.
- PANGAEA huge index checks: No VInt bugs or similar on checkindex and anywhere else (Java 1.7.0_03). Now runs in production, very nice. Not even a need to recompile the whole stuff needed, fine backwards!
- JAR files build with JDK 1.5.0_22 - That’s really nice, thanks Robert (and important in my opinion, I was missing that in previous releases).
- Binary Javadocs still Geocities-like, it's no problem, but was it not planned to use Java 7? - It's of course fine!
- Lucene Source package builds and tests fine.
- Solr Source package builds fine (I only ran the build inside solr/ folder to test this actually works)
- Solr tests ran fine on second run, in the first run (Java 5) I hit the famous XALAN XSLTC bug with turkish locale in the internal XALAN XSLTC processor fork *) -- This is a well-known Java 5 (XALAN XSLTC) bug and Turkish people who use XSL script know that this bug is existent, they would have seen the bug without Solr, too.
My +0.5 for the release, I would wish we fix CHANGES.txt before release - then I would give +1!
Uwe
*) See the bug, we also hit it in Lucene before: https://issues.apache.org/jira/browse/LUCENE-2685, https://issues.apache.org/jira/browse/XALANJ-2420, https://issues.apache.org/bugzilla/show_bug.cgi?id=38787 - In later Java 6 this seems fixed (although it still contains XSLTC, but they may use use newer BCEL).
[junit] java.lang.RuntimeException: Instruction unknown: load?nstruction
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.mapName(InstructionFinder.java:138)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.compilePattern(InstructionFinder.java:170)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:218)
[junit] at com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:264)
[junit] at com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.peepHoleOptimization(Mode.java:1444)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2012 6:45 AM
> To: [EMAIL PROTECTED]
> Subject: VOTE: Lucene/Solr 3.6
>
> Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
>
> I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources on both
> source releases, tested solr example, and reviewed packaging contents
> (http://people.apache.org/~rmuir/36_review/)
>
> Here's my +1.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 10:43
On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>
> - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a major problem, as this is a huge change and people used to building Lucene from source only looking into CHANGES.txt will fail to build without inspecting BUILD.txt. We have changes entries for the refactoring of the build directory structure (by Steven), but not for the Ivy change. Very bad! We must at least tell people about that in the release notes, otherwise -1.
>
This information is in BUILD.txt, which is where the instructions for
building are.
People building need to look at BUILD.txt, thats what this file exists for.
We don't need to duplicate documentation across *BOTH* build.txt and
changes.txt, thats ridiculous.
--
lucidimagination.com
---------------------------------------------------------------------
>
> - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a major problem, as this is a huge change and people used to building Lucene from source only looking into CHANGES.txt will fail to build without inspecting BUILD.txt. We have changes entries for the refactoring of the build directory structure (by Steven), but not for the Ivy change. Very bad! We must at least tell people about that in the release notes, otherwise -1.
>
This information is in BUILD.txt, which is where the instructions for
building are.
People building need to look at BUILD.txt, thats what this file exists for.
We don't need to duplicate documentation across *BOTH* build.txt and
changes.txt, thats ridiculous.
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 10:55
Then please remove the directory refactoring also from CHANGES.txt.
This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
---------------------
Build
* LUCENE-xxxx: Moved build system to use Apache Ivy for retrival of 3rd party JAR files.
(Robert Muir, Chris Male, Uwe Schindler,...)
---------------------
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> >
> > - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a
> major problem, as this is a huge change and people used to building Lucene
> from source only looking into CHANGES.txt will fail to build without inspecting
> BUILD.txt. We have changes entries for the refactoring of the build directory
> structure (by Steven), but not for the Ivy change. Very bad! We must at least
> tell people about that in the release notes, otherwise -1.
> >
>
> This information is in BUILD.txt, which is where the instructions for building
> are.
> People building need to look at BUILD.txt, thats what this file exists for.
> We don't need to duplicate documentation across *BOTH* build.txt and
> changes.txt, thats ridiculous.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
---------------------
Build
* LUCENE-xxxx: Moved build system to use Apache Ivy for retrival of 3rd party JAR files.
(Robert Muir, Chris Male, Uwe Schindler,...)
---------------------
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> >
> > - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a
> major problem, as this is a huge change and people used to building Lucene
> from source only looking into CHANGES.txt will fail to build without inspecting
> BUILD.txt. We have changes entries for the refactoring of the build directory
> structure (by Steven), but not for the Ivy change. Very bad! We must at least
> tell people about that in the release notes, otherwise -1.
> >
>
> This information is in BUILD.txt, which is where the instructions for building
> are.
> People building need to look at BUILD.txt, thats what this file exists for.
> We don't need to duplicate documentation across *BOTH* build.txt and
> changes.txt, thats ridiculous.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:22
On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Then please remove the directory refactoring also from CHANGES.txt.
>
> This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
>
Thats ok that we don't agree here. Fortunately, releases cannot be vetoed.
--
lucidimagination.com
---------------------------------------------------------------------
> Then please remove the directory refactoring also from CHANGES.txt.
>
> This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
>
Thats ok that we don't agree here. Fortunately, releases cannot be vetoed.
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:28
On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen <[EMAIL PROTECTED]> wrote:
> In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
>
Its a real problem: because this IPADIC license requires you have
certain notifications: "PROVIDED that the provisions of Section 3 ("NO
WARRANTY") will ALWAYS appear on, or be attached to, the Program,"
and the LICENSE.txt/NOTICE.txt needs to be at the root of the source
tree (currently solr just duplicates the lucene entries and its
solr/LICENSE.txt and solr/NOTICE.txt is intentionally placed at the
root of the whole sourcetree).
It needs to be fixed: but the question is how to fix it. patching the
solr NOTICE.txt is not acceptable I think, otherwise this will only
happen again... automation is a must here.
--
lucidimagination.com
---------------------------------------------------------------------
> In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
>
Its a real problem: because this IPADIC license requires you have
certain notifications: "PROVIDED that the provisions of Section 3 ("NO
WARRANTY") will ALWAYS appear on, or be attached to, the Program,"
and the LICENSE.txt/NOTICE.txt needs to be at the root of the source
tree (currently solr just duplicates the lucene entries and its
solr/LICENSE.txt and solr/NOTICE.txt is intentionally placed at the
root of the whole sourcetree).
It needs to be fixed: but the question is how to fix it. patching the
solr NOTICE.txt is not acceptable I think, otherwise this will only
happen again... automation is a must here.
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:35
On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> - Binary Javadocs still Geocities-like, it's no problem, but was it not planned to use Java 7? - It's of course fine!
>
Right: as i proposed originally on the list, this would be something
special I would do for the website *only*.
In my opinion its too risky to do this in the build we ship, because
it would mean i would have to compile with java7 and java5 bootstrap
classpath: of course in theory that shoudl all work, but i feel much
more comfortable building the release with an actual java 5 compiler.
--
lucidimagination.com
---------------------------------------------------------------------
> - Binary Javadocs still Geocities-like, it's no problem, but was it not planned to use Java 7? - It's of course fine!
>
Right: as i proposed originally on the list, this would be something
special I would do for the website *only*.
In my opinion its too risky to do this in the build we ship, because
it would mean i would have to compile with java7 and java5 bootstrap
classpath: of course in theory that shoudl all work, but i feel much
more comfortable building the release with an actual java 5 compiler.
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 11:35
Hi Robert,
In the case that you have to fix this one and respin, could you please also fix my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it should be mentioned with names in CHANGES.txt.
One more thing: When you extract Solr src package you are at the top-level root. In my opinion these license/info/build... files should also be placed there (including a BUILD.txt on the root!).
In my opinion, the best would be to place those files only in the root folder of SVN and the srz-tgz/bin-tgz/... tasks should add those root-level txt files also to the roots of the archives (binary and source).
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen <[EMAIL PROTECTED]> wrote:
>
> > In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find
> > a corresponding one in Solr's NOTICE.txt. Is this fine -- or should
> > this also be included as part of the "Lucene notice"? (To me it
> > sounds appropriate to also include this in Solr's NOTICE.txt.)
> >
>
> Its a real problem: because this IPADIC license requires you have certain
> notifications: "PROVIDED that the provisions of Section 3 ("NO
> WARRANTY") will ALWAYS appear on, or be attached to, the Program,"
>
> and the LICENSE.txt/NOTICE.txt needs to be at the root of the source tree
> (currently solr just duplicates the lucene entries and its solr/LICENSE.txt and
> solr/NOTICE.txt is intentionally placed at the root of the whole sourcetree).
>
> It needs to be fixed: but the question is how to fix it. patching the solr
> NOTICE.txt is not acceptable I think, otherwise this will only happen again...
> automation is a must here.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
In the case that you have to fix this one and respin, could you please also fix my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it should be mentioned with names in CHANGES.txt.
One more thing: When you extract Solr src package you are at the top-level root. In my opinion these license/info/build... files should also be placed there (including a BUILD.txt on the root!).
In my opinion, the best would be to place those files only in the root folder of SVN and the srz-tgz/bin-tgz/... tasks should add those root-level txt files also to the roots of the archives (binary and source).
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen <[EMAIL PROTECTED]> wrote:
>
> > In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find
> > a corresponding one in Solr's NOTICE.txt. Is this fine -- or should
> > this also be included as part of the "Lucene notice"? (To me it
> > sounds appropriate to also include this in Solr's NOTICE.txt.)
> >
>
> Its a real problem: because this IPADIC license requires you have certain
> notifications: "PROVIDED that the provisions of Section 3 ("NO
> WARRANTY") will ALWAYS appear on, or be attached to, the Program,"
>
> and the LICENSE.txt/NOTICE.txt needs to be at the root of the source tree
> (currently solr just duplicates the lucene entries and its solr/LICENSE.txt and
> solr/NOTICE.txt is intentionally placed at the root of the whole sourcetree).
>
> It needs to be fixed: but the question is how to fix it. patching the solr
> NOTICE.txt is not acceptable I think, otherwise this will only happen again...
> automation is a must here.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Martijn v Groningen 2012-04-06, 11:37
Hi,
A few days ago Cody Young discovered a bug in Solr's distributed grouping
(SOLR-3316). This bug also occurs in the 3x code.
I attached a bug fix in the issue. I think it is an important bug fix. Can
I commit the fix to branch3x or is it already too late?
Martijn
On 6 April 2012 13:35, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>
> > - Binary Javadocs still Geocities-like, it's no problem, but was it not
> planned to use Java 7? - It's of course fine!
> >
>
> Right: as i proposed originally on the list, this would be something
> special I would do for the website *only*.
>
> In my opinion its too risky to do this in the build we ship, because
> it would mean i would have to compile with java7 and java5 bootstrap
> classpath: of course in theory that shoudl all work, but i feel much
> more comfortable building the release with an actual java 5 compiler.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen
>
> <[EMAIL PROTECTED]>
>
A few days ago Cody Young discovered a bug in Solr's distributed grouping
(SOLR-3316). This bug also occurs in the 3x code.
I attached a bug fix in the issue. I think it is an important bug fix. Can
I commit the fix to branch3x or is it already too late?
Martijn
On 6 April 2012 13:35, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>
> > - Binary Javadocs still Geocities-like, it's no problem, but was it not
> planned to use Java 7? - It's of course fine!
> >
>
> Right: as i proposed originally on the list, this would be something
> special I would do for the website *only*.
>
> In my opinion its too risky to do this in the build we ship, because
> it would mean i would have to compile with java7 and java5 bootstrap
> classpath: of course in theory that shoudl all work, but i feel much
> more comfortable building the release with an actual java 5 compiler.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen
>
> <[EMAIL PROTECTED]>
>
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:37
On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> In the case that you have to fix this one and respin, could you please also fix my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it should be mentioned with names in CHANGES.txt.
>
> One more thing: When you extract Solr src package you are at the top-level root. In my opinion these license/info/build... files should also be placed there (including a BUILD.txt on the root!).
>
we aren't doing this.
We put license.txt/notice.txt at the root only because we are legally
required to do so.
--
lucidimagination.com
---------------------------------------------------------------------
> Hi Robert,
>
> In the case that you have to fix this one and respin, could you please also fix my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it should be mentioned with names in CHANGES.txt.
>
> One more thing: When you extract Solr src package you are at the top-level root. In my opinion these license/info/build... files should also be placed there (including a BUILD.txt on the root!).
>
we aren't doing this.
We put license.txt/notice.txt at the root only because we are legally
required to do so.
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 11:39
I agree. I would have build only the javadocs with java 7, the rest with Java 5.
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>
> > - Binary Javadocs still Geocities-like, it's no problem, but was it not planned to
> use Java 7? - It's of course fine!
> >
>
> Right: as i proposed originally on the list, this would be something special I
> would do for the website *only*.
>
> In my opinion its too risky to do this in the build we ship, because it would mean
> i would have to compile with java7 and java5 bootstrap
> classpath: of course in theory that shoudl all work, but i feel much more
> comfortable building the release with an actual java 5 compiler.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>
> > - Binary Javadocs still Geocities-like, it's no problem, but was it not planned to
> use Java 7? - It's of course fine!
> >
>
> Right: as i proposed originally on the list, this would be something special I
> would do for the website *only*.
>
> In my opinion its too risky to do this in the build we ship, because it would mean
> i would have to compile with java7 and java5 bootstrap
> classpath: of course in theory that shoudl all work, but i feel much more
> comfortable building the release with an actual java 5 compiler.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:40
On Fri, Apr 6, 2012 at 7:37 AM, Martijn v Groningen
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> A few days ago Cody Young discovered a bug in Solr's distributed grouping
> (SOLR-3316). This bug also occurs in the 3x code.
> I attached a bug fix in the issue. I think it is an important bug fix. Can I
> commit the fix to branch3x or is it already too late?
>
Hi Martijn, i will have to respin the RC to fix the legal problem that
Christian found anyway, however we shouldnt add any unnecessary
changes at the same time just because i'm respinning, that can
destabilize an otherwise stable release.
On the other hand, if its a blocker bug and the fix is safe, then set
that issue to blocker and we can have more eyes on the patch...
--
lucidimagination.com
---------------------------------------------------------------------
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> A few days ago Cody Young discovered a bug in Solr's distributed grouping
> (SOLR-3316). This bug also occurs in the 3x code.
> I attached a bug fix in the issue. I think it is an important bug fix. Can I
> commit the fix to branch3x or is it already too late?
>
Hi Martijn, i will have to respin the RC to fix the legal problem that
Christian found anyway, however we shouldnt add any unnecessary
changes at the same time just because i'm respinning, that can
destabilize an otherwise stable release.
On the other hand, if its a blocker bug and the fix is safe, then set
that issue to blocker and we can have more eyes on the patch...
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 11:40
It was a suggestion, no critisism. Why do you attack me?
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >
> > In the case that you have to fix this one and respin, could you please also fix
> my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
> should be mentioned with names in CHANGES.txt.
> >
>
>
> > One more thing: When you extract Solr src package you are at the top-level
> root. In my opinion these license/info/build... files should also be placed there
> (including a BUILD.txt on the root!).
> >
>
> we aren't doing this.
>
> We put license.txt/notice.txt at the root only because we are legally required to
> do so.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >
> > In the case that you have to fix this one and respin, could you please also fix
> my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
> should be mentioned with names in CHANGES.txt.
> >
>
>
> > One more thing: When you extract Solr src package you are at the top-level
> root. In my opinion these license/info/build... files should also be placed there
> (including a BUILD.txt on the root!).
> >
>
> we aren't doing this.
>
> We put license.txt/notice.txt at the root only because we are legally required to
> do so.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:42
The problem is: duplication of documentation is dangerous and only
creates more work for the RM.
if we start duplicating things like build instructions across both
BUILD.txt and CHANGES.txt, or whole text files, then its only a matter
of time before someone says in the next release vote:
XYZ is mentioned in foo/BUILD.txt but this is inconsistent with
foo/CHANGES.txt or XYZ/BUILD.txt is out of date with respect to
/BUILD.txt
On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> It was a suggestion, no critisism. Why do you attack me?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [EMAIL PROTECTED]
>
>
>> -----Original Message-----
>> From: Robert Muir [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, April 06, 2012 1:37 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: VOTE: Lucene/Solr 3.6
>>
>> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>> > Hi Robert,
>> >
>> > In the case that you have to fix this one and respin, could you please also fix
>> my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
>> should be mentioned with names in CHANGES.txt.
>> >
>>
>>
>> > One more thing: When you extract Solr src package you are at the top-level
>> root. In my opinion these license/info/build... files should also be placed there
>> (including a BUILD.txt on the root!).
>> >
>>
>> we aren't doing this.
>>
>> We put license.txt/notice.txt at the root only because we are legally required to
>> do so.
>>
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
>> commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
lucidimagination.com
---------------------------------------------------------------------
creates more work for the RM.
if we start duplicating things like build instructions across both
BUILD.txt and CHANGES.txt, or whole text files, then its only a matter
of time before someone says in the next release vote:
XYZ is mentioned in foo/BUILD.txt but this is inconsistent with
foo/CHANGES.txt or XYZ/BUILD.txt is out of date with respect to
/BUILD.txt
On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> It was a suggestion, no critisism. Why do you attack me?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [EMAIL PROTECTED]
>
>
>> -----Original Message-----
>> From: Robert Muir [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, April 06, 2012 1:37 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: VOTE: Lucene/Solr 3.6
>>
>> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>> > Hi Robert,
>> >
>> > In the case that you have to fix this one and respin, could you please also fix
>> my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
>> should be mentioned with names in CHANGES.txt.
>> >
>>
>>
>> > One more thing: When you extract Solr src package you are at the top-level
>> root. In my opinion these license/info/build... files should also be placed there
>> (including a BUILD.txt on the root!).
>> >
>>
>> we aren't doing this.
>>
>> We put license.txt/notice.txt at the root only because we are legally required to
>> do so.
>>
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
>> commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 11:47
Hi Robert,
Read 3 lines below the comment you replied to:
My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the SVN root (directly under trunk), remove them from Lucene/Solr/modules subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a separate fileset to the root of *every* created archive.
Does this sound like a plan? No duplication in the source, but every ZIP/TGZ file (if its src or bin doesn’t matter) gets all legal information and build instructions (for src only).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> The problem is: duplication of documentation is dangerous and only creates
> more work for the RM.
>
> if we start duplicating things like build instructions across both BUILD.txt and
> CHANGES.txt, or whole text files, then its only a matter of time before someone
> says in the next release vote:
>
> XYZ is mentioned in foo/BUILD.txt but this is inconsistent with foo/CHANGES.txt
> or XYZ/BUILD.txt is out of date with respect to /BUILD.txt
>
> On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > It was a suggestion, no critisism. Why do you attack me?
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: [EMAIL PROTECTED]
> >
> >
> >> -----Original Message-----
> >> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> >> Sent: Friday, April 06, 2012 1:37 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: VOTE: Lucene/Solr 3.6
> >>
> >> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> >> > Hi Robert,
> >> >
> >> > In the case that you have to fix this one and respin, could you
> >> > please also fix
> >> my CHANGES.txt complaint? The Ivy changes were such a huge piece of
> >> work, it should be mentioned with names in CHANGES.txt.
> >> >
> >>
> >>
> >> > One more thing: When you extract Solr src package you are at the
> >> > top-level
> >> root. In my opinion these license/info/build... files should also be
> >> placed there (including a BUILD.txt on the root!).
> >> >
> >>
> >> we aren't doing this.
> >>
> >> We put license.txt/notice.txt at the root only because we are legally
> >> required to do so.
> >>
> >>
> >> --
> >> lucidimagination.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >> additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Read 3 lines below the comment you replied to:
My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the SVN root (directly under trunk), remove them from Lucene/Solr/modules subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a separate fileset to the root of *every* created archive.
Does this sound like a plan? No duplication in the source, but every ZIP/TGZ file (if its src or bin doesn’t matter) gets all legal information and build instructions (for src only).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> The problem is: duplication of documentation is dangerous and only creates
> more work for the RM.
>
> if we start duplicating things like build instructions across both BUILD.txt and
> CHANGES.txt, or whole text files, then its only a matter of time before someone
> says in the next release vote:
>
> XYZ is mentioned in foo/BUILD.txt but this is inconsistent with foo/CHANGES.txt
> or XYZ/BUILD.txt is out of date with respect to /BUILD.txt
>
> On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > It was a suggestion, no critisism. Why do you attack me?
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: [EMAIL PROTECTED]
> >
> >
> >> -----Original Message-----
> >> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> >> Sent: Friday, April 06, 2012 1:37 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: VOTE: Lucene/Solr 3.6
> >>
> >> On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> >> > Hi Robert,
> >> >
> >> > In the case that you have to fix this one and respin, could you
> >> > please also fix
> >> my CHANGES.txt complaint? The Ivy changes were such a huge piece of
> >> work, it should be mentioned with names in CHANGES.txt.
> >> >
> >>
> >>
> >> > One more thing: When you extract Solr src package you are at the
> >> > top-level
> >> root. In my opinion these license/info/build... files should also be
> >> placed there (including a BUILD.txt on the root!).
> >> >
> >>
> >> we aren't doing this.
> >>
> >> We put license.txt/notice.txt at the root only because we are legally
> >> required to do so.
> >>
> >>
> >> --
> >> lucidimagination.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >> additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 11:50
On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> Read 3 lines below the comment you replied to:
> My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the SVN root (directly under trunk), remove them from Lucene/Solr/modules subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a separate fileset to the root of *every* created archive.
>
> Does this sound like a plan? No duplication in the source, but every ZIP/TGZ file (if its src or bin doesn’t matter) gets all legal information and build instructions (for src only).
Its absolutely not a plan. Because then lucene has shit in its
LICENSE.txt and NOTICE.txt that don't apply to it.
--
lucidimagination.com
---------------------------------------------------------------------
> Hi Robert,
>
> Read 3 lines below the comment you replied to:
> My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the SVN root (directly under trunk), remove them from Lucene/Solr/modules subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a separate fileset to the root of *every* created archive.
>
> Does this sound like a plan? No duplication in the source, but every ZIP/TGZ file (if its src or bin doesn’t matter) gets all legal information and build instructions (for src only).
Its absolutely not a plan. Because then lucene has shit in its
LICENSE.txt and NOTICE.txt that don't apply to it.
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: VOTE: Lucene/Solr 3.6Uwe Schindler 2012-04-06, 11:55
JAJA.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >
> > Read 3 lines below the comment you replied to:
> > My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the
> SVN root (directly under trunk), remove them from Lucene/Solr/modules
> subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a
> separate fileset to the root of *every* created archive.
> >
> > Does this sound like a plan? No duplication in the source, but every ZIP/TGZ
> file (if its src or bin doesn’t matter) gets all legal information and build
> instructions (for src only).
>
> Its absolutely not a plan. Because then lucene has shit in its LICENSE.txt and
> NOTICE.txt that don't apply to it.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2012 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: VOTE: Lucene/Solr 3.6
>
> On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >
> > Read 3 lines below the comment you replied to:
> > My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the
> SVN root (directly under trunk), remove them from Lucene/Solr/modules
> subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a
> separate fileset to the root of *every* created archive.
> >
> > Does this sound like a plan? No duplication in the source, but every ZIP/TGZ
> file (if its src or bin doesn’t matter) gets all legal information and build
> instructions (for src only).
>
> Its absolutely not a plan. Because then lucene has shit in its LICENSE.txt and
> NOTICE.txt that don't apply to it.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 12:12
On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen <[EMAIL PROTECTED]> wrote:
> Hello again Robert,
>
> I've been doing some end-to-end testing on Kuromoji using the release candidate build and things look good to me.
>
> I've also done the testing described on SOLR-3282 earlier using a branch_3x build from last week. That also looks good.
>
> I have one legal question:
>
> In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
Thanks again Christian: i created
https://issues.apache.org/jira/browse/SOLR-3331
I think for 3.6 its absolutely necessary the smokeTester check this,
so that its not manual inspection.
Solr has too many dependencies to put this burden on the RM to review
that this stuff is in sync by hand.
we can later extend this to modules in 4.0 if we want, or we can do
something else, thats a separate discussion.
--
lucidimagination.com
---------------------------------------------------------------------
> Hello again Robert,
>
> I've been doing some end-to-end testing on Kuromoji using the release candidate build and things look good to me.
>
> I've also done the testing described on SOLR-3282 earlier using a branch_3x build from last week. That also looks good.
>
> I have one legal question:
>
> In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a corresponding one in Solr's NOTICE.txt. Is this fine -- or should this also be included as part of the "Lucene notice"? (To me it sounds appropriate to also include this in Solr's NOTICE.txt.)
Thanks again Christian: i created
https://issues.apache.org/jira/browse/SOLR-3331
I think for 3.6 its absolutely necessary the smokeTester check this,
so that its not manual inspection.
Solr has too many dependencies to put this burden on the RM to review
that this stuff is in sync by hand.
we can later extend this to modules in 4.0 if we want, or we can do
something else, thats a separate discussion.
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: VOTE: Lucene/Solr 3.6Walter Underwood 2012-04-06, 13:15
Other changes to the build have been mentioned in CHANGES.txt. --wunder
On Apr 6, 2012, at 4:22 AM, Robert Muir wrote:
> On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>> Then please remove the directory refactoring also from CHANGES.txt.
>>
>> This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
>>
>
> Thats ok that we don't agree here. Fortunately, releases cannot be vetoed.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
On Apr 6, 2012, at 4:22 AM, Robert Muir wrote:
> On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>> Then please remove the directory refactoring also from CHANGES.txt.
>>
>> This is still a blocker to me. It should not be *documented* in the CHNAGES.txt, I said it should be mentione:
>>
>
> Thats ok that we don't agree here. Fortunately, releases cannot be vetoed.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
Re: VOTE: Lucene/Solr 3.6Robert Muir 2012-04-06, 13:48
On Fri, Apr 6, 2012 at 9:15 AM, Walter Underwood <[EMAIL PROTECTED]> wrote:
> Other changes to the build have been mentioned in CHANGES.txt. --wunder
>
Doesn't matter. As release manager I have to be extremely careful
about which changes go in and which don't.
Licensing/Legal stuff: respin with no questions.
Packaging bugs: if its a serious problem, we need it fixed.
bugs in the code: case by case basis depending upon severity and risk
of the patch
Missing documentation: welcome to lucene/solr :).
Can't just let any old documentation patch go through, because it
itself can create additional documentation bugs.
Not to pick on Uwe but see his first patch to the issue he created for
this (https://issues.apache.org/jira/browse/LUCENE-3962)
Had I not reviewed this, it would have only *added confusion* to the
solr release.
--
lucidimagination.com
---------------------------------------------------------------------
> Other changes to the build have been mentioned in CHANGES.txt. --wunder
>
Doesn't matter. As release manager I have to be extremely careful
about which changes go in and which don't.
Licensing/Legal stuff: respin with no questions.
Packaging bugs: if its a serious problem, we need it fixed.
bugs in the code: case by case basis depending upon severity and risk
of the patch
Missing documentation: welcome to lucene/solr :).
Can't just let any old documentation patch go through, because it
itself can create additional documentation bugs.
Not to pick on Uwe but see his first patch to the issue he created for
this (https://issues.apache.org/jira/browse/LUCENE-3962)
Had I not reviewed this, it would have only *added confusion* to the
solr release.
--
lucidimagination.com
---------------------------------------------------------------------
