Grokbase Groups Lucene dev April 2012
FAQ
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Search Discussions

  • Dawid Weiss at Apr 5, 2012 at 7:33 am
    - Checked Solr example and clustering part, looks good and works.
    - Checked lucene-src, compiled from sources, worked.

    Dawid
    On Thu, Apr 5, 2012 at 6:45 AM, 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Steven A Rowe at Apr 5, 2012 at 3:04 pm
    I was looking at the noggit and commons-csv sources that got included in Solr's sources in r1306796 as part of LUCENE-3930, and I can see @author tags in multiple .java files. A quick search reveals that there are other cases of this outside of noggit and commons-csv.

    I'm not sure if this is important enough to warrant a re-spin.

    Steve

    -----Original Message-----
    From: Robert Muir
    Sent: Thursday, April 05, 2012 12:45 AM
    To: dev@lucene.apache.org
    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: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 5, 2012 at 3:08 pm
    nice find.

    can we open an issue to:
    1. fix all @author tags
    2. look for @author like nocommit in hudson and fail on it

    On Thu, Apr 5, 2012 at 11:04 AM, Steven A Rowe wrote:
    I was looking at the noggit and commons-csv sources that got included in Solr's sources in r1306796 as part of LUCENE-3930, and I can see @author tags in multiple .java files.  A quick search reveals that there are other cases of this outside of noggit and commons-csv.

    I'm not sure if this is important enough to warrant a re-spin.

    Steve

    -----Original Message-----
    From: Robert Muir
    Sent: Thursday, April 05, 2012 12:45 AM
    To: dev@lucene.apache.org
    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: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org


    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Yonik Seeley at Apr 5, 2012 at 3:10 pm

    On Thu, Apr 5, 2012 at 11:04 AM, Steven A Rowe wrote:
    I was looking at the noggit and commons-csv sources that got included in Solr's sources in r1306796 as part of LUCENE-3930, and I can see @author tags in multiple .java files.  A quick search reveals that there are other cases of this outside of noggit and commons-csv.

    I'm not sure if this is important enough to warrant a re-spin.
    Nah - these are not prohibited, just not "best practice".
    And in the case where we are copying other source verbatim, just
    because we don't want to include a jar, we should prob avoid
    unnecessary modifications anyway.

    -Yonik
    lucenerevolution.com - Lucene/Solr Open Source Search Conference.
    Boston May 7-10

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Christian Moen at Apr 5, 2012 at 3:26 pm
    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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Dawid Weiss at Apr 5, 2012 at 3:56 pm
    Great work getting everything ready and reworking the build system as well.
    +1. This is a major effort you've put into it; very much appreciated.

    Dawid

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Michael McCandless at Apr 5, 2012 at 4:57 pm

    On Thu, Apr 5, 2012 at 11:55 AM, Dawid Weiss wrote:
    Great work getting everything ready and reworking the build system as well.
    +1. This is a major effort you've put into it; very much appreciated.
    +1!

    Mike McCandless

    http://blog.mikemccandless.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Christian Moen at Apr 6, 2012 at 8:59 am
    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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:29 am

    On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 11:35 am
    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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:28 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:37 am

    On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 11:40 am
    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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:37 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:43 am
    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 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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:37 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org


    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 11:46 am
    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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:42 PM
    To: dev@lucene.apache.org
    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 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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:37 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For
    additional commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
    additional commands, e-mail: dev-help@lucene.apache.org


    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:51 am

    On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 11:55 am
    JAJA.

    -----
    Uwe Schindler
    H.-H.-Meier-Allee 63, D-28213 Bremen
    http://www.thetaphi.de
    eMail: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:51 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 12:12 pm

    On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen 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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Chris Hostetter at Apr 5, 2012 at 7:46 pm
    : Please vote to release these artifacts: http://s.apache.org/lusolr36rc0

    +1

    I encountered a few very nit-picky problems, mostly related to
    Solr->Lucene javadocs linkage -- but as long as we upload the lucene
    javadocs to where the the solr releases are linking when the release is
    official, there's nothing actually "broken"

    ###### Short summary of nit-picks...

    * "ant compile" in lucene src artifacts builds jars for some contribs not
    all -- kind of confusing. I did a double take before i realized i
    needed "build-contrib" to get them all and the ones i was seeing were just
    because of cross-contrb dependencies
    * solr bin artifacts have javadocs linking to url that currently 404s:
    http://lucene.apache.org/java/3_6_0/api/all/
    * generating javadocs from solr src artifacts causes the solr javadocs to
    default link to: https://builds.apache.org/job/Lucene-3.x/javadoc/all/
    trivial for the user to change with a build property (SOLR-3323)
    * in the solr src releases, some shell scripts are not executable by
    default.

    ###### sha1 for all of the files tested...

    1b9e06c807cc2d089b4a3fce09a6f17ba4275e85 *apache-solr-3.6.0-src.tgz
    93fac0aa78c10c72ae5366f017c8aa0d5525f567 *apache-solr-3.6.0.tgz
    af79f05d5b9fd0b48beef3f2e2c4b1b77700dfe8 *apache-solr-3.6.0.zip
    c9dc43cb2f799fd11786d92781687b66598d7e14 *lucene-3.6.0-src.tgz
    a4deb3b07e6d6bad8647f75f0b4a1981ee8f7a98 *lucene-3.6.0.tgz
    c2709f4756c8ea380ca5a4d450068ee0142ebaf5 *lucene-3.6.0.zip

    ###### Notes from my testing...


    ### Lucene tgz bin build...

    * md5 & sha1 checks out
    * contents look ok
    * docs look good
    * demo runs correctly per docs

    ### Lucene zip bin build...

    * md5 & sha1 checks out
    * contents look ok
    * docs look good
    * demo runs correctly per docs

    ### Lucene src build...

    * md5 & sha1 checks out
    * contents look ok
    * ivy-bootstrap works
    * ant clean compile javadocs test
    * test pass
    * javadocs look good
    * !! jars are built for some contribs but not all??
    * ant build-contrib
    * demo runs correctly per docs
    * ant package-all-binary
    * re-ran demo using zip built from source
    * demo worked correctly

    ### Solr tgz bin build...

    * md5 & sha1 checks out
    * contents look ok
    * docs look mostly good
    * !! javadocs attempt to link to: http://lucene.apache.org/java/3_6_0/api/all/
    * !! currently redirects to: http://lucene.apache.org/core/old_versioned_docs/versions/3_6_0/api/all/
    * presumably one of these will work once 3.6 goes live?
    * example works, tutorial runs as described

    ### Solr zip bin build...

    * md5 & sha1 checks out
    * contents look ok
    * docs mostly look good
    * !! javadocs attempt to link to: http://lucene.apache.org/java/3_6_0/api/all/
    * !! currently redirects to: http://lucene.apache.org/core/old_versioned_docs/versions/3_6_0/api/all/
    * presumably one of these will work once 3.6 goes live?
    * example works, tutorial runs as described

    ### Solr src build...

    * md5 & sha1 checks out
    * contents look ok
    * !! post.sh and test_utf8.sh are not executable .. not worth worrying about
    * ivy-bootstrap works
    * ant clean compile javadocs test
    * tests pass
    * javadocs mostly look good
    * !! javadocs link to: https://builds.apache.org/job/Lucene-3.x/javadoc/all/
    * links work, shouldn't be a big deal
    * easy for user to override
    * ant example
    * example works, tutorial runs as described



    -Hoss

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 5, 2012 at 7:54 pm

    On Thu, Apr 5, 2012 at 3:46 PM, Chris Hostetter wrote:

    : Please vote to release these artifacts: http://s.apache.org/lusolr36rc0

    +1

    I encountered a few very nit-picky problems, mostly related to
    Solr->Lucene javadocs linkage -- but as long as we upload the lucene
    javadocs to where the the solr releases are linking when the release is
    official, there's nothing actually "broken"

    ###### Short summary of nit-picks...

    * "ant compile" in lucene src artifacts builds jars for some contribs not
    all -- kind of confusing.  I did a double take before i realized i
    needed "build-contrib" to get them all and the ones i was seeing were just
    because of cross-contrb dependencies
    where did you get this target name 'compile' from? Is it listed in any
    of our documentation that this target should even work?
    its not a 'public target' listed in ant -p....


    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Chris Hostetter at Apr 5, 2012 at 8:06 pm
    : >  * "ant compile" in lucene src artifacts builds jars for some contribs not

    : where did you get this target name 'compile' from? Is it listed in any
    : of our documentation that this target should even work?
    : its not a 'public target' listed in ant -p....

    Heh... sorry. pure muscle memory from years of usage.

    Ignore "compile" ... "ant test" has the same result -- jars are built for
    some contribs, but not all -- which is kind of confusing when you run all
    the tests, and then go look for the demo but it's not there.

    But like i said -- not a big deal, we have a documented "build-contribs"

    -Hoss
  • Robert Muir at Apr 5, 2012 at 8:09 pm

    On Thu, Apr 5, 2012 at 4:05 PM, Chris Hostetter wrote:
    Ignore "compile" ... "ant test" has the same result -- jars are built for
    some contribs, but not all -- which is kind of confusing when you run all
    the tests, and then go look for the demo but it's not there.
    ant test really shouldnt build any jars at all :)


    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Chris Hostetter at Apr 5, 2012 at 8:13 pm
    : > Ignore "compile" ... "ant test" has the same result -- jars are built for
    : > some contribs, but not all -- which is kind of confusing when you run all
    : > the tests, and then go look for the demo but it's not there.
    : >
    :
    : ant test really shouldnt build any jars at all :)

    that's my point -- it's a side effect of some contribs building other
    contibs so they can use hte jars in their classpaths for tests -- but
    because it doesn't consistently build them all, it gave me a double take
    -- i thought i had the contrib jars all built (because i could see some),
    but then i realized they werent' all there.

    hence my "working correctly, but slightly confusing" point.

    (perhaps for 4.0 we should consider always jaring when we compile? .. so
    you never have *.class files built w/o them being in a jar?)

    -Hoss

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 5, 2012 at 8:15 pm

    On Thu, Apr 5, 2012 at 4:12 PM, Chris Hostetter wrote:

    : > Ignore "compile" ... "ant test" has the same result -- jars are built for
    : > some contribs, but not all -- which is kind of confusing when you run all
    : > the tests, and then go look for the demo but it's not there.
    : >
    :
    : ant test really shouldnt build any jars at all :)
    (perhaps for 4.0 we should consider always jaring when we compile? .. so
    you never have *.class files built w/o them being in a jar?)
    no my point is we should always try to avoid jarring for tests, it
    slows down the build
    tremendously to jar and rejar things. tests dont need nor use jars,
    they only need
    the class files in their test classpath...

    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Steven A Rowe at Apr 5, 2012 at 8:03 pm
    +1 to release

    I ran dev-tools/scripts/smokeTestRelease.py against the RC on Windows 7 under Cygwin and it passes for me. For Java6 I used my installed Oracle/Sun v1.6.0_21 instead of the v1.6.0_27 referenced in the checked-in smokeTestRelease.py.

    Steve

    -----Original Message-----
    From: Robert Muir
    Sent: Thursday, April 05, 2012 12:45 AM
    To: dev@lucene.apache.org
    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: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org
  • Smiley, David W. at Apr 5, 2012 at 9:03 pm
    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, 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?

    Speaking of deprecations, since this may be the last 3.x version, this means now is the time to send the right message to users on what may go away in a future Solr release. It's not clear to me if Solr 4 needs to guarantee compatibility with a Solr 3 configuration file or just aim for a likely probability of compatibility.

    ~ David
    On Apr 5, 2012, at 12:45 AM, 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 5, 2012 at 9:22 pm

    On Thu, Apr 5, 2012 at 5:03 PM, Smiley, David W. 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.
    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.

    --
    lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Smiley, David W. at Apr 5, 2012 at 9:43 pm

    On Apr 5, 2012, at 5:22 PM, Robert Muir wrote:
    On Thu, Apr 5, 2012 at 5:03 PM, Smiley, David W. 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
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 5, 2012 at 9:46 pm

    On Thu, Apr 5, 2012 at 5:42 PM, Smiley, David W. 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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Mark Miller at Apr 5, 2012 at 10:05 pm

    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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Tommaso Teofili at Apr 6, 2012 at 7:18 am
    +1 for the release and I agree with Mark and Robert's points.
    Tommaso

    2012/4/6 Mark Miller <markrmiller@gmail.com>
    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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Andi Vajda at Apr 5, 2012 at 11:11 pm

    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..

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 10:35 am
    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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Thursday, April 05, 2012 6:45 AM
    To: dev@lucene.apache.org
    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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 10:43 am

    On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 10:55 am
    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: uwe@thetaphi.de

    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 12:43 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:22 am

    On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Walter Underwood at Apr 6, 2012 at 1:15 pm
    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 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 1:49 pm

    On Fri, Apr 6, 2012 at 9:15 AM, Walter Underwood 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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir at Apr 6, 2012 at 11:36 am

    On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Martijn v Groningen at Apr 6, 2012 at 11:38 am
    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 wrote:
    On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

    --
    Met vriendelijke groet,

    Martijn van Groningen

    <dev-help@lucene.apache.org>
  • Robert Muir at Apr 6, 2012 at 11:41 am

    On Fri, Apr 6, 2012 at 7:37 AM, Martijn v Groningen 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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler at Apr 6, 2012 at 11:39 am
    I agree. I would have build only the javadocs with java 7, the rest with Java 5.
    -----Original Message-----
    From: Robert Muir
    Sent: Friday, April 06, 2012 1:36 PM
    To: dev@lucene.apache.org
    Subject: Re: VOTE: Lucene/Solr 3.6
    On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler 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: dev-unsubscribe@lucene.apache.org For additional
    commands, e-mail: dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

Related Discussions

People

Translate

site design / logo © 2021 Grokbase