[VOTE] Set Solr 1.3 freeze and release date

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Set Solr 1.3 freeze and release date

Grant Ingersoll-2
Well, we've been beating around the bush on 1.3 for a good amount of  
time now.   How about we set a date and actually vote on it and thus  
make it pseudo-binding?

I see that we have 13 issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486

SOLR-410: Review the ResponseBuilder class.  My take is this can be  
closed.  We've (Solr that is) been running w/ it for a while now.

SOLR-545: Remove Default core in multicore.  No patch available.

SOLR-243: Create a hook to bring in custom IndexReaders.  This patch  
made a lot of progress, but then seems to be abandoned once unit tests  
were asked for.  I suggest moving to 1.4

SOLR-624: Don't take snapshot if no diffs.  Sounds ready to be committed

SOLR-630: Spellchecker should not be case-sensitive and should be  
stopwords aware.  No patch available or unit tests.  Seems like it  
could be handled through analysis, but not sure.

SOLR-506:  Enabling HTTP Cache Headers should be configurable.  Sounds  
ready to commit, right Shalin?

SOLR-653: remove overwrite command.  Sounds ready to commit

SOLR-474: Audit docs for spellchecker Mike Klaas says he will take  
care of it.

SOLR-646: Config. props in multicore.xml  Seems really useful, but is  
currently unassigned.

SOLR-619: Dynamic copyField at runtime.  Rumor has it's completed...

SOLR-614: Allow components to read any kind of XML.  Has a couple of  
-1 on it that have been changed to -0

SOLR-489: Add deprecation docs.  Last updated on the 4th.  Needs  
review and should go in

So, what to vote on?

0.  Accept no more issues outside of this list, other than blockers  
for 1.3.
1.   Set August 12 as code freeze date.  1 week from today.  After  
which, only doc changes and blockers are allowed.   So, if the above  
isn't fixed by then, it's out unless someone wants to make it a blocker.
2.   Code Freeze in effect for 5 days for testing of release  
candidates.  Thus, the 1.3 release, assuming all goes well will be on  
the 17th or 18th (since the 17th is a Sunday.)  Thus SOLR-489 in  
theory need not be complete by the 12th, but the 18th instead,  
although we might as well get it done.

What this means?  Speak up now, unassign yourself, or otherwise "git  
'r done" if you care about one of these issues.

I volunteer to be the release manager, unless someone else is dying to  
do it.

Cheers,
Grant




Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Ryan McKinley-2
>
> SOLR-545: Remove Default core in multicore.  No patch available.
>
> SOLR-646: Config. props in multicore.xml  Seems really useful, but  
> is currently unassigned.
>

I'm on these guys.


>
> 0.  Accept no more issues outside of this list, other than blockers  
> for 1.3.

+1

>
> 1.   Set August 12 as code freeze date.  1 week from today.  After  
> which, only doc changes and blockers are allowed.   So, if the above  
> isn't fixed by then, it's out unless someone wants to make it a  
> blocker.

+1

>
> 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.  Thus, the 1.3 release, assuming all goes well will be  
> on the 17th or 18th (since the 17th is a Sunday.)  Thus SOLR-489 in  
> theory need not be complete by the 12th, but the 18th instead,  
> although we might as well get it done.
>

+1


> What this means?  Speak up now, unassign yourself, or otherwise "git  
> 'r done" if you care about one of these issues.
>
> I volunteer to be the release manager, unless someone else is dying  
> to do it.

thanks!
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Otis Gospodnetic-2
In reply to this post by Grant Ingersoll-2
May the force be with you.  +1

 
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch



----- Original Message ----

