You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Vanlerberghe, Luc" <Lu...@bvdinfo.com> on 2016/03/08 10:30:05 UTC
RE: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Hi,
I added two JIRA issues (Lucene: https://issues.apache.org/jira/browse/LUCENE-7078, Solr: https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query classes that are still mutable and should either become immutable, marked as @lucene.experimental or get a comment why it’s not an issue for that case.
Since they are part of the public API, I think now is the time to update them.
I already converted MultiPhraseQuery (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and committed by Adrien Grand).
Luc Vanlerberghe
From: Joel Bernstein [mailto:joelsolr@gmail.com]
Sent: maandag 7 maart 2016 21:08
To: lucene dev
Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
"Major API and bug fixes (no features) can be committed without my approval before Friday as long as they're reviewed and approved by another committer."
Hmmm, are there really major API changes underway at this point? As far as bug fixes needing another committer approval is not something we've done in the past.
Joel Bernstein
http://joelsolr.blogspot.com/
On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com>> wrote:
I think with all of the volatility surrounding the new Points codec that obvious bug/stability patches like these are OK? I know several folks have been working feverishly the past few days to fix serious (and simplify) 6.0 issues and squash all of the jenkins failures to ensure stability in time for the major release. That being said, you're right that we don't want chaotic committing as we lead up to the release.
So unless there are no objections I'll plan to move forward and start the release process this Friday. Until then, since this is a major release, as many people we can get to scrutinize and stabilize 6_0 over the next 3-4 days the better. Major API and bug fixes (no features) can be committed without my approval before Friday as long as they're reviewed and approved by another committer. If there is any uncertainty ping me on this thread or the corresponding issue and I'll review. I will also send out an email 24 hours before I start the release process.
- Nick
On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com<ma...@gmail.com> <da...@gmail.com>> wrote:
I just want to clarify you(Nick) / our expectations about this release branch. It seems, based on issues I've seen like LUCENE-7072, that we can commit to the release branch without your permission as RM. If this is true, then I presume the tacit approval is okay so long as it's not a new feature. Right?
On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com>> wrote:
With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to keep the ball moving and volunteer as the 6.0.0 RM.
If there are no objections my plan is to cut branch_6_0 early next week - Mon or Tues. Please mark blocker issues accordingly and/or let me know if there are any commits needed before cutting the branch.
- Nick
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Upayavira <uv...@odoko.co.uk>.
Given its triviality, I have made this change. Solr peeps, please view
the messages at the top of the two UIs and object if needs be.
Upayavira
On Thu, 10 Mar 2016, at 11:24 PM, Upayavira wrote:
> I need to check whether the Solr UI messages need quietening down
> (removing the big red "experimental" banners).
>
> This is trivial work that should be done before the 6.0 release.
> Apologies for going silent here - I've been absorbing the impact of
> major life changes.
>
> Upayavira
>
> On Thu, 10 Mar 2016, at 01:37 PM, Nicholas Knize wrote:
>> Thanks Mike! I will hold off on starting the release process until
>> next Wednesday at the earliest.
>>
>> >We should really reserve some time to "stop" adding new features and
>> >only fix bugs and API hickups
>>
>> 6_0 branch should already be in feature freeze. Only bug fixes, and
>> API cleanups (along with any necessary testing) should be committed
>> to 6_0.
>>
>> On Thu, Mar 10, 2016 at 5:33 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> Hi,
>>>
>>> Yes, please delay!
>>> The code is not yet releasable without further testing and API
>>> cleanups. That's my personal opinion, but others might have the same
>>> impression. A major release like 6.0 always needs some time for the
>>> pre-release cleanup, like deprecated APIs, API problems,... We
>>> should really reserve some time to "stop" adding new features and
>>> only fix bugs and API hickups. I wish, I could help, but I am
>>> unfortunately very busy at the moment.
>>>
>>> Uwe
>>>
>>>
-----
>>>
Uwe Schindler
>>>
H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>>
eMail: uwe@thetaphi.de
>>>
>>>
> -----Original Message-----
>>> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>>
> Sent: Thursday, March 10, 2016 11:13 AM
>>>
> To: Lucene/Solr dev <de...@lucene.apache.org>
>>> > Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>>> >
>>> > Hi Nick,
>>> >
>>> > Since we are still finding a number of bad bugs (!!) in the new
>>> > dimensional points, e.g. equals was broken on the range query,
>>> > the set
>>> > query for InetAddress didn't work, exceptions on merging sparse
>>> > fields, etc., and since at least e.g. Rob is working hard on
>>> > cutting
>>> > over legacy numerics usage to points, I think we should delay
>>> > cutting
>>> > the RC for now? Once the severity of the issues settles down I
>>> > think
>>> > it will become clearer that we're ready for the first RC?
>>> >
>>> > Thank you for being RM!
>>> >
>>> > Mike McCandless
>>> >
>>> > http://blog.mikemccandless.com
>>> >
>>> >
>>> > On Wed, Mar 9, 2016 at 5:11 PM, Nicholas Knize <nk...@gmail.com> wrote:
>>> > > This is a heads up that I will be starting the release process
>>> > > no earlier
>>> > > than 24 hours from now. Thanks to everyone in advance for their
>>> > > help
>>> > during
>>> > > this process.
>>> > >
>>> > > - Nick
>>> > >
>>> > > On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc
>>> > > <Lu...@bvdinfo.com> wrote:
>>> > >>
>>> > >> Hi,
>>> > >>
>>> > >>
>>> > >>
>>> > >> I added two JIRA issues (Lucene:
>>> > >> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
>>> > >> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
>>> > classes
>>> > >> that are still mutable and should either become immutable,
>>> > >> marked as
>>> > >> @lucene.experimental or get a comment why it’s not an issue for
>>> > >> that
>>> > case.
>>> > >>
>>> > >>
>>> > >>
>>> > >> Since they are part of the public API, I think now is the time
>>> > >> to update
>>> > >> them.
>>> > >>
>>> > >>
>>> > >>
>>> > >> I already converted MultiPhraseQuery
>>> > >> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and
>>> > committed
>>> > >> by Adrien Grand).
>>> > >>
>>> > >>
>>> > >>
>>> > >> Luc Vanlerberghe
>>> > >>
>>> > >>
>>> > >>
>>> > >> From: Joel Bernstein [mailto:joelsolr@gmail.com]
>>> > >> Sent: maandag 7 maart 2016 21:08
>>> > >> To: lucene dev
>>> > >> Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>>> > >>
>>> > >>
>>> > >>
>>> > >> "Major API and bug fixes (no features) can be committed without
>>> > >> my
>>> > >> approval before Friday as long as they're reviewed and approved
>>> > >> by
>>> > another
>>> > >> committer."
>>> > >>
>>> > >>
>>> > >>
>>> > >> Hmmm, are there really major API changes underway at this
>>> > >> point? As far
>>> > as
>>> > >> bug fixes needing another committer approval is not something
>>> > >> we've
>>> > done in
>>> > >> the past.
>>> > >>
>>> > >>
>>> > >> Joel Bernstein
>>> > >>
>>> > >> http://joelsolr.blogspot.com/
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com>
>>> > wrote:
>>> > >>
>>> > >> I think with all of the volatility surrounding the new Points
>>> > >> codec that
>>> > >> obvious bug/stability patches like these are OK? I know several
>>> > >> folks have
>>> > >> been working feverishly the past few days to fix serious (and
>>> > >> simplify) 6.0
>>> > >> issues and squash all of the jenkins failures to ensure
>>> > >> stability in time
>>> > >> for the major release. That being said, you're right that we
>>> > >> don't want
>>> > >> chaotic committing as we lead up to the release.
>>> > >>
>>> > >>
>>> > >>
>>> > >> So unless there are no objections I'll plan to move forward and
>>> > >> start the
>>> > >> release process this Friday. Until then, since this is a major
>>> > >> release, as
>>> > >> many people we can get to scrutinize and stabilize 6_0 over the
>>> > >> next 3-4
>>> > >> days the better. Major API and bug fixes (no features) can be
>>> > >> committed
>>> > >> without my approval before Friday as long as they're reviewed
>>> > >> and
>>> > approved
>>> > >> by another committer. If there is any uncertainty ping me on
>>> > >> this thread
>>> > or
>>> > >> the corresponding issue and I'll review. I will also send out
>>> > >> an email 24
>>> > >> hours before I start the release process.
>>> > >>
>>> > >>
>>> > >>
>>> > >> - Nick
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com
>>> > >> <da...@gmail.com> wrote:
>>> > >>
>>> > >> I just want to clarify you(Nick) / our expectations about this
>>> > >> release
>>> > >> branch. It seems, based on issues I've seen like LUCENE-7072,
>>> > >> that we can
>>> > >> commit to the release branch without your permission as RM. If
>>> > >> this is
>>> > >> true, then I presume the tacit approval is okay so long as it's
>>> > >> not a new
>>> > >> feature. Right?
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com>
>>> > wrote:
>>> > >>
>>> > >> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
>>> > >> keep the ball moving and volunteer as the 6.0.0 RM.
>>> > >>
>>> > >>
>>> > >>
>>> > >> If there are no objections my plan is to cut branch_6_0 early
>>> > >> next week -
>>> > >> Mon or Tues. Please mark blocker issues accordingly and/or let
>>> > >> me know
>>> > if
>>> > >> there are any commits needed before cutting the branch.
>>> > >>
>>> > >>
>>> > >>
>>> > >> - Nick
>>> > >>
>>> > >> --
>>> > >>
>>> > >> Lucene/Solr Search Committer, Consultant, Developer, Author,
>>> > >> Speaker
>>> > >>
>>> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> > >> http://www.solrenterprisesearchserver.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
>>>
>
Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Posted by Upayavira <uv...@odoko.co.uk>.
I need to check whether the Solr UI messages need quietening down
(removing the big red "experimental" banners).
This is trivial work that should be done before the 6.0 release.
Apologies for going silent here - I've been absorbing the impact of
major life changes.
Upayavira
On Thu, 10 Mar 2016, at 01:37 PM, Nicholas Knize wrote:
> Thanks Mike! I will hold off on starting the release process until
> next Wednesday at the earliest.
>
> >We should really reserve some time to "stop" adding new features and
> >only fix bugs and API hickups
>
> 6_0 branch should already be in feature freeze. Only bug fixes,
> and API cleanups (along with any necessary testing) should be
> committed to 6_0.
>
> On Thu, Mar 10, 2016 at 5:33 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi,
>>
>>
Yes, please delay!
>>
The code is not yet releasable without further testing and API
cleanups. That's my personal opinion, but others might have the same
impression. A major release like 6.0 always needs some time for the pre-
release cleanup, like deprecated APIs, API problems,... We should
really reserve some time to "stop" adding new features and only fix
bugs and API hickups. I wish, I could help, but I am unfortunately very
busy at the moment.
>>
>>
Uwe
>>
>>
-----
>>
Uwe Schindler
>>
H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>>
eMail: uwe@thetaphi.de
>>
>>
> -----Original Message-----
>> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>
> Sent: Thursday, March 10, 2016 11:13 AM
>>
> To: Lucene/Solr dev <de...@lucene.apache.org>
>> > Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>>
>
>>
> Hi Nick,
>>
>
>>
> Since we are still finding a number of bad bugs (!!) in the new
>>
> dimensional points, e.g. equals was broken on the range query, the set
>>
> query for InetAddress didn't work, exceptions on merging sparse
>>
> fields, etc., and since at least e.g. Rob is working hard on cutting
>>
> over legacy numerics usage to points, I think we should delay cutting
>>
> the RC for now? Once the severity of the issues settles down I think
>>
> it will become clearer that we're ready for the first RC?
>>
>
>>
> Thank you for being RM!
>>
>
>>
> Mike McCandless
>>
>
>>
> http://blog.mikemccandless.com
>>
>
>>
>
>>
> On Wed, Mar 9, 2016 at 5:11 PM, Nicholas Knize
> <nk...@gmail.com> wrote:
>>
> > This is a heads up that I will be starting the release process no
> > earlier
>>
> > than 24 hours from now. Thanks to everyone in advance for their help
>>
> during
>>
> > this process.
>>
> >
>>
> > - Nick
>>
> >
>>
> > On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc
>>
> > <Lu...@bvdinfo.com> wrote:
>>
> >>
>>
> >> Hi,
>>
> >>
>>
> >>
>>
> >>
>>
> >> I added two JIRA issues (Lucene:
>>
> >> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
>>
> >> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
>>
> classes
>>
> >> that are still mutable and should either become immutable,
> >> marked as
>>
> >> @lucene.experimental or get a comment why it’s not an issue
> >> for that
>>
> case.
>>
> >>
>>
> >>
>>
> >>
>>
> >> Since they are part of the public API, I think now is the time to
> >> update
>>
> >> them.
>>
> >>
>>
> >>
>>
> >>
>>
> >> I already converted MultiPhraseQuery
>>
> >> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and
>>
> committed
>>
> >> by Adrien Grand).
>>
> >>
>>
> >>
>>
> >>
>>
> >> Luc Vanlerberghe
>>
> >>
>>
> >>
>>
> >>
>>
> >> From: Joel Bernstein [mailto:joelsolr@gmail.com]
>>
> >> Sent: maandag 7 maart 2016 21:08
>>
> >> To: lucene dev
>>
> >> Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>>
> >>
>>
> >>
>>
> >>
>>
> >> "Major API and bug fixes (no features) can be committed without my
>>
> >> approval before Friday as long as they're reviewed and approved by
>>
> another
>>
> >> committer."
>>
> >>
>>
> >>
>>
> >>
>>
> >> Hmmm, are there really major API changes underway at this point?
> >> As far
>>
> as
>>
> >> bug fixes needing another committer approval is not something we've
>>
> done in
>>
> >> the past.
>>
> >>
>>
> >>
>>
> >> Joel Bernstein
>>
> >>
>>
> >> http://joelsolr.blogspot.com/
>>
> >>
>>
> >>
>>
> >>
>>
> >> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com>
>>
> wrote:
>>
> >>
>>
> >> I think with all of the volatility surrounding the new Points
> >> codec that
>>
> >> obvious bug/stability patches like these are OK? I know several
> >> folks have
>>
> >> been working feverishly the past few days to fix serious (and
> >> simplify) 6.0
>>
> >> issues and squash all of the jenkins failures to ensure stability
> >> in time
>>
> >> for the major release. That being said, you're right that we
> >> don't want
>>
> >> chaotic committing as we lead up to the release.
>>
> >>
>>
> >>
>>
> >>
>>
> >> So unless there are no objections I'll plan to move forward and
> >> start the
>>
> >> release process this Friday. Until then, since this is a major
> >> release, as
>>
> >> many people we can get to scrutinize and stabilize 6_0 over the
> >> next 3-4
>>
> >> days the better. Major API and bug fixes (no features) can be
> >> committed
>>
> >> without my approval before Friday as long as they're reviewed and
>>
> approved
>>
> >> by another committer. If there is any uncertainty ping me on this
> >> thread
>>
> or
>>
> >> the corresponding issue and I'll review. I will also send out an
> >> email 24
>>
> >> hours before I start the release process.
>>
> >>
>>
> >>
>>
> >>
>>
> >> - Nick
>>
> >>
>>
> >>
>>
> >>
>>
> >>
>>
> >>
>>
> >> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com
>>
> >> <da...@gmail.com> wrote:
>>
> >>
>>
> >> I just want to clarify you(Nick) / our expectations about this
> >> release
>>
> >> branch. It seems, based on issues I've seen like LUCENE-7072, that
> >> we can
>>
> >> commit to the release branch without your permission as RM. If
> >> this is
>>
> >> true, then I presume the tacit approval is okay so long as it's not
> >> a new
>>
> >> feature. Right?
>>
> >>
>>
> >>
>>
> >>
>>
> >> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com>
>>
> wrote:
>>
> >>
>>
> >> With the release of 5.5 and the previous discussion re: 6.0.0 I'd
> >> like to
>>
> >> keep the ball moving and volunteer as the 6.0.0 RM.
>>
> >>
>>
> >>
>>
> >>
>>
> >> If there are no objections my plan is to cut branch_6_0 early next
> >> week -
>>
> >> Mon or Tues. Please mark blocker issues accordingly and/or let
> >> me know
>>
> if
>>
> >> there are any commits needed before cutting the branch.
>>
> >>
>>
> >>
>>
> >>
>>
> >> - Nick
>>
> >>
>>
> >> --
>>
> >>
>>
> >> Lucene/Solr Search Committer, Consultant, Developer, Author,
> >> Speaker
>>
> >>
>>
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>
> >> http://www.solrenterprisesearchserver.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
>>
Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
Thanks Mike! I will hold off on starting the release process until next
Wednesday at the earliest.
> We should really reserve some time to "stop" adding new features and only
fix bugs and API hickups
6_0 branch should already be in feature freeze. Only bug fixes, and API
cleanups (along with any necessary testing) should be committed to 6_0.
On Thu, Mar 10, 2016 at 5:33 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> Yes, please delay!
> The code is not yet releasable without further testing and API cleanups.
> That's my personal opinion, but others might have the same impression. A
> major release like 6.0 always needs some time for the pre-release cleanup,
> like deprecated APIs, API problems,... We should really reserve some time
> to "stop" adding new features and only fix bugs and API hickups. I wish, I
> could help, but I am unfortunately very busy at the moment.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > Sent: Thursday, March 10, 2016 11:13 AM
> > To: Lucene/Solr dev <de...@lucene.apache.org>
> > Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
> >
> > Hi Nick,
> >
> > Since we are still finding a number of bad bugs (!!) in the new
> > dimensional points, e.g. equals was broken on the range query, the set
> > query for InetAddress didn't work, exceptions on merging sparse
> > fields, etc., and since at least e.g. Rob is working hard on cutting
> > over legacy numerics usage to points, I think we should delay cutting
> > the RC for now? Once the severity of the issues settles down I think
> > it will become clearer that we're ready for the first RC?
> >
> > Thank you for being RM!
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Wed, Mar 9, 2016 at 5:11 PM, Nicholas Knize <nk...@gmail.com> wrote:
> > > This is a heads up that I will be starting the release process no
> earlier
> > > than 24 hours from now. Thanks to everyone in advance for their help
> > during
> > > this process.
> > >
> > > - Nick
> > >
> > > On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc
> > > <Lu...@bvdinfo.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >>
> > >>
> > >> I added two JIRA issues (Lucene:
> > >> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
> > >> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
> > classes
> > >> that are still mutable and should either become immutable, marked as
> > >> @lucene.experimental or get a comment why it’s not an issue for that
> > case.
> > >>
> > >>
> > >>
> > >> Since they are part of the public API, I think now is the time to
> update
> > >> them.
> > >>
> > >>
> > >>
> > >> I already converted MultiPhraseQuery
> > >> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and
> > committed
> > >> by Adrien Grand).
> > >>
> > >>
> > >>
> > >> Luc Vanlerberghe
> > >>
> > >>
> > >>
> > >> From: Joel Bernstein [mailto:joelsolr@gmail.com]
> > >> Sent: maandag 7 maart 2016 21:08
> > >> To: lucene dev
> > >> Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
> > >>
> > >>
> > >>
> > >> "Major API and bug fixes (no features) can be committed without my
> > >> approval before Friday as long as they're reviewed and approved by
> > another
> > >> committer."
> > >>
> > >>
> > >>
> > >> Hmmm, are there really major API changes underway at this point? As
> far
> > as
> > >> bug fixes needing another committer approval is not something we've
> > done in
> > >> the past.
> > >>
> > >>
> > >> Joel Bernstein
> > >>
> > >> http://joelsolr.blogspot.com/
> > >>
> > >>
> > >>
> > >> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com>
> > wrote:
> > >>
> > >> I think with all of the volatility surrounding the new Points codec
> that
> > >> obvious bug/stability patches like these are OK? I know several folks
> have
> > >> been working feverishly the past few days to fix serious (and
> simplify) 6.0
> > >> issues and squash all of the jenkins failures to ensure stability in
> time
> > >> for the major release. That being said, you're right that we don't
> want
> > >> chaotic committing as we lead up to the release.
> > >>
> > >>
> > >>
> > >> So unless there are no objections I'll plan to move forward and start
> the
> > >> release process this Friday. Until then, since this is a major
> release, as
> > >> many people we can get to scrutinize and stabilize 6_0 over the next
> 3-4
> > >> days the better. Major API and bug fixes (no features) can be
> committed
> > >> without my approval before Friday as long as they're reviewed and
> > approved
> > >> by another committer. If there is any uncertainty ping me on this
> thread
> > or
> > >> the corresponding issue and I'll review. I will also send out an
> email 24
> > >> hours before I start the release process.
> > >>
> > >>
> > >>
> > >> - Nick
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com
> > >> <da...@gmail.com> wrote:
> > >>
> > >> I just want to clarify you(Nick) / our expectations about this release
> > >> branch. It seems, based on issues I've seen like LUCENE-7072, that
> we can
> > >> commit to the release branch without your permission as RM. If this
> is
> > >> true, then I presume the tacit approval is okay so long as it's not a
> new
> > >> feature. Right?
> > >>
> > >>
> > >>
> > >> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com>
> > wrote:
> > >>
> > >> With the release of 5.5 and the previous discussion re: 6.0.0 I'd
> like to
> > >> keep the ball moving and volunteer as the 6.0.0 RM.
> > >>
> > >>
> > >>
> > >> If there are no objections my plan is to cut branch_6_0 early next
> week -
> > >> Mon or Tues. Please mark blocker issues accordingly and/or let me know
> > if
> > >> there are any commits needed before cutting the branch.
> > >>
> > >>
> > >>
> > >> - Nick
> > >>
> > >> --
> > >>
> > >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > >>
> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > >> http://www.solrenterprisesearchserver.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
>
>
RE: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
Yes, please delay!
The code is not yet releasable without further testing and API cleanups. That's my personal opinion, but others might have the same impression. A major release like 6.0 always needs some time for the pre-release cleanup, like deprecated APIs, API problems,... We should really reserve some time to "stop" adding new features and only fix bugs and API hickups. I wish, I could help, but I am unfortunately very busy at the moment.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Thursday, March 10, 2016 11:13 AM
> To: Lucene/Solr dev <de...@lucene.apache.org>
> Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>
> Hi Nick,
>
> Since we are still finding a number of bad bugs (!!) in the new
> dimensional points, e.g. equals was broken on the range query, the set
> query for InetAddress didn't work, exceptions on merging sparse
> fields, etc., and since at least e.g. Rob is working hard on cutting
> over legacy numerics usage to points, I think we should delay cutting
> the RC for now? Once the severity of the issues settles down I think
> it will become clearer that we're ready for the first RC?
>
> Thank you for being RM!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Mar 9, 2016 at 5:11 PM, Nicholas Knize <nk...@gmail.com> wrote:
> > This is a heads up that I will be starting the release process no earlier
> > than 24 hours from now. Thanks to everyone in advance for their help
> during
> > this process.
> >
> > - Nick
> >
> > On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc
> > <Lu...@bvdinfo.com> wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >> I added two JIRA issues (Lucene:
> >> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
> >> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
> classes
> >> that are still mutable and should either become immutable, marked as
> >> @lucene.experimental or get a comment why it’s not an issue for that
> case.
> >>
> >>
> >>
> >> Since they are part of the public API, I think now is the time to update
> >> them.
> >>
> >>
> >>
> >> I already converted MultiPhraseQuery
> >> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and
> committed
> >> by Adrien Grand).
> >>
> >>
> >>
> >> Luc Vanlerberghe
> >>
> >>
> >>
> >> From: Joel Bernstein [mailto:joelsolr@gmail.com]
> >> Sent: maandag 7 maart 2016 21:08
> >> To: lucene dev
> >> Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
> >>
> >>
> >>
> >> "Major API and bug fixes (no features) can be committed without my
> >> approval before Friday as long as they're reviewed and approved by
> another
> >> committer."
> >>
> >>
> >>
> >> Hmmm, are there really major API changes underway at this point? As far
> as
> >> bug fixes needing another committer approval is not something we've
> done in
> >> the past.
> >>
> >>
> >> Joel Bernstein
> >>
> >> http://joelsolr.blogspot.com/
> >>
> >>
> >>
> >> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com>
> wrote:
> >>
> >> I think with all of the volatility surrounding the new Points codec that
> >> obvious bug/stability patches like these are OK? I know several folks have
> >> been working feverishly the past few days to fix serious (and simplify) 6.0
> >> issues and squash all of the jenkins failures to ensure stability in time
> >> for the major release. That being said, you're right that we don't want
> >> chaotic committing as we lead up to the release.
> >>
> >>
> >>
> >> So unless there are no objections I'll plan to move forward and start the
> >> release process this Friday. Until then, since this is a major release, as
> >> many people we can get to scrutinize and stabilize 6_0 over the next 3-4
> >> days the better. Major API and bug fixes (no features) can be committed
> >> without my approval before Friday as long as they're reviewed and
> approved
> >> by another committer. If there is any uncertainty ping me on this thread
> or
> >> the corresponding issue and I'll review. I will also send out an email 24
> >> hours before I start the release process.
> >>
> >>
> >>
> >> - Nick
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com
> >> <da...@gmail.com> wrote:
> >>
> >> I just want to clarify you(Nick) / our expectations about this release
> >> branch. It seems, based on issues I've seen like LUCENE-7072, that we can
> >> commit to the release branch without your permission as RM. If this is
> >> true, then I presume the tacit approval is okay so long as it's not a new
> >> feature. Right?
> >>
> >>
> >>
> >> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com>
> wrote:
> >>
> >> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
> >> keep the ball moving and volunteer as the 6.0.0 RM.
> >>
> >>
> >>
> >> If there are no objections my plan is to cut branch_6_0 early next week -
> >> Mon or Tues. Please mark blocker issues accordingly and/or let me know
> if
> >> there are any commits needed before cutting the branch.
> >>
> >>
> >>
> >> - Nick
> >>
> >> --
> >>
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >>
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> http://www.solrenterprisesearchserver.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
Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
Hi Nick,
Since we are still finding a number of bad bugs (!!) in the new
dimensional points, e.g. equals was broken on the range query, the set
query for InetAddress didn't work, exceptions on merging sparse
fields, etc., and since at least e.g. Rob is working hard on cutting
over legacy numerics usage to points, I think we should delay cutting
the RC for now? Once the severity of the issues settles down I think
it will become clearer that we're ready for the first RC?
Thank you for being RM!
Mike McCandless
http://blog.mikemccandless.com
On Wed, Mar 9, 2016 at 5:11 PM, Nicholas Knize <nk...@gmail.com> wrote:
> This is a heads up that I will be starting the release process no earlier
> than 24 hours from now. Thanks to everyone in advance for their help during
> this process.
>
> - Nick
>
> On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc
> <Lu...@bvdinfo.com> wrote:
>>
>> Hi,
>>
>>
>>
>> I added two JIRA issues (Lucene:
>> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
>> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query classes
>> that are still mutable and should either become immutable, marked as
>> @lucene.experimental or get a comment why it’s not an issue for that case.
>>
>>
>>
>> Since they are part of the public API, I think now is the time to update
>> them.
>>
>>
>>
>> I already converted MultiPhraseQuery
>> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and committed
>> by Adrien Grand).
>>
>>
>>
>> Luc Vanlerberghe
>>
>>
>>
>> From: Joel Bernstein [mailto:joelsolr@gmail.com]
>> Sent: maandag 7 maart 2016 21:08
>> To: lucene dev
>> Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>>
>>
>>
>> "Major API and bug fixes (no features) can be committed without my
>> approval before Friday as long as they're reviewed and approved by another
>> committer."
>>
>>
>>
>> Hmmm, are there really major API changes underway at this point? As far as
>> bug fixes needing another committer approval is not something we've done in
>> the past.
>>
>>
>> Joel Bernstein
>>
>> http://joelsolr.blogspot.com/
>>
>>
>>
>> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com> wrote:
>>
>> I think with all of the volatility surrounding the new Points codec that
>> obvious bug/stability patches like these are OK? I know several folks have
>> been working feverishly the past few days to fix serious (and simplify) 6.0
>> issues and squash all of the jenkins failures to ensure stability in time
>> for the major release. That being said, you're right that we don't want
>> chaotic committing as we lead up to the release.
>>
>>
>>
>> So unless there are no objections I'll plan to move forward and start the
>> release process this Friday. Until then, since this is a major release, as
>> many people we can get to scrutinize and stabilize 6_0 over the next 3-4
>> days the better. Major API and bug fixes (no features) can be committed
>> without my approval before Friday as long as they're reviewed and approved
>> by another committer. If there is any uncertainty ping me on this thread or
>> the corresponding issue and I'll review. I will also send out an email 24
>> hours before I start the release process.
>>
>>
>>
>> - Nick
>>
>>
>>
>>
>>
>> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com
>> <da...@gmail.com> wrote:
>>
>> I just want to clarify you(Nick) / our expectations about this release
>> branch. It seems, based on issues I've seen like LUCENE-7072, that we can
>> commit to the release branch without your permission as RM. If this is
>> true, then I presume the tacit approval is okay so long as it's not a new
>> feature. Right?
>>
>>
>>
>> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com> wrote:
>>
>> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
>> keep the ball moving and volunteer as the 6.0.0 RM.
>>
>>
>>
>> If there are no objections my plan is to cut branch_6_0 early next week -
>> Mon or Tues. Please mark blocker issues accordingly and/or let me know if
>> there are any commits needed before cutting the branch.
>>
>>
>>
>> - Nick
>>
>> --
>>
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
This is a heads up that I will be starting the release process no earlier
than 24 hours from now. Thanks to everyone in advance for their help during
this process.
- Nick
On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc <
Luc.Vanlerberghe@bvdinfo.com> wrote:
> Hi,
>
>
>
> I added two JIRA issues (Lucene:
> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
> classes that are still mutable and should either become immutable, marked
> as @lucene.experimental or get a comment why it’s not an issue for that
> case.
>
>
>
> Since they are part of the public API, I think now is the time to update
> them.
>
>
>
> I already converted MultiPhraseQuery (
> https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and committed
> by Adrien Grand).
>
>
>
> Luc Vanlerberghe
>
>
>
> *From:* Joel Bernstein [mailto:joelsolr@gmail.com]
> *Sent:* maandag 7 maart 2016 21:08
> *To:* lucene dev
> *Subject:* [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>
>
>
> "Major API and bug fixes (no features) can be committed without my
> approval before Friday as long as they're reviewed and approved by another
> committer."
>
>
>
> Hmmm, are there really major API changes underway at this point? As far as
> bug fixes needing another committer approval is not something we've done in
> the past.
>
>
> Joel Bernstein
>
> http://joelsolr.blogspot.com/
>
>
>
> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize <nk...@gmail.com> wrote:
>
> I think with all of the volatility surrounding the new Points codec that
> obvious bug/stability patches like these are OK? I know several folks have
> been working feverishly the past few days to fix serious (and simplify) 6.0
> issues and squash all of the jenkins failures to ensure stability in time
> for the major release. That being said, you're right that we don't want
> chaotic committing as we lead up to the release.
>
>
>
> So unless there are no objections I'll plan to move forward and start the
> release process this Friday. Until then, since this is a major release, as
> many people we can get to scrutinize and stabilize 6_0 over the next 3-4
> days the better. Major API and bug fixes (no features) can be committed
> without my approval before Friday as long as they're reviewed and approved
> by another committer. If there is any uncertainty ping me on this thread or
> the corresponding issue and I'll review. I will also send out an email 24
> hours before I start the release process.
>
>
>
> - Nick
>
>
>
>
>
> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smiley@gmail.com <
> david.w.smiley@gmail.com> wrote:
>
> I just want to clarify you(Nick) / our expectations about this release
> branch. It seems, based on issues I've seen like LUCENE-7072, that we can
> commit to the release branch without your permission as RM. If this is
> true, then I presume the tacit approval is okay so long as it's not a new
> feature. Right?
>
>
>
> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize <nk...@gmail.com> wrote:
>
> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
> keep the ball moving and volunteer as the 6.0.0 RM.
>
>
>
> If there are no objections my plan is to cut branch_6_0 early next week -
> Mon or Tues. Please mark blocker issues accordingly and/or let me know if
> there are any commits needed before cutting the branch.
>
>
>
> - Nick
>
> --
>
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>
>
>