You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2009/05/13 15:10:18 UTC
Solr 1.4
Seems like we're reaching critical mass again, but there is a lot of
issues that are open, or not even marked.
Do people think we can shoot for 1.4 in the coming month (say mid-
June)? I'm happy (OK, maybe happy isn't the word, how about willing)
to be the RM again.
See https://issues.apache.org/jira/secure/BrowseProject.jspa for
what's currently on 1.4, 1.5 and unscheduled. The unscheduled section
is particularly large, IMO. So, we should work through these areas.
WDYT?
-Grant
Re: Solr 1.4
Posted by Ryan McKinley <ry...@gmail.com>.
As a general rule any feature/API from 1.3 that you are using in 1.4
should work on /trunk -- any chances to this are always in CHANGES.txt
The place were you get in to murky water is with new features/API
since the previous release -- in this case, you will need to follow
the JIRA issues to have a sense of how "stable" the specific feature is.
On May 14, 2009, at 5:25 PM, Eger, Patrick wrote:
> Fair enough, any yes we would definitely do extensive testing before
> any
> release. I think the problem is, that without any "official
> blessing" I
> as a user have no real way of knowing the current state of TRUNK. IE
> is
> some feature in the middle of a rework? Is there some kind of janky
> partially-solved issue that is "known"? Questions like that make it
> difficult for me to know where to spend my (limited) testing time,
> so in
> the end I really end up not doing it at all. I'd likely be able to
> commit to RC X testing or monthly blessed snapshot kind of thing
> though,
> which is why I mention it. Only speaking for myself but I surmise
> others
> might be in the same boat. Again though, thanks for the great product!
>
>
> Best Regards,
>
> Patrick
>
>> -----Original Message-----
>> From: Grant Ingersoll [mailto:gsingers@apache.org]
>> Sent: Thursday, May 14, 2009 11:33 AM
>> To: solr-dev@lucene.apache.org
>> Subject: Re: Solr 1.4
>>
>> I'm not suggesting you don't validate it first with your own
>> tests. I
>> can't imagine you take a release and just deploy it in production,
>> right?
>>
>> I'm just observing that if everyone (besides the committers) takes
>> this "release only" approach, then you quickly realize that the large
>> majority of testing in real production systems happens _after_
>> release, not before, which makes it seem less like a "release" and
>> more like a "release to QA". We committers and contributors make
>> best
>> efforts to test, but the community is responsible for finding most
>> issues simply (b/c of sheer volume) regardless of what name you want
>> to apply to the actual bits they are testing (i.e. nightly/release/
>> Giant Ball of Solr Fun). In other words, if you are planning on
>> upgrading to 1.4, then you should be trying out 1.4-dev in your test
>> environment before release, not after.
>>
>> Just my two cents,
>> Grant
>>
>>
>> On May 14, 2009, at 12:35 PM, Eger, Patrick wrote:
>>
>>> Yeah, at least for us, the corporate overlords (and our operations
>>> team) would be *extremely* hesitant to go to production with any
>>> kind of snapshot release. If there was a "weekly stable" or similar
>>> that might be slightly better, but definitely not a CI/nightly.
>>>
>>>
>>> Best Regards,
>>>
>>> Patrick
>>>
>>>> -----Original Message-----
>>>> From: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf
> Of
>>>> Noble Paul ??????? ??????
>>>> Sent: Thursday, May 14, 2009 5:55 AM
>>>> To: solr-dev@lucene.apache.org
>>>> Subject: Re: Solr 1.4
>>>>
>>>> The advantage is that there is strength in numbers. There will be a
>>>> lot of users using the release build and if there is an issue the
>>>> user
>>>> can rest assured that there will others who need the same fix on
> the
>>>> same revision. (so a better chance of a resolution)
>>>>
>>>> moreover there won't be any half baked fixes in a release
>>>>
>>>>
>>>>
>>>> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll
>>>> <gs...@apache.org>
>>>> wrote:
>>>>>
>>>>> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
>>>>>
>>>>>> +2
>>>>>>
>>>>>> This would be very much appreciated by your users, I at least was
>>>>>> expecting March :-) We were hoping to release with 1.4
>>>>>> (specifically
>>>> for
>>>>>> java replication and field collapsing) but had to redo some plans
>>>>>> since
>>>>>> it seemed to keep slipping.
>>>>>
>>>>> It's not like anything all that magical necessarily happens with a
>>>> release.
>>>>> Sure, we package up the bits and there is some legal
>>>>> ramifications, I
>>>>> suppose, but the software is more or less the same. In other
> words,
>>>> most
>>>>> people should be fine with trunk, or some recent revision. In fact
>>>>> if
>>>> more
>>>>> people tried out trunk, it would be faster to release b/c we would
>>>>> have
>>>> more
>>>>> vetting done.
>>>>>
>>>>>> Not complaining, just FYI on our experiences
>>>>>> (it's a free product after all). A 4-6 month release schedule
>>>>>> would be
>>>>>> ideal for us, whereas it looks like it'll be ~9-10 months
>>>>>> currently?
>>>>>> Again, not complaining, just trying to get SOLR into production!
>>>>>
>>>>> http://wiki.apache.org/solr/HowToContribute ;-)
>>>>>
>>>>>
Re: Solr 1.4
Posted by Grant Ingersoll <gs...@apache.org>.
Agreed. I think we are all in that boat! Never enough time to do all
the things we want to do.
Cheers,
Grant
On May 14, 2009, at 5:25 PM, Eger, Patrick wrote:
> Fair enough, any yes we would definitely do extensive testing before
> any
> release. I think the problem is, that without any "official
> blessing" I
> as a user have no real way of knowing the current state of TRUNK. IE
> is
> some feature in the middle of a rework? Is there some kind of janky
> partially-solved issue that is "known"? Questions like that make it
> difficult for me to know where to spend my (limited) testing time,
> so in
> the end I really end up not doing it at all. I'd likely be able to
> commit to RC X testing or monthly blessed snapshot kind of thing
> though,
> which is why I mention it. Only speaking for myself but I surmise
> others
> might be in the same boat. Again though, thanks for the great product!
>
>
> Best Regards,
>
> Patrick
>
>> -----Original Message-----
>> From: Grant Ingersoll [mailto:gsingers@apache.org]
>> Sent: Thursday, May 14, 2009 11:33 AM
>> To: solr-dev@lucene.apache.org
>> Subject: Re: Solr 1.4
>>
>> I'm not suggesting you don't validate it first with your own
>> tests. I
>> can't imagine you take a release and just deploy it in production,
>> right?
>>
>> I'm just observing that if everyone (besides the committers) takes
>> this "release only" approach, then you quickly realize that the large
>> majority of testing in real production systems happens _after_
>> release, not before, which makes it seem less like a "release" and
>> more like a "release to QA". We committers and contributors make
>> best
>> efforts to test, but the community is responsible for finding most
>> issues simply (b/c of sheer volume) regardless of what name you want
>> to apply to the actual bits they are testing (i.e. nightly/release/
>> Giant Ball of Solr Fun). In other words, if you are planning on
>> upgrading to 1.4, then you should be trying out 1.4-dev in your test
>> environment before release, not after.
>>
>> Just my two cents,
>> Grant
>>
>>
>> On May 14, 2009, at 12:35 PM, Eger, Patrick wrote:
>>
>>> Yeah, at least for us, the corporate overlords (and our operations
>>> team) would be *extremely* hesitant to go to production with any
>>> kind of snapshot release. If there was a "weekly stable" or similar
>>> that might be slightly better, but definitely not a CI/nightly.
>>>
>>>
>>> Best Regards,
>>>
>>> Patrick
>>>
>>>> -----Original Message-----
>>>> From: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf
> Of
>>>> Noble Paul ??????? ??????
>>>> Sent: Thursday, May 14, 2009 5:55 AM
>>>> To: solr-dev@lucene.apache.org
>>>> Subject: Re: Solr 1.4
>>>>
>>>> The advantage is that there is strength in numbers. There will be a
>>>> lot of users using the release build and if there is an issue the
>>>> user
>>>> can rest assured that there will others who need the same fix on
> the
>>>> same revision. (so a better chance of a resolution)
>>>>
>>>> moreover there won't be any half baked fixes in a release
>>>>
>>>>
>>>>
>>>> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll
>>>> <gs...@apache.org>
>>>> wrote:
>>>>>
>>>>> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
>>>>>
>>>>>> +2
>>>>>>
>>>>>> This would be very much appreciated by your users, I at least was
>>>>>> expecting March :-) We were hoping to release with 1.4
>>>>>> (specifically
>>>> for
>>>>>> java replication and field collapsing) but had to redo some plans
>>>>>> since
>>>>>> it seemed to keep slipping.
>>>>>
>>>>> It's not like anything all that magical necessarily happens with a
>>>> release.
>>>>> Sure, we package up the bits and there is some legal
>>>>> ramifications, I
>>>>> suppose, but the software is more or less the same. In other
> words,
>>>> most
>>>>> people should be fine with trunk, or some recent revision. In fact
>>>>> if
>>>> more
>>>>> people tried out trunk, it would be faster to release b/c we would
>>>>> have
>>>> more
>>>>> vetting done.
>>>>>
>>>>>> Not complaining, just FYI on our experiences
>>>>>> (it's a free product after all). A 4-6 month release schedule
>>>>>> would be
>>>>>> ideal for us, whereas it looks like it'll be ~9-10 months
>>>>>> currently?
>>>>>> Again, not complaining, just trying to get SOLR into production!
>>>>>
>>>>> http://wiki.apache.org/solr/HowToContribute ;-)
>>>>>
>>>>>
RE: Solr 1.4
Posted by "Eger, Patrick" <pe...@automotive.com>.
Fair enough, any yes we would definitely do extensive testing before any
release. I think the problem is, that without any "official blessing" I
as a user have no real way of knowing the current state of TRUNK. IE is
some feature in the middle of a rework? Is there some kind of janky
partially-solved issue that is "known"? Questions like that make it
difficult for me to know where to spend my (limited) testing time, so in
the end I really end up not doing it at all. I'd likely be able to
commit to RC X testing or monthly blessed snapshot kind of thing though,
which is why I mention it. Only speaking for myself but I surmise others
might be in the same boat. Again though, thanks for the great product!
Best Regards,
Patrick
> -----Original Message-----
> From: Grant Ingersoll [mailto:gsingers@apache.org]
> Sent: Thursday, May 14, 2009 11:33 AM
> To: solr-dev@lucene.apache.org
> Subject: Re: Solr 1.4
>
> I'm not suggesting you don't validate it first with your own tests. I
> can't imagine you take a release and just deploy it in production,
> right?
>
> I'm just observing that if everyone (besides the committers) takes
> this "release only" approach, then you quickly realize that the large
> majority of testing in real production systems happens _after_
> release, not before, which makes it seem less like a "release" and
> more like a "release to QA". We committers and contributors make best
> efforts to test, but the community is responsible for finding most
> issues simply (b/c of sheer volume) regardless of what name you want
> to apply to the actual bits they are testing (i.e. nightly/release/
> Giant Ball of Solr Fun). In other words, if you are planning on
> upgrading to 1.4, then you should be trying out 1.4-dev in your test
> environment before release, not after.
>
> Just my two cents,
> Grant
>
>
> On May 14, 2009, at 12:35 PM, Eger, Patrick wrote:
>
> > Yeah, at least for us, the corporate overlords (and our operations
> > team) would be *extremely* hesitant to go to production with any
> > kind of snapshot release. If there was a "weekly stable" or similar
> > that might be slightly better, but definitely not a CI/nightly.
> >
> >
> > Best Regards,
> >
> > Patrick
> >
> >> -----Original Message-----
> >> From: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf
Of
> >> Noble Paul ??????? ??????
> >> Sent: Thursday, May 14, 2009 5:55 AM
> >> To: solr-dev@lucene.apache.org
> >> Subject: Re: Solr 1.4
> >>
> >> The advantage is that there is strength in numbers. There will be a
> >> lot of users using the release build and if there is an issue the
> >> user
> >> can rest assured that there will others who need the same fix on
the
> >> same revision. (so a better chance of a resolution)
> >>
> >> moreover there won't be any half baked fixes in a release
> >>
> >>
> >>
> >> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll
> >> <gs...@apache.org>
> >> wrote:
> >>>
> >>> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
> >>>
> >>>> +2
> >>>>
> >>>> This would be very much appreciated by your users, I at least was
> >>>> expecting March :-) We were hoping to release with 1.4
> >>>> (specifically
> >> for
> >>>> java replication and field collapsing) but had to redo some plans
> >>>> since
> >>>> it seemed to keep slipping.
> >>>
> >>> It's not like anything all that magical necessarily happens with a
> >> release.
> >>> Sure, we package up the bits and there is some legal
> >>> ramifications, I
> >>> suppose, but the software is more or less the same. In other
words,
> >> most
> >>> people should be fine with trunk, or some recent revision. In fact
> >>> if
> >> more
> >>> people tried out trunk, it would be faster to release b/c we would
> >>> have
> >> more
> >>> vetting done.
> >>>
> >>>> Not complaining, just FYI on our experiences
> >>>> (it's a free product after all). A 4-6 month release schedule
> >>>> would be
> >>>> ideal for us, whereas it looks like it'll be ~9-10 months
> >>>> currently?
> >>>> Again, not complaining, just trying to get SOLR into production!
> >>>
> >>> http://wiki.apache.org/solr/HowToContribute ;-)
> >>>
> >>>
Re: Solr 1.4
Posted by Yonik Seeley <ys...@gmail.com>.
FYI, I also planned on starting a discussion about the particular
version and features of Lucene that Solr is using on lucene-dev before
Solr releases.
-Yonik
Re: Solr 1.4
Posted by Grant Ingersoll <gs...@apache.org>.
I'm not suggesting you don't validate it first with your own tests. I
can't imagine you take a release and just deploy it in production,
right?
I'm just observing that if everyone (besides the committers) takes
this "release only" approach, then you quickly realize that the large
majority of testing in real production systems happens _after_
release, not before, which makes it seem less like a "release" and
more like a "release to QA". We committers and contributors make best
efforts to test, but the community is responsible for finding most
issues simply (b/c of sheer volume) regardless of what name you want
to apply to the actual bits they are testing (i.e. nightly/release/
Giant Ball of Solr Fun). In other words, if you are planning on
upgrading to 1.4, then you should be trying out 1.4-dev in your test
environment before release, not after.
Just my two cents,
Grant
On May 14, 2009, at 12:35 PM, Eger, Patrick wrote:
> Yeah, at least for us, the corporate overlords (and our operations
> team) would be *extremely* hesitant to go to production with any
> kind of snapshot release. If there was a "weekly stable" or similar
> that might be slightly better, but definitely not a CI/nightly.
>
>
> Best Regards,
>
> Patrick
>
>> -----Original Message-----
>> From: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf Of
>> Noble Paul ??????? ??????
>> Sent: Thursday, May 14, 2009 5:55 AM
>> To: solr-dev@lucene.apache.org
>> Subject: Re: Solr 1.4
>>
>> The advantage is that there is strength in numbers. There will be a
>> lot of users using the release build and if there is an issue the
>> user
>> can rest assured that there will others who need the same fix on the
>> same revision. (so a better chance of a resolution)
>>
>> moreover there won't be any half baked fixes in a release
>>
>>
>>
>> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll
>> <gs...@apache.org>
>> wrote:
>>>
>>> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
>>>
>>>> +2
>>>>
>>>> This would be very much appreciated by your users, I at least was
>>>> expecting March :-) We were hoping to release with 1.4
>>>> (specifically
>> for
>>>> java replication and field collapsing) but had to redo some plans
>>>> since
>>>> it seemed to keep slipping.
>>>
>>> It's not like anything all that magical necessarily happens with a
>> release.
>>> Sure, we package up the bits and there is some legal
>>> ramifications, I
>>> suppose, but the software is more or less the same. In other words,
>> most
>>> people should be fine with trunk, or some recent revision. In fact
>>> if
>> more
>>> people tried out trunk, it would be faster to release b/c we would
>>> have
>> more
>>> vetting done.
>>>
>>>> Not complaining, just FYI on our experiences
>>>> (it's a free product after all). A 4-6 month release schedule
>>>> would be
>>>> ideal for us, whereas it looks like it'll be ~9-10 months
>>>> currently?
>>>> Again, not complaining, just trying to get SOLR into production!
>>>
>>> http://wiki.apache.org/solr/HowToContribute ;-)
>>>
>>>
RE: Solr 1.4
Posted by "Eger, Patrick" <pe...@automotive.com>.
Yeah, at least for us, the corporate overlords (and our operations team) would be *extremely* hesitant to go to production with any kind of snapshot release. If there was a "weekly stable" or similar that might be slightly better, but definitely not a CI/nightly.
Best Regards,
Patrick
> -----Original Message-----
> From: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf Of
> Noble Paul ??????? ??????
> Sent: Thursday, May 14, 2009 5:55 AM
> To: solr-dev@lucene.apache.org
> Subject: Re: Solr 1.4
>
> The advantage is that there is strength in numbers. There will be a
> lot of users using the release build and if there is an issue the user
> can rest assured that there will others who need the same fix on the
> same revision. (so a better chance of a resolution)
>
> moreover there won't be any half baked fixes in a release
>
>
>
> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll <gs...@apache.org>
> wrote:
> >
> > On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
> >
> >> +2
> >>
> >> This would be very much appreciated by your users, I at least was
> >> expecting March :-) We were hoping to release with 1.4 (specifically
> for
> >> java replication and field collapsing) but had to redo some plans since
> >> it seemed to keep slipping.
> >
> > It's not like anything all that magical necessarily happens with a
> release.
> > Sure, we package up the bits and there is some legal ramifications, I
> > suppose, but the software is more or less the same. In other words,
> most
> > people should be fine with trunk, or some recent revision. In fact if
> more
> > people tried out trunk, it would be faster to release b/c we would have
> more
> > vetting done.
> >
> >> Not complaining, just FYI on our experiences
> >> (it's a free product after all). A 4-6 month release schedule would be
> >> ideal for us, whereas it looks like it'll be ~9-10 months currently?
> >> Again, not complaining, just trying to get SOLR into production!
> >
> > http://wiki.apache.org/solr/HowToContribute ;-)
> >
> > -Grant
> >
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Solr 1.4
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
The advantage is that there is strength in numbers. There will be a
lot of users using the release build and if there is an issue the user
can rest assured that there will others who need the same fix on the
same revision. (so a better chance of a resolution)
moreover there won't be any half baked fixes in a release
On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
>
>> +2
>>
>> This would be very much appreciated by your users, I at least was
>> expecting March :-) We were hoping to release with 1.4 (specifically for
>> java replication and field collapsing) but had to redo some plans since
>> it seemed to keep slipping.
>
> It's not like anything all that magical necessarily happens with a release.
> Sure, we package up the bits and there is some legal ramifications, I
> suppose, but the software is more or less the same. In other words, most
> people should be fine with trunk, or some recent revision. In fact if more
> people tried out trunk, it would be faster to release b/c we would have more
> vetting done.
>
>> Not complaining, just FYI on our experiences
>> (it's a free product after all). A 4-6 month release schedule would be
>> ideal for us, whereas it looks like it'll be ~9-10 months currently?
>> Again, not complaining, just trying to get SOLR into production!
>
> http://wiki.apache.org/solr/HowToContribute ;-)
>
> -Grant
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Solr 1.4
Posted by Jacob Singh <ja...@gmail.com>.
> It's not like anything all that magical necessarily happens with a release.
> Sure, we package up the bits and there is some legal ramifications, I
> suppose, but the software is more or less the same. In other words, most
> people should be fine with trunk, or some recent revision. In fact if more
> people tried out trunk, it would be faster to release b/c we would have more
> vetting done.
>
We (Acquia) have been using a 1.4 nightlies (updating every month or
so) since January 15th in production.
We haven't had any problems with builds that pass tests at all.
Granted, we're not doing sharding, field collapsing or some other
features which may be "advanced", but we are using java replication in
multicore heavily and have played around a bit with the Tika extension
without issues.
Best,
Jacob
--
+1 510 277-0891 (o)
+91 9999 33 7458 (m)
web: http://pajamadesign.com
Skype: pajamadesign
Yahoo: jacobsingh
AIM: jacobsingh
gTalk: jacobsingh@gmail.com
Re: Solr 1.4
Posted by Grant Ingersoll <gs...@apache.org>.
On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
> +2
>
> This would be very much appreciated by your users, I at least was
> expecting March :-) We were hoping to release with 1.4 (specifically
> for
> java replication and field collapsing) but had to redo some plans
> since
> it seemed to keep slipping.
It's not like anything all that magical necessarily happens with a
release. Sure, we package up the bits and there is some legal
ramifications, I suppose, but the software is more or less the same.
In other words, most people should be fine with trunk, or some recent
revision. In fact if more people tried out trunk, it would be faster
to release b/c we would have more vetting done.
> Not complaining, just FYI on our experiences
> (it's a free product after all). A 4-6 month release schedule would be
> ideal for us, whereas it looks like it'll be ~9-10 months currently?
> Again, not complaining, just trying to get SOLR into production!
http://wiki.apache.org/solr/HowToContribute ;-)
-Grant
RE: Solr 1.4
Posted by "Eger, Patrick" <pe...@automotive.com>.
+2
This would be very much appreciated by your users, I at least was
expecting March :-) We were hoping to release with 1.4 (specifically for
java replication and field collapsing) but had to redo some plans since
it seemed to keep slipping. Not complaining, just FYI on our experiences
(it's a free product after all). A 4-6 month release schedule would be
ideal for us, whereas it looks like it'll be ~9-10 months currently?
Again, not complaining, just trying to get SOLR into production!
Best Regards,
Patrick
> -----Original Message-----
> From: Grant Ingersoll [mailto:gsingers@apache.org]
> Sent: Wednesday, May 13, 2009 1:02 PM
> To: solr-dev@lucene.apache.org
> Subject: Re: Solr 1.4
>
>
> On May 13, 2009, at 9:36 AM, Yonik Seeley wrote:
>
> > On Wed, May 13, 2009 at 9:10 AM, Grant Ingersoll
> > <gs...@apache.org> wrote:
> >> Seems like we're reaching critical mass again, but there is a lot
> >> of issues
> >> that are open, or not even marked.
> >>
> >> Do people think we can shoot for 1.4 in the coming month (say mid-
> >> June)?
> >
> > +1
> >
> > I was sort of shooting for the end of May, but schedules do tend to
>
> I know time-wise, I won't have the bandwidth before then, but if
> someone else wants to be the RM, be my guest. I figured it would give
> us the time to get the 1.4 issues resolved.
>
> -Grant
Re: Solr 1.4
Posted by Grant Ingersoll <gs...@apache.org>.
On May 13, 2009, at 9:36 AM, Yonik Seeley wrote:
> On Wed, May 13, 2009 at 9:10 AM, Grant Ingersoll
> <gs...@apache.org> wrote:
>> Seems like we're reaching critical mass again, but there is a lot
>> of issues
>> that are open, or not even marked.
>>
>> Do people think we can shoot for 1.4 in the coming month (say mid-
>> June)?
>
> +1
>
> I was sort of shooting for the end of May, but schedules do tend to
I know time-wise, I won't have the bandwidth before then, but if
someone else wants to be the RM, be my guest. I figured it would give
us the time to get the 1.4 issues resolved.
-Grant
Re: Solr 1.4
Posted by Yonik Seeley <ys...@gmail.com>.
On Wed, May 13, 2009 at 9:10 AM, Grant Ingersoll <gs...@apache.org> wrote:
> Seems like we're reaching critical mass again, but there is a lot of issues
> that are open, or not even marked.
>
> Do people think we can shoot for 1.4 in the coming month (say mid-June)?
+1
I was sort of shooting for the end of May, but schedules do tend to
slip a bit around here :-)
-Yonik
Re: Solr 1.4
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
FYI, I've moved issues marked for 1.3.1 to 1.4 or 1.5 as appropriate.
I've deleted the 1.3.1 version from Jira because I don't think we are going
to release a 1.3.1 now.
The following are the issues which were raised with affects version as
1.3.1. I've marked them as affecting 1.3
SOLR-895 DataImportHandler does not import multiple documents
specified in db-data-config.xml
SOLR-892 PHPResponseWriter fails to serialize boolean vars for
spellcheck output
The following were the issues which were marked for 1.3.1 as fix version.
I've marked them as fixed in 1.4
SOLR-843 SynonymFilterFactory cannot handle multiple synonym files
correctly
SOLR-840 BinaryResponseWriter does not handle nulls with shards as it
does locally
SOLR-830 snappuller picks bad snapshot name
SOLR-800 concurrentmodification exception for XPathEntityprocessor while
streaming
SOLR-794 ClientUtils.escapeQueryChars escapes chars a bit aggressive
SOLR-789 The javadoc of RandomSortField is not readable
SOLR-787 SolrJ POM refers to stax parser
SOLR-779 SolrQuery#setHighlightRequireFieldMatch() should be renamed to
SolrQuery#getHighlightRequireFieldMatch().
SOLR-778 Wrong parameter name in SolrQuery#getFacetMinCount().
SOLR-776 Maven Artifacts need to be signed.
SOLR-751 WordDelimiterFilter doesn't adjust startOffset
On Thu, May 14, 2009 at 1:05 AM, Grant Ingersoll <gs...@apache.org>wrote:
>
> On May 13, 2009, at 2:59 PM, Shalin Shekhar Mangar wrote:
>
>>
>>> See https://issues.apache.org/jira/secure/BrowseProject.jspa for what's
>>> currently on 1.4, 1.5 and unscheduled. The unscheduled section is
>>> particularly large, IMO. So, we should work through these areas.
>>>
>>> WDYT?
>>>
>>>
>> I wouldn't want to add any more issues to 1.4 unless it is a critical bug.
>> We have enough features already.
>>
>
> Agreed, but we still need to review them.
>
--
Regards,
Shalin Shekhar Mangar.
Re: Solr 1.4
Posted by Grant Ingersoll <gs...@apache.org>.
On May 13, 2009, at 2:59 PM, Shalin Shekhar Mangar wrote:
>>
>> See https://issues.apache.org/jira/secure/BrowseProject.jspa for
>> what's
>> currently on 1.4, 1.5 and unscheduled. The unscheduled section is
>> particularly large, IMO. So, we should work through these areas.
>>
>> WDYT?
>>
>
> I wouldn't want to add any more issues to 1.4 unless it is a
> critical bug.
> We have enough features already.
Agreed, but we still need to review them.
Re: Solr 1.4
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Wed, May 13, 2009 at 6:40 PM, Grant Ingersoll <gs...@apache.org>wrote:
> Seems like we're reaching critical mass again, but there is a lot of issues
> that are open, or not even marked.
>
> Do people think we can shoot for 1.4 in the coming month (say mid-June)?
> I'm happy (OK, maybe happy isn't the word, how about willing) to be the RM
> again.
deja-vu!
+1
>
> See https://issues.apache.org/jira/secure/BrowseProject.jspa for what's
> currently on 1.4, 1.5 and unscheduled. The unscheduled section is
> particularly large, IMO. So, we should work through these areas.
>
> WDYT?
>
I wouldn't want to add any more issues to 1.4 unless it is a critical bug.
We have enough features already.
--
Regards,
Shalin Shekhar Mangar.