> From: Grant Ingersoll <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, August 5, 2008 3:46:26 PM
> Subject: [VOTE] Set Solr 1.3 freeze and release date
>
> Well, we've been beating around the bush on 1.3 for a good amount of  
> time now.   How about we set a date and actually vote on it and thus  
> make it pseudo-binding?
>
> I see that we have 13 issues:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486
>
> SOLR-410: Review the ResponseBuilder class.  My take is this can be  
> closed.  We've (Solr that is) been running w/ it for a while now.
>
> SOLR-545: Remove Default core in multicore.  No patch available.
>
> SOLR-243: Create a hook to bring in custom IndexReaders.  This patch  
> made a lot of progress, but then seems to be abandoned once unit tests  
> were asked for.  I suggest moving to 1.4
>
> SOLR-624: Don't take snapshot if no diffs.  Sounds ready to be committed
>
> SOLR-630: Spellchecker should not be case-sensitive and should be  
> stopwords aware.  No patch available or unit tests.  Seems like it  
> could be handled through analysis, but not sure.
>
> SOLR-506:  Enabling HTTP Cache Headers should be configurable.  Sounds  
> ready to commit, right Shalin?
>
> SOLR-653: remove overwrite command.  Sounds ready to commit
>
> SOLR-474: Audit docs for spellchecker Mike Klaas says he will take  
> care of it.
>
> SOLR-646: Config. props in multicore.xml  Seems really useful, but is  
> currently unassigned.
>
> SOLR-619: Dynamic copyField at runtime.  Rumor has it's completed...
>
> SOLR-614: Allow components to read any kind of XML.  Has a couple of  
> -1 on it that have been changed to -0
>
> SOLR-489: Add deprecation docs.  Last updated on the 4th.  Needs  
> review and should go in
>
> So, what to vote on?
>
> 0.  Accept no more issues outside of this list, other than blockers  
> for 1.3.
> 1.   Set August 12 as code freeze date.  1 week from today.  After  
> which, only doc changes and blockers are allowed.   So, if the above  
> isn't fixed by then, it's out unless someone wants to make it a blocker.
> 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.  Thus, the 1.3 release, assuming all goes well will be on  
> the 17th or 18th (since the 17th is a Sunday.)  Thus SOLR-489 in  
> theory need not be complete by the 12th, but the 18th instead,  
> although we might as well get it done.
>
> What this means?  Speak up now, unassign yourself, or otherwise "git  
> 'r done" if you care about one of these issues.
>
> I volunteer to be the release manager, unless someone else is dying to  
> do it.
>
> Cheers,
> Grant

Reply | Threaded
Open this post in threaded view
|

RE: [VOTE] Set Solr 1.3 freeze and release date

Kashyap, Raghu
+1 for Aug 18th

-----Original Message-----
From: Otis Gospodnetic [mailto:[hidden email]]
Sent: Tuesday, August 05, 2008 4:32 PM
To: [hidden email]
Subject: Re: [VOTE] Set Solr 1.3 freeze and release date

May the force be with you.  +1

 
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch



----- Original Message ----

> From: Grant Ingersoll <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, August 5, 2008 3:46:26 PM
> Subject: [VOTE] Set Solr 1.3 freeze and release date
>
> Well, we've been beating around the bush on 1.3 for a good amount of  
> time now.   How about we set a date and actually vote on it and thus  
> make it pseudo-binding?
>
> I see that we have 13 issues:
>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mod
e=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=1231023
0&fixfor=12312486
>
> SOLR-410: Review the ResponseBuilder class.  My take is this can be  
> closed.  We've (Solr that is) been running w/ it for a while now.
>
> SOLR-545: Remove Default core in multicore.  No patch available.
>
> SOLR-243: Create a hook to bring in custom IndexReaders.  This patch  
> made a lot of progress, but then seems to be abandoned once unit tests

> were asked for.  I suggest moving to 1.4
>
> SOLR-624: Don't take snapshot if no diffs.  Sounds ready to be
committed
>
> SOLR-630: Spellchecker should not be case-sensitive and should be  
> stopwords aware.  No patch available or unit tests.  Seems like it  
> could be handled through analysis, but not sure.
>
> SOLR-506:  Enabling HTTP Cache Headers should be configurable.  Sounds

> ready to commit, right Shalin?
>
> SOLR-653: remove overwrite command.  Sounds ready to commit
>
> SOLR-474: Audit docs for spellchecker Mike Klaas says he will take  
> care of it.
>
> SOLR-646: Config. props in multicore.xml  Seems really useful, but is

> currently unassigned.
>
> SOLR-619: Dynamic copyField at runtime.  Rumor has it's completed...
>
> SOLR-614: Allow components to read any kind of XML.  Has a couple of  
> -1 on it that have been changed to -0
>
> SOLR-489: Add deprecation docs.  Last updated on the 4th.  Needs  
> review and should go in
>
> So, what to vote on?
>
> 0.  Accept no more issues outside of this list, other than blockers  
> for 1.3.
> 1.   Set August 12 as code freeze date.  1 week from today.  After  
> which, only doc changes and blockers are allowed.   So, if the above  
> isn't fixed by then, it's out unless someone wants to make it a
blocker.
> 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.  Thus, the 1.3 release, assuming all goes well will be on

> the 17th or 18th (since the 17th is a Sunday.)  Thus SOLR-489 in  
> theory need not be complete by the 12th, but the 18th instead,  
> although we might as well get it done.
>
> What this means?  Speak up now, unassign yourself, or otherwise "git  
> 'r done" if you care about one of these issues.
>
> I volunteer to be the release manager, unless someone else is dying to

> do it.
>
> Cheers,
> Grant

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Henrib-2
In reply to this post by Grant Ingersoll-2
>> SOLR-545: Remove Default core in multicore.  No patch available.

Not sure how much should be added to this - I've added comment in the issue itself.


>> SOLR-646: Config. props in multicore.xml  Seems really useful, but is  
currently unassigned.

Feel free to bug me as much as needed if I can help.


>> 0.  Accept no more issues outside of this list, other than blockers  
for 1.3.

+1

>> 1.   Set August 12 as code freeze date.  1 week from today.

+1

>> I volunteer to be the release manager, unless someone else is dying to  
do it.

Thanks!






Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Erik Hatcher
In reply to this post by Grant Ingersoll-2

On Aug 5, 2008, at 3:46 PM, Grant Ingersoll wrote:
> Well, we've been beating around the bush on 1.3 for a good amount of  
> time now.   How about we set a date and actually vote on it and thus  
> make it pseudo-binding?

Finally!   (I'm of the "release early, release often" philosophy myself)

> I see that we have 13 issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486

I'm adding SOLR-513 assigned to me to get done by our cut-off date.  
I've applied the patch locally, and will work through the  
SolrDispatchFilter pathPrefix issue and commit when all is well.

> SOLR-545: Remove Default core in multicore.  No patch available.

+1  - thanks Ryan!

> SOLR-506:  Enabling HTTP Cache Headers should be configurable.  
> Sounds ready to commit, right Shalin?

+1

> SOLR-646: Config. props in multicore.xml  Seems really useful, but  
> is currently unassigned.
>
> SOLR-614: Allow components to read any kind of XML.  Has a couple of  
> -1 on it that have been changed to -0

These two give me pause, not because they aren't clever and useful,  
but rather it pains me to see Solr take on so much config. management  
duties.  It's a "code smell" to me to have a search engine be  
concerning itself deeply with configuration.

But in general these are indeed handy additions, provided they aren't  
abused.

> SOLR-619: Dynamic copyField at runtime.  Rumor has it's completed...

Could the use case for this be explained?   Why copyFields and not any  
other piece of config/schema?

> 0.  Accept no more issues outside of this list, other than blockers  
> for 1.3.

Let me add SOLR-513, and if for some reason it doesn't make it in, no  
big deal, but it'll be do-able by August 12.

> 1.   Set August 12 as code freeze date.  1 week from today.  After  
> which, only doc changes and blockers are allowed.   So, if the above  
> isn't fixed by then, it's out unless someone wants to make it a  
> blocker.

+1

> 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.  Thus, the 1.3 release, assuming all goes well will be  
> on the 17th or 18th (since the 17th is a Sunday.)  Thus SOLR-489 in  
> theory need not be complete by the 12th, but the 18th instead,  
> although we might as well get it done.

+1

> What this means?  Speak up now, unassign yourself, or otherwise "git  
> 'r done" if you care about one of these issues.
>
> I volunteer to be the release manager, unless someone else is dying  
> to do it.

Thanks Grant for the prod!    Solr 1.3 here we come!

        Erik

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

hossman
In reply to this post by Grant Ingersoll-2
: 0.  Accept no more issues outside of this list, other than blockers for 1.3.

+1

: 1.   Set August 12 as code freeze date.  1 week from today.  After which, only

+1

: 2.   Code Freeze in effect for 5 days for testing of release candidates.

+0 ... I'd prefer we spend more then 5 days on this.  Both because i think
we're missing a lot of docs; and because i have a hunch that when we
really start shaking the tree, a lot of weird release packaging
quirks/questions are going to fall out since this is the first release to
include SolrJ and contribs.

But I ain't going to stop you from cutting release candidates :)


-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Shalin Shekhar Mangar
In reply to this post by Grant Ingersoll-2
On Wed, Aug 6, 2008 at 1:16 AM, Grant Ingersoll <[hidden email]> wrote:

> Well, we've been beating around the bush on 1.3 for a good amount of time
> now.   How about we set a date and actually vote on it and thus make it
> pseudo-binding?
>

+101 :)


> SOLR-630: Spellchecker should not be case-sensitive and should be stopwords
> aware.  No patch available or unit tests.  Seems like it could be handled
> through analysis, but not sure.


I think the same. Will find some time look into it.

>
>
> SOLR-506:  Enabling HTTP Cache Headers should be configurable.  Sounds
> ready to commit, right Shalin?
>

Correct.

>
> SOLR-614: Allow components to read any kind of XML.  Has a couple of -1 on
> it that have been changed to -0


I'm very much +1 for it. Will review and commit soon.

0.  Accept no more issues outside of this list, other than blockers for 1.3.


I'd like to add support for publishing artifacts to maven since it is very
useful for a lot of people. We have 2 issues related to this. SOLR-19 and
SOLR-586. However, it should not stop us from releasing 1.3

>
> 1.   Set August 12 as code freeze date.  1 week from today.  After which,
> only doc changes and blockers are allowed.   So, if the above isn't fixed by
> then, it's out unless someone wants to make it a blocker.


+1 for August 12

2.   Code Freeze in effect for 5 days for testing of release candidates.
>  Thus, the 1.3 release, assuming all goes well will be on the 17th or 18th
> (since the 17th is a Sunday.)  Thus SOLR-489 in theory need not be complete
> by the 12th, but the 18th instead, although we might as well get it done.


+1, however I feel there may be changes required in docs and builds.
Specifically, contrib build needs to be more consistent in terms of
manifests, clover.

Just one question, what are we going to do about the logo?

I volunteer to be the release manager, unless someone else is dying to do
> it.


Thank you!

--
Regards,
Shalin Shekhar Mangar.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Andrew Savory
In reply to this post by Grant Ingersoll-2
Hi,

2008/8/5 Grant Ingersoll <[hidden email]>:

> So, what to vote on?
>
> 0.  Accept no more issues outside of this list, other than blockers for 1.3.

I'd like to see the following issues added to the list (in order of priority):

https://issues.apache.org/jira/browse/SOLR-84 New logo
https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
also https://issues.apache.org/jira/browse/SOLR-643)
https://issues.apache.org/jira/browse/SOLR-484 Solr Website changes
https://issues.apache.org/jira/browse/SOLR-19 pom.xml to support maven2

None of these are particularly crucial from a codebase perspective,
but I believe all of them are crucial from a community perspective.

> 1.   Set August 12 as code freeze date.  1 week from today.  After which,
> only doc changes and blockers are allowed.   So, if the above isn't fixed by
> then, it's out unless someone wants to make it a blocker.

Non-binding +1.

> 2.   Code Freeze in effect for 5 days for testing of release candidates.
>  Thus, the 1.3 release, assuming all goes well will be on the 17th or 18th
> (since the 17th is a Sunday.)  Thus SOLR-489 in theory need not be complete
> by the 12th, but the 18th instead, although we might as well get it done.

Non-binding +1.

> I volunteer to be the release manager, unless someone else is dying to do
> it.

Non-binding +1.


There's also the issue of using snapshots
(commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
emphasis on the legal issues surrounding the use of snapshots, I'd
suggest we should ship 1.3 with latest stable releases of those
dependencies.


Andrew.
--
[hidden email] / [hidden email]
http://www.andrewsavory.com/
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Grant Ingersoll-2
In reply to this post by Shalin Shekhar Mangar

On Aug 6, 2008, at 1:16 AM, Shalin Shekhar Mangar wrote:

> On Wed, Aug 6, 2008 at 1:16 AM, Grant Ingersoll  
> <[hidden email]> wrote:
>
>> Well, we've been beating around the bush on 1.3 for a good amount  
>> of time
>> now.   How about we set a date and actually vote on it and thus  
>> make it
>> pseudo-binding?
>>
>
> +101 :)
>
>
>> SOLR-630: Spellchecker should not be case-sensitive and should be  
>> stopwords
>> aware.  No patch available or unit tests.  Seems like it could be  
>> handled
>> through analysis, but not sure.
>
>
> I think the same. Will find some time look into it.
>
>>
>>
>> SOLR-506:  Enabling HTTP Cache Headers should be configurable.  
>> Sounds
>> ready to commit, right Shalin?
>>
>
> Correct.
>
>>
>> SOLR-614: Allow components to read any kind of XML.  Has a couple  
>> of -1 on
>> it that have been changed to -0
>
>
> I'm very much +1 for it. Will review and commit soon.

Um, I don't know if committing is what is supposed to be done here.  
There seems to be a general lack of enthusiasm for it, with several  
-1's that were changed to -0, which is not exactly encouraging.  My  
gut says it should wait.

>
>
> 0.  Accept no more issues outside of this list, other than blockers  
> for 1.3.
>
>
> I'd like to add support for publishing artifacts to maven since it  
> is very
> useful for a lot of people. We have 2 issues related to this.  
> SOLR-19 and
> SOLR-586. However, it should not stop us from releasing 1.3

+1.  I'd just copy what Lucene does.

>
>
>>
>> 1.   Set August 12 as code freeze date.  1 week from today.  After  
>> which,
>> only doc changes and blockers are allowed.   So, if the above isn't  
>> fixed by
>> then, it's out unless someone wants to make it a blocker.
>
>
> +1 for August 12
>
> 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.
>> Thus, the 1.3 release, assuming all goes well will be on the 17th  
>> or 18th
>> (since the 17th is a Sunday.)  Thus SOLR-489 in theory need not be  
>> complete
>> by the 12th, but the 18th instead, although we might as well get it  
>> done.
>






Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Grant Ingersoll-2
In reply to this post by hossman

On Aug 6, 2008, at 1:00 AM, Chris Hostetter wrote:

> : 2.   Code Freeze in effect for 5 days for testing of release  
> candidates.
>
> +0 ... I'd prefer we spend more then 5 days on this.  Both because i  
> think
> we're missing a lot of docs; and because i have a hunch that when we
> really start shaking the tree, a lot of weird release packaging
> quirks/questions are going to fall out since this is the first  
> release to
> include SolrJ and contribs.
>
> But I ain't going to stop you from cutting release candidates :)
>

We can go 7 or 10 days if you want.  My experience in Lucene land is  
that only 1 or 2 committers ever step up to the plate on the  
documentation, but I do agree about the packaging stuff.  How about we  
aim for 5 days, and we'll be happy w/ 7?

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Grant Ingersoll-2
In reply to this post by Andrew Savory

On Aug 6, 2008, at 6:37 AM, Andrew Savory wrote:

> Hi,
>
> 2008/8/5 Grant Ingersoll <[hidden email]>:
>
>> So, what to vote on?
>>
>> 0.  Accept no more issues outside of this list, other than blockers  
>> for 1.3.
>
> I'd like to see the following issues added to the list (in order of  
> priority):
>
> https://issues.apache.org/jira/browse/SOLR-84 New logo

I think we should hold off on the logo.  I'm more of the mindset now  
that we can do better.

>
> https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
> also https://issues.apache.org/jira/browse/SOLR-643)

Given I personally don't think the logo is good enough, I don't see  
too much pointing in updating the admin pages either.

>
> https://issues.apache.org/jira/browse/SOLR-484 Solr Website changes

This is going forward regardless of release.

>
> https://issues.apache.org/jira/browse/SOLR-19 pom.xml to support  
> maven2

Sounds like Shalin has taken this up.

>
>
> None of these are particularly crucial from a codebase perspective,
> but I believe all of them are crucial from a community perspective.
>
>> 1.   Set August 12 as code freeze date.  1 week from today.  After  
>> which,
>> only doc changes and blockers are allowed.   So, if the above isn't  
>> fixed by
>> then, it's out unless someone wants to make it a blocker.
>
> Non-binding +1.
>
>> 2.   Code Freeze in effect for 5 days for testing of release  
>> candidates.
>> Thus, the 1.3 release, assuming all goes well will be on the 17th  
>> or 18th
>> (since the 17th is a Sunday.)  Thus SOLR-489 in theory need not be  
>> complete
>> by the 12th, but the 18th instead, although we might as well get it  
>> done.
>
> Non-binding +1.
>
>> I volunteer to be the release manager, unless someone else is dying  
>> to do
>> it.
>
> Non-binding +1.
>
>
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.
>


Well, Lucene 2.4 isn't going to be released anytime soon, so...

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Guillaume Smet
In reply to this post by Andrew Savory
On Wed, Aug 6, 2008 at 12:37 PM, Andrew Savory <[hidden email]> wrote:
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.

Yes, I'm kinda annoyed too with lucene 2.4-dev integration in a stable
release. What if a bug is fixed in Lucene after the release and we
cannot package 2.4-dev trunk because it has too many changes (physical
format changes, API changes...)? Is Solr dev team going to maintain a
separate branch with the 2.4-dev snapshot version shipped with 1.3 +
bugfixes?

--
Guillaume
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Mark Miller-3
In reply to this post by Grant Ingersoll-2

>>
>>> So, what to vote on?
>>>
>>> 0.  Accept no more issues outside of this list, other than blockers
>>> for 1.3.
>>
>> I'd like to see the following issues added to the list (in order of
>> priority):
>>
>> https://issues.apache.org/jira/browse/SOLR-84 New logo
>
> I think we should hold off on the logo.  I'm more of the mindset now
> that we can do better.
I think this is a great idea - hopefully. The interest by a couple guys
to submit more logos is awesome - I just hope holding off won't drop
everything off the radar. Someone mentioned all this hubbub happening
before, and then nothing was done. We ran two polls as well, and we are
throwing that all away - I still think its a good idea to wait if we are
actually going to get more logos though - we certainly don't want to be
changing it on every release, so I think we want to be relatively happy
with it.
>
>>
>> https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
>> also https://issues.apache.org/jira/browse/SOLR-643)
>
> Given I personally don't think the logo is good enough, I don't see
> too much pointing in updating the admin pages either.
I don't think there has been enough work here yet anyway. And like the
logo, we are going to have to make sure its the direction that the
majority wants to go. Users definitely want a more professional look at
some point - but I think these issues are more starting points.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Yonik Seeley-2
On Wed, Aug 6, 2008 at 7:58 AM, Mark Miller <[hidden email]> wrote:
>> I think we should hold off on the logo.  I'm more of the mindset now that
>> we can do better.
>
> I think this is a great idea - hopefully. The interest by a couple guys to
> submit more logos is awesome - I just hope holding off won't drop everything
> off the radar. Someone mentioned all this hubbub happening before, and then
> nothing was done.

Seems to be moving in that direction this time too :-)

> We ran two polls as well, and we are throwing that all
> away - I still think its a good idea to wait if we are actually going to get
> more logos though - we certainly don't want to be changing it on every
> release, so I think we want to be relatively happy with it.

If people decide to wait and accept more logos, why not have a proper
logo contest as other projects have done... let everyone know that new
logo candidates are being accepted.

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Grant Ingersoll-2
In reply to this post by Guillaume Smet

On Aug 6, 2008, at 7:47 AM, Guillaume Smet wrote:

> On Wed, Aug 6, 2008 at 12:37 PM, Andrew Savory <[hidden email]>  
> wrote:
>> There's also the issue of using snapshots
>> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
>> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
>> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
>> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
>> emphasis on the legal issues surrounding the use of snapshots, I'd
>> suggest we should ship 1.3 with latest stable releases of those
>> dependencies.
>
> Yes, I'm kinda annoyed too with lucene 2.4-dev integration in a stable
> release. What if a bug is fixed in Lucene after the release and we
> cannot package 2.4-dev trunk because it has too many changes (physical
> format changes, API changes...)? Is Solr dev team going to maintain a
> separate branch with the 2.4-dev snapshot version shipped with 1.3 +
> bugfixes?

I'm less concerned about Lucene, but maybe that's b/c I live close to  
it.
Taking it out would mean a decent amount of rolling back.  We will  
almost certainly have a 1.3.1 release, etc. unless all goes swimmingly.

Also, note 1.2 has Lucene dev JARs in it, not official releases...
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Norberto Meijome-2
In reply to this post by Grant Ingersoll-2
On Wed, 6 Aug 2008 07:35:47 -0400
Grant Ingersoll <[hidden email]> wrote:

> > I'd like to see the following issues added to the list (in order of  
> > priority):
> >
> > https://issues.apache.org/jira/browse/SOLR-84 New logo  
>
> I think we should hold off on the logo.  I'm more of the mindset now  
> that we can do better.

emphatic +1.

>
> >
> > https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
> > also https://issues.apache.org/jira/browse/SOLR-643)  
>
> Given I personally don't think the logo is good enough, I don't see  
> too much pointing in updating the admin pages either.

yup. candidate for a 1.3.5 (1.3.1., 1.4 , whatever )  , with other smaller things that may be ready in when these are too...?
_________________________
{Beto|Norberto|Numard} Meijome

"Build a system that even a fool can use, and only a fool will want to use it."
   George Bernard Shaw

I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Andrew Savory
In reply to this post by Grant Ingersoll-2
Hi,

2008/8/6 Grant Ingersoll <[hidden email]>:

> I'm less concerned about Lucene, but maybe that's b/c I live close to it.
> Taking it out would mean a decent amount of rolling back.  We will almost
> certainly have a 1.3.1 release, etc. unless all goes swimmingly.

Yes, it's good that lots of Solr people are also Lucene people. But I
don't think that makes it alright to ship Lucene nightlies or
snapshots.

One of the reasons projects are pushed into doing releases is because
of pressure from downstream projects who need stable releases for
their own code. Therefore Solr should be gently exerting pressure on
Lucene to do a stable release, in just the same way that some of us
who depend on Solr are exerting pressure for a Solr release.

If you short-circuit that process by saying "well, we know lucene so
it's ok for us to use unstable builds", then there might never be a
stable release of Lucene again (hyperbole and exaggeration, but you
get my point).

Another reason: say corporation X has a policy to use "only released
software" (lots do). Developers at X could grab Solr 1.3 and use it
without problem, but what if they were building a supercool tool Y
that worked alongside Solr, but used only Lucene libraries. Clearly
they would want to use the latest library, but they would be forced to
only use the release, which practically guarantees headaches and
interoperability problems between Solr and tool Y.

It sucks to delay Solr 1.3, but perhaps we should all hope over to the
Lucene mailing lists and start pushing for a stable release there?

> Also, note 1.2 has Lucene dev JARs in it, not official releases...

And had I been around when 1.2 was released, I'd have made the same
arguments ;-)


Andrew.
--
[hidden email] / [hidden email]
http://www.andrewsavory.com/
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Mark Miller-3
Andrew Savory wrote:
> It sucks to delay Solr 1.3, but perhaps we should all hope over to the
> Lucene mailing lists and start pushing for a stable release there?
>  
A while back (a year now or a i bit less i think) there was a push for
doing Lucene releases much more often. It didn't work out IMO :) But it
was well supported in discussion - probably worth bringing up again.

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Set Solr 1.3 freeze and release date

Erik Hatcher
In reply to this post by Andrew Savory

On Aug 6, 2008, at 6:37 AM, Andrew Savory wrote:
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.

Andrew - I'm mostly with you on this myself, primarily from the  
dependency sanity issue, but also in the Lucene case of the  
possibility that the index format could change and break Solr  
backwards compatibility (or at least forcing the issue to be addressed  
somehow).

I'm not sure what the situation with commons-csv - probably something  
got fixed in trunk?

Practically speaking, though, Grant's right about the troubles it'd  
cause to roll back to the latest official Lucene release.

*ugh* - I'm on the fence on this one.  I really think Solr should have  
release versions of Lucene JARs in its official releases.   What to  
do?    [go camping!   see ya Saturday]

        Erik

12