Re: Lucene/Solr 6.0.0 Release Branch

[Upayavira]

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 <u...@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: u...@thetaphi.de
>>>
>>>
> -Original Message-
>>> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
>>>
> Sent: Thursday, March 10, 2016 11:13 AM
>>>
> To: Lucene/Solr dev <dev@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 <nkn...@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
>>> > > <luc.vanlerber...@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 an

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Upayavira]

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 <u...@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: u...@thetaphi.de
>>
>>
> -Original Message-
>> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
>>
> Sent: Thursday, March 10, 2016 11:13 AM
>>
> To: Lucene/Solr dev <dev@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
> <nkn...@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
>>
> > <luc.vanlerber...@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:joels...@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
>>

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

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 <u...@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: u...@thetaphi.de
>
> > -Original Message-
> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
> > Sent: Thursday, March 10, 2016 11:13 AM
> > To: Lucene/Solr dev <dev@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 <nkn...@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
> > > <luc.vanlerber...@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:joels...@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 <nkn...@gmail.com>
> > wrote:
> > >>
> > >> I think with all of the volatility surrounding the new Points codec
> that
> > >> obvious b

RE: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Uwe Schindler]

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: u...@thetaphi.de

> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Thursday, March 10, 2016 11:13 AM
> To: Lucene/Solr dev <dev@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 <nkn...@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
> > <luc.vanlerber...@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:joels...@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 <nkn...@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

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

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 <nkn...@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
> <luc.vanlerber...@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:joels...@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 <nkn...@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.smi...@gmail.com
>> <david.w.smi...@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 <nkn...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

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.vanlerber...@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:joels...@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 <nkn...@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.smi...@gmail.com <
> david.w.smi...@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 <nkn...@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: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Vanlerberghe, Luc]

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:joels...@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 
<nkn...@gmail.com<mailto:nkn...@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.smi...@gmail.com<mailto:david.w.smi...@gmail.com> 
<david.w.smi...@gmail.com<mailto:david.w.smi...@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 
<nkn...@gmail.com<mailto:nkn...@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

[Yonik Seeley]

On Mon, Mar 7, 2016 at 3:07 PM, Joel Bernstein  wrote:
> As far as
> bug fixes needing another committer approval is not something we've done in
> the past.

Correct.  And the burden should not be on any RM to decide either what
bug fixes go in or not either... that is asking way too much (i.e.
everyone has their own areas of expertise). The burden of decisions
continues to be on the committer, and if they are in doubt, they
should consult the larger dev community.

If a commit will cause the RM extra work (i.e. another respin or
whatever), then it seems appropriate to ask if they are willing to do
so.
As Mark pointed out earlier, a RM has no official power - they have
simply volunteered to do the grunt work of turning out release
candidates, etc.  It doesn't even have to be a single person - a group
could collaborate to get everything necessary done.

-Yonik

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

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

> Hmmm, are there really major API changes underway at this point?

Major fixes (not changes) if they're needed. (e.g, the types of fixes that
have been worked over the weekend to shore up the API for the major
release)

> As far as bug fixes needing another committer approval is not something
we've done in the past.

This is only for 6_0 and in re: to David's question "that we can commit to
the release branch without your permission as RM."


On Mon, Mar 7, 2016 at 2:07 PM, Joel Bernstein  wrote:

> "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  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.smi...@gmail.com <
>> david.w.smi...@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  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

[Joel Bernstein]

"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  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.smi...@gmail.com <
> david.w.smi...@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  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

[Nicholas Knize]

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.smi...@gmail.com <
david.w.smi...@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  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

[david.w.smi...@gmail.com]

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

[Shawn Heisey]

On 3/4/2016 7:35 AM, Robert Muir wrote:
> On Fri, Mar 4, 2016 at 6:00 AM, Vanlerberghe, Luc
>  wrote:
>> Basically, they apply changes at the lowest release for which the change is 
>> applicable and then merge the change upwards to the other releases and 
>> eventually to trunk.
> This just creates a worse problem. Instead of "feature/bugfix didn't
> make it into that release", you can have "feature/bugfix disappeared
> entirely!".

I agree with Robert.

Our usual method starts with master and works down.  If the backporting
doesn't happen, the change is not completely lost -- it will eventually
make it into a release because at some point master will be branched
into a new stable branch.  With the bottom-up approach, if
forward-porting the original commit doesn't happen, then the change will
be gone from new releases the next time a higher branch is created.

I understand the motivation to do it that way.  Some things (deprecation
removal in particular) are easier, but the top-down approach handles
mis-steps better.  We can always break from the usual pattern for
situations where it makes sense (such as a change that includes
deprecations), but I think changing the normal approach is the wrong
thing to do.

Thanks,
Shawn


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

Re: Lucene/Solr 6.0.0 Release Branch

[Robert Muir]

On Fri, Mar 4, 2016 at 6:00 AM, Vanlerberghe, Luc
 wrote:

> Basically, they apply changes at the lowest release for which the change is 
> applicable and then merge the change upwards to the other releases and 
> eventually to trunk.
>

This just creates a worse problem. Instead of "feature/bugfix didn't
make it into that release", you can have "feature/bugfix disappeared
entirely!".

Shalin, thanks for fixing!

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

Re: Lucene/Solr 6.0.0 Release Branch

[Vanlerberghe, Luc]

Hi,

With the recent switch to git and the debate on branching for 6.x going on, may 
I suggest taking a look at the git workflow of the apache Cassandra project?
http://wiki.apache.org/cassandra/HowToContribute#Committing
(There's a link to a Google TechTalk video with an in-depth explanation too)

They currently have 4 (4!) supported releases, each in their own branch, and 
still keep everything manageable.

Basically, they apply changes at the lowest release for which the change is 
applicable and then merge the change upwards to the other releases and 
eventually to trunk.

IMHO it has the following advantages:
- A fix for an issue (even if it would be a long-running side-branch) occurs 
only once in the full project log.
- No more cherry-picking
- Instead of having parallel logs per version, it's immediately clear which 
fixes are applied to which version
- No fixes for a lower version can be forgotten in a higher version (the 
committer of the next fix would notice)
- Back-porting is still possible if really necessary by cherry-picking. The 
merge-upward would be a no-op, but still make clear the versions are in sync.
- If you have a graphical tool to visualize the log (even if only using ascii 
art), it looks beautiful :)

If you want to take a look, their git repository is at: 
http://git-wip-us.apache.org/repos/asf/cassandra.git

Luc


-Original Message-
From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com] 
Sent: donderdag 3 maart 2016 17:30
To: dev@lucene.apache.org
Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

Mike,

I'll fix the TestBackwardsCompatibility. The mistake was to freeze the
6x branch in the first place. The release branch is the one which
should be frozen. I specifically asked the RM to cut the branch to let
others progress but I received no replies -- which is why I was forced
to do it myself. In future, the RM should keep this in mind and not
block others. The rest of the problem was because I am new to Git --
in subversion a release branch is always copied from the server so
pulling latest changes locally before creating the branch did not
cross my mind.

On Thu, Mar 3, 2016 at 9:46 PM, Michael McCandless
<luc...@mikemccandless.com> wrote:
> Shalin,
>
> In the future please don't jump the gun like this?
>
> It has caused a lot of unnecessary chaos.  It should be the RM, and
> only the RM, that is doing things like creating release branches,
> bumping versions, etc., at release time.
>
> Also, your changes to bump the version on 6.x seem to be causing
> TestBackwardsCompatibility to be failing.  Can you please fix that?
> In the future, when you are RM, please run tests when bumping versions
> before pushing.
>
> A major release is hard enough with only one chef.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar
> <shalinman...@gmail.com> wrote:
>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>
>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote:
>>> This is missing a bunch of yesterday's branch_6x changes. Some of
>>> david smiley's spatial work, at least one of my commits.
>>>
>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>> <shalinman...@gmail.com> wrote:
>>>> FYI, I have created the branch_6_0 so that we can continue to commit
>>>> stuff intended for 6.1 on master and branch_6x. I have also added the
>>>> 6.1.0 version on branch_6x and master.
>>>>
>>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org> wrote:
>>>>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>>>>>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>>>>>  I have stuff to push into master and that should eventually make it
>>>>>> into 6.1, and it will be easy to forget to backport stuff if there's a
>>>>>> week before I can do that…
>>>>>
>>>>> +1
>>>>>
>>>>> When I saw Nick's email about branch_6x being feature frozen, my first
>>>>> thought was that we don't (and really can't) feature freeze the stable
>>>>> branch -- isn't new feature development (for the next minor release in
>>>>> the current major version) the entire purpose of branch_Nx?
>>>>>
>>>>> A feature freeze on a specific minor version does make sense.  I've seen
>>>>> a couple of people say that we have, but there are also a few messages
>>>>> from people saying that they want to include new functionality in 6.0.
>>>>&g

Re: Lucene/Solr 6.0.0 Release Branch

[Anshum Gupta]

Sure, I will. Thanks !

On Thu, Mar 3, 2016 at 11:20 AM, Nicholas Knize  wrote:

> I quickly skimmed the patches. I'm OK with them being backported to 6.0.
> Can you mark the Fix Version/s accordingly?
>
> Thanks!
>
> On Thu, Mar 3, 2016 at 1:11 PM, Anshum Gupta 
> wrote:
>
>> The releases are demanding, specially major versions, so thanks for all
>> the effort Nick.
>>
>> I would like to commit SOLR-8423 and SOLR-8725 to 6.0. They aren't
>> blockers but are bugs and the patch for both are ready.
>>
>> If you are fine with it, I'll commit to 6.0 else, I'd push it out with
>> 6.1. SOLR-8725 is certainly something that I'd push out with 5.5.1 (and if
>> 5.6 happens, with 5.6).
>>
>> On Thu, Mar 3, 2016 at 10:28 AM, Nicholas Knize  wrote:
>>
>>> > hours (acceptable), not days (unacceptable).
>>>
>>> ++ I definitely agree with this. And it looks like the time period here
>>> was less than a day?
>>>
>>> >  there were multiple questions about it from more than one person
>>> over a couple days
>>>
>>> ?? I do not see these questions? They're certainly not in this thread
>>> which is where all of the branching was being discussed. If there are
>>> separate conversation threads then I think as the RM I should know about
>>> them?
>>>
>>> > If you’re going to be AFK for extended periods, please let people
>>> know.
>>>
>>> ++ This is definitely important. I'm not sure I agree that < 24 hours
>>> constitutes an extended period in this case. Especially given that its the
>>> first major release on the git infrastructure?
>>>
>>> Regardless, thank you to everyone that helped settle these branches.
>>>
>>> - Nick
>>>
>>>
>>>
>>> On Thu, Mar 3, 2016 at 12:09 PM, Steve Rowe  wrote:
>>>
 First, Nick, thanks for your RM work.

 > On Mar 3, 2016, at 12:53 PM, Nicholas Knize  wrote:

 > > The mistake was to freeze the 6x branch in the first place. The
 release branch is the one which should be frozen.
 >
 >  I certainly agree with this. However, over a week ago there was a
 request to hold off on creating the 6_0 branch until Jenkins settled with a
 6x. I received no push back on this suggestion so this was the plan that
 was executed (several days after that request was sent).

 I guess I took this as meaning a freeze on *branch_6x* of hours
 (acceptable), not days (unacceptable).

 > I think Mike is suggesting, and I agree with this, there needs to be
 a reasonable amount of time given for someone to respond.


 My impression was that you were intentionally ignoring questions about
 creation of the 6.0 branch, since there were multiple questions about it
 from more than one person over a couple days with no response from you, but
 meanwhile, you responded on other threads.  (Sorry, I haven’t gone back and
 found the exact messages that left me with this impression, so I guess I
 could be wrong.)

 One of the RM’s most important responsibilities is timely
 communication.  If you’re going to be AFK for extended periods, please let
 people know.

 --
 Steve
 www.lucidworks.com


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


>>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>


-- 
Anshum Gupta

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

I quickly skimmed the patches. I'm OK with them being backported to 6.0.
Can you mark the Fix Version/s accordingly?

Thanks!

On Thu, Mar 3, 2016 at 1:11 PM, Anshum Gupta  wrote:

> The releases are demanding, specially major versions, so thanks for all
> the effort Nick.
>
> I would like to commit SOLR-8423 and SOLR-8725 to 6.0. They aren't
> blockers but are bugs and the patch for both are ready.
>
> If you are fine with it, I'll commit to 6.0 else, I'd push it out with
> 6.1. SOLR-8725 is certainly something that I'd push out with 5.5.1 (and if
> 5.6 happens, with 5.6).
>
> On Thu, Mar 3, 2016 at 10:28 AM, Nicholas Knize  wrote:
>
>> > hours (acceptable), not days (unacceptable).
>>
>> ++ I definitely agree with this. And it looks like the time period here
>> was less than a day?
>>
>> >  there were multiple questions about it from more than one person over
>> a couple days
>>
>> ?? I do not see these questions? They're certainly not in this thread
>> which is where all of the branching was being discussed. If there are
>> separate conversation threads then I think as the RM I should know about
>> them?
>>
>> > If you’re going to be AFK for extended periods, please let people know.
>>
>> ++ This is definitely important. I'm not sure I agree that < 24 hours
>> constitutes an extended period in this case. Especially given that its the
>> first major release on the git infrastructure?
>>
>> Regardless, thank you to everyone that helped settle these branches.
>>
>> - Nick
>>
>>
>>
>> On Thu, Mar 3, 2016 at 12:09 PM, Steve Rowe  wrote:
>>
>>> First, Nick, thanks for your RM work.
>>>
>>> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize  wrote:
>>>
>>> > > The mistake was to freeze the 6x branch in the first place. The
>>> release branch is the one which should be frozen.
>>> >
>>> >  I certainly agree with this. However, over a week ago there was a
>>> request to hold off on creating the 6_0 branch until Jenkins settled with a
>>> 6x. I received no push back on this suggestion so this was the plan that
>>> was executed (several days after that request was sent).
>>>
>>> I guess I took this as meaning a freeze on *branch_6x* of hours
>>> (acceptable), not days (unacceptable).
>>>
>>> > I think Mike is suggesting, and I agree with this, there needs to be a
>>> reasonable amount of time given for someone to respond.
>>>
>>>
>>> My impression was that you were intentionally ignoring questions about
>>> creation of the 6.0 branch, since there were multiple questions about it
>>> from more than one person over a couple days with no response from you, but
>>> meanwhile, you responded on other threads.  (Sorry, I haven’t gone back and
>>> found the exact messages that left me with this impression, so I guess I
>>> could be wrong.)
>>>
>>> One of the RM’s most important responsibilities is timely
>>> communication.  If you’re going to be AFK for extended periods, please let
>>> people know.
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>
>
> --
> Anshum Gupta
>

Re: Lucene/Solr 6.0.0 Release Branch

[Anshum Gupta]

The releases are demanding, specially major versions, so thanks for all the
effort Nick.

I would like to commit SOLR-8423 and SOLR-8725 to 6.0. They aren't blockers
but are bugs and the patch for both are ready.

If you are fine with it, I'll commit to 6.0 else, I'd push it out with 6.1.
SOLR-8725 is certainly something that I'd push out with 5.5.1 (and if 5.6
happens, with 5.6).

On Thu, Mar 3, 2016 at 10:28 AM, Nicholas Knize  wrote:

> > hours (acceptable), not days (unacceptable).
>
> ++ I definitely agree with this. And it looks like the time period here
> was less than a day?
>
> >  there were multiple questions about it from more than one person over
> a couple days
>
> ?? I do not see these questions? They're certainly not in this thread
> which is where all of the branching was being discussed. If there are
> separate conversation threads then I think as the RM I should know about
> them?
>
> > If you’re going to be AFK for extended periods, please let people know.
>
> ++ This is definitely important. I'm not sure I agree that < 24 hours
> constitutes an extended period in this case. Especially given that its the
> first major release on the git infrastructure?
>
> Regardless, thank you to everyone that helped settle these branches.
>
> - Nick
>
>
>
> On Thu, Mar 3, 2016 at 12:09 PM, Steve Rowe  wrote:
>
>> First, Nick, thanks for your RM work.
>>
>> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize  wrote:
>>
>> > > The mistake was to freeze the 6x branch in the first place. The
>> release branch is the one which should be frozen.
>> >
>> >  I certainly agree with this. However, over a week ago there was a
>> request to hold off on creating the 6_0 branch until Jenkins settled with a
>> 6x. I received no push back on this suggestion so this was the plan that
>> was executed (several days after that request was sent).
>>
>> I guess I took this as meaning a freeze on *branch_6x* of hours
>> (acceptable), not days (unacceptable).
>>
>> > I think Mike is suggesting, and I agree with this, there needs to be a
>> reasonable amount of time given for someone to respond.
>>
>>
>> My impression was that you were intentionally ignoring questions about
>> creation of the 6.0 branch, since there were multiple questions about it
>> from more than one person over a couple days with no response from you, but
>> meanwhile, you responded on other threads.  (Sorry, I haven’t gone back and
>> found the exact messages that left me with this impression, so I guess I
>> could be wrong.)
>>
>> One of the RM’s most important responsibilities is timely communication.
>> If you’re going to be AFK for extended periods, please let people know.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>


-- 
Anshum Gupta

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

> hours (acceptable), not days (unacceptable).

++ I definitely agree with this. And it looks like the time period here was
less than a day?

>  there were multiple questions about it from more than one person over a
couple days

?? I do not see these questions? They're certainly not in this thread which
is where all of the branching was being discussed. If there are separate
conversation threads then I think as the RM I should know about them?

> If you’re going to be AFK for extended periods, please let people know.

++ This is definitely important. I'm not sure I agree that < 24 hours
constitutes an extended period in this case. Especially given that its the
first major release on the git infrastructure?

Regardless, thank you to everyone that helped settle these branches.

- Nick



On Thu, Mar 3, 2016 at 12:09 PM, Steve Rowe  wrote:

> First, Nick, thanks for your RM work.
>
> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize  wrote:
>
> > > The mistake was to freeze the 6x branch in the first place. The
> release branch is the one which should be frozen.
> >
> >  I certainly agree with this. However, over a week ago there was a
> request to hold off on creating the 6_0 branch until Jenkins settled with a
> 6x. I received no push back on this suggestion so this was the plan that
> was executed (several days after that request was sent).
>
> I guess I took this as meaning a freeze on *branch_6x* of hours
> (acceptable), not days (unacceptable).
>
> > I think Mike is suggesting, and I agree with this, there needs to be a
> reasonable amount of time given for someone to respond.
>
>
> My impression was that you were intentionally ignoring questions about
> creation of the 6.0 branch, since there were multiple questions about it
> from more than one person over a couple days with no response from you, but
> meanwhile, you responded on other threads.  (Sorry, I haven’t gone back and
> found the exact messages that left me with this impression, so I guess I
> could be wrong.)
>
> One of the RM’s most important responsibilities is timely communication.
> If you’re going to be AFK for extended periods, please let people know.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 Release Branch

[Steve Rowe]

First, Nick, thanks for your RM work.

> On Mar 3, 2016, at 12:53 PM, Nicholas Knize  wrote:

> > The mistake was to freeze the 6x branch in the first place. The release 
> > branch is the one which should be frozen.
> 
>  I certainly agree with this. However, over a week ago there was a request to 
> hold off on creating the 6_0 branch until Jenkins settled with a 6x. I 
> received no push back on this suggestion so this was the plan that was 
> executed (several days after that request was sent). 

I guess I took this as meaning a freeze on *branch_6x* of hours (acceptable), 
not days (unacceptable).

> I think Mike is suggesting, and I agree with this, there needs to be a 
> reasonable amount of time given for someone to respond.


My impression was that you were intentionally ignoring questions about creation 
of the 6.0 branch, since there were multiple questions about it from more than 
one person over a couple days with no response from you, but meanwhile, you 
responded on other threads.  (Sorry, I haven’t gone back and found the exact 
messages that left me with this impression, so I guess I could be wrong.)

One of the RM’s most important responsibilities is timely communication.  If 
you’re going to be AFK for extended periods, please let people know.

--
Steve
www.lucidworks.com


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

Re: Lucene/Solr 6.0.0 Release Branch

[Dawid Weiss]

I wouldn't read so, to be honest. This isn't so convoluted:

https://git-scm.com/docs/git-diff

Quote:

git diff [--options]   [--] […]
This is to view the changes between two arbitrary .

git diff [--options] .. [--] […]
This is synonymous to the previous form.

I use it all the time (never used the triple dot notation, to be
honest). It is what you expect it to be -- it's essentially a diff of
changes between two commits (as if you checked them out into two
folders and ran a recursive diff on both).

Dawid

On Thu, Mar 3, 2016 at 6:58 PM, Steve Rowe  wrote:
> Nearly all of my git knowledge is from possibly wrongheaded stack overflow 
> posts - in this case 
>  
> where chaiyachaiya said "git diff b1..b2, show you what is in b2 that is not 
> in b1. So git diff b1..b2 and git diff b2..b1 will not have the same output.”
>
> Re-reading that comment I see I missed the next sentence: "On the contrary, 
> git b1...b2, show you what is in b1 XOR b2 (either b1 or b2 but not both). So 
> git b1...b2 is equal to git b2...b1"
>
> Shoulda used the triple-dot syntax instead of the double-dot syntax.  Git, I 
> love you.
>
> --
> Steve
> www.lucidworks.com
>
>> On Mar 3, 2016, at 12:49 PM, Dawid Weiss  wrote:
>>
>>> (with minor solr/CHANGES.txt fixups) and then diffing both directions:
>>>
>>> git diff branch_6_0..branch_6x
>>> git diff branch_6x..branch_6_0
>>
>> Wait, can it ever be assymetric? I'd say it's impossible -- it should
>> always be a "reverse" diff of the another?
>>
>> Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 Release Branch

[Steve Rowe]

Nearly all of my git knowledge is from possibly wrongheaded stack overflow 
posts - in this case 
 
where chaiyachaiya said "git diff b1..b2, show you what is in b2 that is not in 
b1. So git diff b1..b2 and git diff b2..b1 will not have the same output.”

Re-reading that comment I see I missed the next sentence: "On the contrary, git 
b1...b2, show you what is in b1 XOR b2 (either b1 or b2 but not both). So git 
b1...b2 is equal to git b2...b1"

Shoulda used the triple-dot syntax instead of the double-dot syntax.  Git, I 
love you.

--
Steve
www.lucidworks.com

> On Mar 3, 2016, at 12:49 PM, Dawid Weiss  wrote:
> 
>> (with minor solr/CHANGES.txt fixups) and then diffing both directions:
>> 
>> git diff branch_6_0..branch_6x
>> git diff branch_6x..branch_6_0
> 
> Wait, can it ever be assymetric? I'd say it's impossible -- it should
> always be a "reverse" diff of the another?
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

> The mistake was to freeze the 6x branch in the first place. The release
branch is the one which should be frozen.

 I certainly agree with this. However, over a week ago there was a request
to hold off on creating the 6_0 branch until Jenkins settled with a 6x. I
received no push back on this suggestion so this was the plan that was
executed (several days after that request was sent).

> I specifically asked the RM to cut the branch to let others progress I
received no replies -- which is why I was forced to do it myself.

Your email was sent to me yesterday and I was on travel so didn't see it
until today (right when the branch was created in fact). Because of time
zones and other jobs I usually like to give people > 24 hours to reply.
That being said, if the collective needs to move forward I'm certainly not
insulted if someone else cuts a branch. I don't think any RM should be.

> The rest of the problem was because I am new to Git

I am not new to git so I had no problem creating the 6_0 branch, it just
seems I didn't get online soon enough.

I think Mike is suggesting, and I agree with this, there needs to be a
reasonable amount of time given for someone to respond.

- Nick


On Thu, Mar 3, 2016 at 10:30 AM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> Mike,
>
> I'll fix the TestBackwardsCompatibility. The mistake was to freeze the
> 6x branch in the first place. The release branch is the one which
> should be frozen. I specifically asked the RM to cut the branch to let
> others progress but I received no replies -- which is why I was forced
> to do it myself. In future, the RM should keep this in mind and not
> block others. The rest of the problem was because I am new to Git --
> in subversion a release branch is always copied from the server so
> pulling latest changes locally before creating the branch did not
> cross my mind.
>
> On Thu, Mar 3, 2016 at 9:46 PM, Michael McCandless
>  wrote:
> > Shalin,
> >
> > In the future please don't jump the gun like this?
> >
> > It has caused a lot of unnecessary chaos.  It should be the RM, and
> > only the RM, that is doing things like creating release branches,
> > bumping versions, etc., at release time.
> >
> > Also, your changes to bump the version on 6.x seem to be causing
> > TestBackwardsCompatibility to be failing.  Can you please fix that?
> > In the future, when you are RM, please run tests when bumping versions
> > before pushing.
> >
> > A major release is hard enough with only one chef.
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar
> >  wrote:
> >> Hmm I think I created the branch without pulling the latest code. I'll
> fix.
> >>
> >> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
> >>> This is missing a bunch of yesterday's branch_6x changes. Some of
> >>> david smiley's spatial work, at least one of my commits.
> >>>
> >>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
> >>>  wrote:
>  FYI, I have created the branch_6_0 so that we can continue to commit
>  stuff intended for 6.1 on master and branch_6x. I have also added the
>  6.1.0 version on branch_6x and master.
> 
>  On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey 
> wrote:
> > On 3/2/2016 4:19 AM, Alan Woodward wrote:
> >> Should we create a separate branch_6_0 branch for the
> feature-freeze?
> >>  I have stuff to push into master and that should eventually make it
> >> into 6.1, and it will be easy to forget to backport stuff if
> there's a
> >> week before I can do that…
> >
> > +1
> >
> > When I saw Nick's email about branch_6x being feature frozen, my
> first
> > thought was that we don't (and really can't) feature freeze the
> stable
> > branch -- isn't new feature development (for the next minor release
> in
> > the current major version) the entire purpose of branch_Nx?
> >
> > A feature freeze on a specific minor version does make sense.  I've
> seen
> > a couple of people say that we have, but there are also a few
> messages
> > from people saying that they want to include new functionality in
> 6.0.
> > I expect that backporting almost anything from branch_6x to
> branch_6_0
> > will be relatively easy, so it may be a good idea to just create the
> new
> > branch.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> 
> 
>  --
>  Regards,
>  Shalin Shekhar Mangar.
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  

Re: Lucene/Solr 6.0.0 Release Branch

[Dawid Weiss]

> (with minor solr/CHANGES.txt fixups) and then diffing both directions:
>
> git diff branch_6_0..branch_6x
> git diff branch_6x..branch_6_0

Wait, can it ever be assymetric? I'd say it's impossible -- it should
always be a "reverse" diff of the another?

Dawid

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

Re: Lucene/Solr 6.0.0 Release Branch

[Steve Rowe]

I compared the state of branch_6x and branch_6_0 after Mike merged LUCENE-7062 
by cherry-picking Shalin's 6.1-only commits into my local branch_6_0:

e4712bb028849f9a9b202651728c1f5c0a224374 (SOLR-8722)  
97db2d0b932ceae17fc6ab442af0b32f54928e05 (Adding version 6.1.0)
d346af3994fd2784c8550ccfea1f1d22afa0cd32 (SOLR-7516)

(with minor solr/CHANGES.txt fixups) and then diffing both directions:

git diff branch_6_0..branch_6x
git diff branch_6x..branch_6_0

and there were zero differences.

I think we’re good.

--
Steve
www.lucidworks.com

> On Mar 3, 2016, at 10:52 AM, Steve Rowe  wrote:
> 
> Shalin, I will take a look.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Mar 3, 2016, at 10:25 AM, Shalin Shekhar Mangar  
>> wrote:
>> 
>> I cherry-picked the following missing commits. I think I got all of
>> the missing ones but another set of eyes would be good.
>> 
>> Cherry-pick successful
>>  3cbc48e LUCENE-7059: always visit 1D points in sorted
>> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
>> maxMBSortInHeap to the OfflineSorter too
>>  e1033d9 SOLR-8145: Fix position of OOM killer script when
>> starting Solr in the background
>>  ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>>  25cc48b LUCENE-7059: remove MultiPointValues
>>  8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
>>  b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
>> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
>> commit 569b6ca)
>>  6dcb01c SOLR-8764: test schema-latest.xml spatial dist
>> units should be kilometers (no test uses yet?) (cherry picked from
>> commit deb6a49)
>> 
>> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
>>  wrote:
>>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>> 
>>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
 This is missing a bunch of yesterday's branch_6x changes. Some of
 david smiley's spatial work, at least one of my commits.
 
 On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
  wrote:
> FYI, I have created the branch_6_0 so that we can continue to commit
> stuff intended for 6.1 on master and branch_6x. I have also added the
> 6.1.0 version on branch_6x and master.
> 
> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>> I have stuff to push into master and that should eventually make it
>>> into 6.1, and it will be easy to forget to backport stuff if there's a
>>> week before I can do that…
>> 
>> +1
>> 
>> When I saw Nick's email about branch_6x being feature frozen, my first
>> thought was that we don't (and really can't) feature freeze the stable
>> branch -- isn't new feature development (for the next minor release in
>> the current major version) the entire purpose of branch_Nx?
>> 
>> A feature freeze on a specific minor version does make sense.  I've seen
>> a couple of people say that we have, but there are also a few messages
>> from people saying that they want to include new functionality in 6.0.
>> I expect that backporting almost anything from branch_6x to branch_6_0
>> will be relatively easy, so it may be a good idea to just create the new
>> branch.
>> 
>> Thanks,
>> Shawn
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> 
> --
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>> 
>> 
>> 
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

On Thu, Mar 3, 2016 at 10:58 AM, Robert Muir  wrote:

> I think mike has not merged his checkindex work but I am surprised to
> see merge conflicts?

OK I was able to merge my 6.x push to 6.0 with no conflicts, a good sign!

> Mike can you make sure your readint/readvint
> mismatch and other important bugfixes are not missing here?

I did a full source tree diff between 6.0 and master and reviewed all
the changes, and found a pre-existing minor bug (fixed), but otherwise
it looks like all master issues were successfully backported.

Thanks for fixing things, Shalin.

Mike McCandless

http://blog.mikemccandless.com

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

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

On Thu, Mar 3, 2016 at 11:30 AM, Shalin Shekhar Mangar
 wrote:

> I'll fix the TestBackwardsCompatibility.

Thanks.

> The mistake was to freeze the
> 6x branch in the first place. The release branch is the one which
> should be frozen. I specifically asked the RM to cut the branch to let
> others progress but I received no replies -- which is why I was forced
> to do it myself.

Again, even if you feel it was a mistake, even if the RM is taking a
bit to reply, please don't go and cut branches yourself.

If you feel strongly, start up a new thread, try to contact RM over
IRC, etc.  Please don't cut your own branches.

A major release is hard enough with one chef in the kitchen.

Mike McCandless

http://blog.mikemccandless.com

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

Re: Lucene/Solr 6.0.0 Release Branch

[Anshum Gupta]

> Feature freeze for a release should not block development.

+1.

On the other hand, I'm all for moving fast and getting things done but if
we think we shouldn't have cut the branch as things aren't stable, we
should not have had a feature freeze.


On Thu, Mar 3, 2016 at 7:48 AM, Steve Rowe <sar...@gmail.com> wrote:

> -1 to wait on creation of branch_6_0.  My preference is to not drop the
> branch, but to continue forward and fix problems as we discover them.
>
> Feature freeze for a release should not block development.
>
> If we drop the 6.0 branch, then changes already merged into branch_6x, but
> destined for 6.1, will have to be reverted.
>
> --
> Steve
> www.lucidworks.com
>
> > On Mar 3, 2016, at 10:35 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> >
> > Hi,
> >
> > could we just drop and re-create the branch? The Jenkins builds are not
> yet stable, so I am not happy to branch 6.0 NOW. See also Robert's mail.
> > First we should fix the Solr test failures! We have almost NO run on
> Jenkins that succeeds for 6.x (or master)! We cannot release that!!!
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> >> -Original Message-----
> >> From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com]
> >> Sent: Thursday, March 03, 2016 4:26 PM
> >> To: dev@lucene.apache.org
> >> Subject: Re: Lucene/Solr 6.0.0 Release Branch
> >>
> >> I cherry-picked the following missing commits. I think I got all of
> >> the missing ones but another set of eyes would be good.
> >>
> >> Cherry-pick successful
> >>   3cbc48e LUCENE-7059: always visit 1D points in sorted
> >> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
> >> maxMBSortInHeap to the OfflineSorter too
> >>   e1033d9 SOLR-8145: Fix position of OOM killer script when
> >> starting Solr in the background
> >>   ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
> >>   25cc48b LUCENE-7059: remove MultiPointValues
> >>   8eada27 LUCENE-7061: fix remaining api issues with XYZPoint
> classes
> >>   b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
> >> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
> >> commit 569b6ca)
> >>   6dcb01c SOLR-8764: test schema-latest.xml spatial dist
> >> units should be kilometers (no test uses yet?) (cherry picked from
> >> commit deb6a49)
> >>
> >> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
> >> <shalinman...@gmail.com> wrote:
> >>> Hmm I think I created the branch without pulling the latest code. I'll
> fix.
> >>>
> >>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote:
> >>>> This is missing a bunch of yesterday's branch_6x changes. Some of
> >>>> david smiley's spatial work, at least one of my commits.
> >>>>
> >>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
> >>>> <shalinman...@gmail.com> wrote:
> >>>>> FYI, I have created the branch_6_0 so that we can continue to commit
> >>>>> stuff intended for 6.1 on master and branch_6x. I have also added the
> >>>>> 6.1.0 version on branch_6x and master.
> >>>>>
> >>>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org>
> >> wrote:
> >>>>>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
> >>>>>>> Should we create a separate branch_6_0 branch for the feature-
> >> freeze?
> >>>>>>> I have stuff to push into master and that should eventually make it
> >>>>>>> into 6.1, and it will be easy to forget to backport stuff if
> there's a
> >>>>>>> week before I can do that…
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> When I saw Nick's email about branch_6x being feature frozen, my
> first
> >>>>>> thought was that we don't (and really can't) feature freeze the
> stable
> >>>>>> branch -- isn't new feature development (for the next minor release
> in
> >>>>>> the current major version) the entire purpose of branch_Nx?
> >>>>>>
> >>>>>> A feature freeze on a specific minor version does

Re: Lucene/Solr 6.0.0 Release Branch

[Dawid Weiss]

> The rest of the problem was because I am new to Git --
> in subversion a release branch is always copied from the server so
> pulling latest changes locally before creating the branch did not
> cross my mind.

FYI, just as a side note for those interested in version control systems.

Contrary to what you say branching in SVN is very much like it is git.
It just depends how you create a branch (or a "path" in SVN). What you
did in git would be this in SVN world:

svn checkout http://repo/trunk
# [delay]
svn cp . http://repo/branches/foo

The trunk could have been changed in between on the server, this
wouldn't be reflected on the branch. What you're used to is
remote-copying, probably:

svn cp  http://repo/trunk http://repo/branches/foo

but this is, to be honest, a very questionable command since you have
absolutely no control over which version you're copying (which version
of trunk you're branching). And if you do specify a version (there is
such a possibility) this in no way differs from pulling changes from
remote in git, marking your "branching" commit and then creating a
branch from there.

Dawid

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

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

Mike,

I'll fix the TestBackwardsCompatibility. The mistake was to freeze the
6x branch in the first place. The release branch is the one which
should be frozen. I specifically asked the RM to cut the branch to let
others progress but I received no replies -- which is why I was forced
to do it myself. In future, the RM should keep this in mind and not
block others. The rest of the problem was because I am new to Git --
in subversion a release branch is always copied from the server so
pulling latest changes locally before creating the branch did not
cross my mind.

On Thu, Mar 3, 2016 at 9:46 PM, Michael McCandless
 wrote:
> Shalin,
>
> In the future please don't jump the gun like this?
>
> It has caused a lot of unnecessary chaos.  It should be the RM, and
> only the RM, that is doing things like creating release branches,
> bumping versions, etc., at release time.
>
> Also, your changes to bump the version on 6.x seem to be causing
> TestBackwardsCompatibility to be failing.  Can you please fix that?
> In the future, when you are RM, please run tests when bumping versions
> before pushing.
>
> A major release is hard enough with only one chef.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar
>  wrote:
>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>
>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
>>> This is missing a bunch of yesterday's branch_6x changes. Some of
>>> david smiley's spatial work, at least one of my commits.
>>>
>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>>  wrote:
 FYI, I have created the branch_6_0 so that we can continue to commit
 stuff intended for 6.1 on master and branch_6x. I have also added the
 6.1.0 version on branch_6x and master.

 On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>  I have stuff to push into master and that should eventually make it
>> into 6.1, and it will be easy to forget to backport stuff if there's a
>> week before I can do that…
>
> +1
>
> When I saw Nick's email about branch_6x being feature frozen, my first
> thought was that we don't (and really can't) feature freeze the stable
> branch -- isn't new feature development (for the next minor release in
> the current major version) the entire purpose of branch_Nx?
>
> A feature freeze on a specific minor version does make sense.  I've seen
> a couple of people say that we have, but there are also a few messages
> from people saying that they want to include new functionality in 6.0.
> I expect that backporting almost anything from branch_6x to branch_6_0
> will be relatively easy, so it may be a good idea to just create the new
> branch.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



 --
 Regards,
 Shalin Shekhar Mangar.

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

>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

Shalin,

In the future please don't jump the gun like this?

It has caused a lot of unnecessary chaos.  It should be the RM, and
only the RM, that is doing things like creating release branches,
bumping versions, etc., at release time.

Also, your changes to bump the version on 6.x seem to be causing
TestBackwardsCompatibility to be failing.  Can you please fix that?
In the future, when you are RM, please run tests when bumping versions
before pushing.

A major release is hard enough with only one chef.

Mike McCandless

http://blog.mikemccandless.com


On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar
 wrote:
> Hmm I think I created the branch without pulling the latest code. I'll fix.
>
> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
>> This is missing a bunch of yesterday's branch_6x changes. Some of
>> david smiley's spatial work, at least one of my commits.
>>
>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>  wrote:
>>> FYI, I have created the branch_6_0 so that we can continue to commit
>>> stuff intended for 6.1 on master and branch_6x. I have also added the
>>> 6.1.0 version on branch_6x and master.
>>>
>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
 On 3/2/2016 4:19 AM, Alan Woodward wrote:
> Should we create a separate branch_6_0 branch for the feature-freeze?
>  I have stuff to push into master and that should eventually make it
> into 6.1, and it will be easy to forget to backport stuff if there's a
> week before I can do that…

 +1

 When I saw Nick's email about branch_6x being feature frozen, my first
 thought was that we don't (and really can't) feature freeze the stable
 branch -- isn't new feature development (for the next minor release in
 the current major version) the entire purpose of branch_Nx?

 A feature freeze on a specific minor version does make sense.  I've seen
 a couple of people say that we have, but there are also a few messages
 from people saying that they want to include new functionality in 6.0.
 I expect that backporting almost anything from branch_6x to branch_6_0
 will be relatively easy, so it may be a good idea to just create the new
 branch.

 Thanks,
 Shawn


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

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

On Thu, Mar 3, 2016 at 10:48 AM, Steve Rowe  wrote:

> Feature freeze for a release should not block development.

+1

Mike McCandless

http://blog.mikemccandless.com

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

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

> Mike can you make sure your readint/readvint mismatch and other important 
> bugfixes are not missing here?

Thanks Rob, I'll confirm this fix made it to 6.0.

And, yes, I haven't merged LUCENE-7062 to 6.0 yet: it hit merge
conflicts when I last tried, I thought (at the time) because Shalin's
branch was missing a bunch of commits, but I'll try again.

Mike McCandless

http://blog.mikemccandless.com

On Thu, Mar 3, 2016 at 10:58 AM, Robert Muir  wrote:
> I took a look (by doing merge --squash from branch_6x to review
> changes), and it mostly looks good, but i was surprised to see these
> conflicts:
>
> both modified:
> lucene/core/src/java/org/apache/lucene/index/CheckIndex.java
> both modified:
> lucene/core/src/test/org/apache/lucene/index/TestPointValues.java
> both modified:
> lucene/test-framework/src/java/org/apache/lucene/codecs/asserting/AssertingPointFormat.java
>
> I think mike has not merged his checkindex work but I am surprised to
> see merge conflicts? Mike can you make sure your readint/readvint
> mismatch and other important bugfixes are not missing here?
>
> On Thu, Mar 3, 2016 at 10:25 AM, Shalin Shekhar Mangar
>  wrote:
>> I cherry-picked the following missing commits. I think I got all of
>> the missing ones but another set of eyes would be good.
>>
>> Cherry-pick successful
>>3cbc48e LUCENE-7059: always visit 1D points in sorted
>> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
>> maxMBSortInHeap to the OfflineSorter too
>>e1033d9 SOLR-8145: Fix position of OOM killer script when
>> starting Solr in the background
>>ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>>25cc48b LUCENE-7059: remove MultiPointValues
>>8eada27 LUCENE-7061: fix remaining api issues with XYZPoint 
>> classes
>>b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
>> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
>> commit 569b6ca)
>>6dcb01c SOLR-8764: test schema-latest.xml spatial dist
>> units should be kilometers (no test uses yet?) (cherry picked from
>> commit deb6a49)
>>
>> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
>>  wrote:
>>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>>
>>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
 This is missing a bunch of yesterday's branch_6x changes. Some of
 david smiley's spatial work, at least one of my commits.

 On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
  wrote:
> FYI, I have created the branch_6_0 so that we can continue to commit
> stuff intended for 6.1 on master and branch_6x. I have also added the
> 6.1.0 version on branch_6x and master.
>
> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>>  I have stuff to push into master and that should eventually make it
>>> into 6.1, and it will be easy to forget to backport stuff if there's a
>>> week before I can do that…
>>
>> +1
>>
>> When I saw Nick's email about branch_6x being feature frozen, my first
>> thought was that we don't (and really can't) feature freeze the stable
>> branch -- isn't new feature development (for the next minor release in
>> the current major version) the entire purpose of branch_Nx?
>>
>> A feature freeze on a specific minor version does make sense.  I've seen
>> a couple of people say that we have, but there are also a few messages
>> from people saying that they want to include new functionality in 6.0.
>> I expect that backporting almost anything from branch_6x to branch_6_0
>> will be relatively easy, so it may be a good idea to just create the new
>> branch.
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: 

Re: Lucene/Solr 6.0.0 Release Branch

[Robert Muir]

I took a look (by doing merge --squash from branch_6x to review
changes), and it mostly looks good, but i was surprised to see these
conflicts:

both modified:
lucene/core/src/java/org/apache/lucene/index/CheckIndex.java
both modified:
lucene/core/src/test/org/apache/lucene/index/TestPointValues.java
both modified:
lucene/test-framework/src/java/org/apache/lucene/codecs/asserting/AssertingPointFormat.java

I think mike has not merged his checkindex work but I am surprised to
see merge conflicts? Mike can you make sure your readint/readvint
mismatch and other important bugfixes are not missing here?

On Thu, Mar 3, 2016 at 10:25 AM, Shalin Shekhar Mangar
 wrote:
> I cherry-picked the following missing commits. I think I got all of
> the missing ones but another set of eyes would be good.
>
> Cherry-pick successful
>3cbc48e LUCENE-7059: always visit 1D points in sorted
> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
> maxMBSortInHeap to the OfflineSorter too
>e1033d9 SOLR-8145: Fix position of OOM killer script when
> starting Solr in the background
>ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>25cc48b LUCENE-7059: remove MultiPointValues
>8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
>b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
> commit 569b6ca)
>6dcb01c SOLR-8764: test schema-latest.xml spatial dist
> units should be kilometers (no test uses yet?) (cherry picked from
> commit deb6a49)
>
> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
>  wrote:
>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>
>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
>>> This is missing a bunch of yesterday's branch_6x changes. Some of
>>> david smiley's spatial work, at least one of my commits.
>>>
>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>>  wrote:
 FYI, I have created the branch_6_0 so that we can continue to commit
 stuff intended for 6.1 on master and branch_6x. I have also added the
 6.1.0 version on branch_6x and master.

 On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>  I have stuff to push into master and that should eventually make it
>> into 6.1, and it will be easy to forget to backport stuff if there's a
>> week before I can do that…
>
> +1
>
> When I saw Nick's email about branch_6x being feature frozen, my first
> thought was that we don't (and really can't) feature freeze the stable
> branch -- isn't new feature development (for the next minor release in
> the current major version) the entire purpose of branch_Nx?
>
> A feature freeze on a specific minor version does make sense.  I've seen
> a couple of people say that we have, but there are also a few messages
> from people saying that they want to include new functionality in 6.0.
> I expect that backporting almost anything from branch_6x to branch_6_0
> will be relatively easy, so it may be a good idea to just create the new
> branch.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



 --
 Regards,
 Shalin Shekhar Mangar.

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

>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 Release Branch

[Steve Rowe]

Shalin, I will take a look.

--
Steve
www.lucidworks.com

> On Mar 3, 2016, at 10:25 AM, Shalin Shekhar Mangar  
> wrote:
> 
> I cherry-picked the following missing commits. I think I got all of
> the missing ones but another set of eyes would be good.
> 
> Cherry-pick successful
>   3cbc48e LUCENE-7059: always visit 1D points in sorted
> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
> maxMBSortInHeap to the OfflineSorter too
>   e1033d9 SOLR-8145: Fix position of OOM killer script when
> starting Solr in the background
>   ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>   25cc48b LUCENE-7059: remove MultiPointValues
>   8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
>   b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
> commit 569b6ca)
>   6dcb01c SOLR-8764: test schema-latest.xml spatial dist
> units should be kilometers (no test uses yet?) (cherry picked from
> commit deb6a49)
> 
> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
>  wrote:
>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>> 
>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
>>> This is missing a bunch of yesterday's branch_6x changes. Some of
>>> david smiley's spatial work, at least one of my commits.
>>> 
>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>>  wrote:
 FYI, I have created the branch_6_0 so that we can continue to commit
 stuff intended for 6.1 on master and branch_6x. I have also added the
 6.1.0 version on branch_6x and master.
 
 On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>> Should we create a separate branch_6_0 branch for the feature-freeze?
>> I have stuff to push into master and that should eventually make it
>> into 6.1, and it will be easy to forget to backport stuff if there's a
>> week before I can do that…
> 
> +1
> 
> When I saw Nick's email about branch_6x being feature frozen, my first
> thought was that we don't (and really can't) feature freeze the stable
> branch -- isn't new feature development (for the next minor release in
> the current major version) the entire purpose of branch_Nx?
> 
> A feature freeze on a specific minor version does make sense.  I've seen
> a couple of people say that we have, but there are also a few messages
> from people saying that they want to include new functionality in 6.0.
> I expect that backporting almost anything from branch_6x to branch_6_0
> will be relatively easy, so it may be a good idea to just create the new
> branch.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
 
 
 
 --
 Regards,
 Shalin Shekhar Mangar.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> 
>> 
>> --
>> Regards,
>> Shalin Shekhar Mangar.
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

Re: Lucene/Solr 6.0.0 Release Branch

[Steve Rowe]

-1 to wait on creation of branch_6_0.  My preference is to not drop the branch, 
but to continue forward and fix problems as we discover them.

Feature freeze for a release should not block development.

If we drop the 6.0 branch, then changes already merged into branch_6x, but 
destined for 6.1, will have to be reverted.

--
Steve
www.lucidworks.com

> On Mar 3, 2016, at 10:35 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> 
> Hi,
> 
> could we just drop and re-create the branch? The Jenkins builds are not yet 
> stable, so I am not happy to branch 6.0 NOW. See also Robert's mail.
> First we should fix the Solr test failures! We have almost NO run on Jenkins 
> that succeeds for 6.x (or master)! We cannot release that!!!
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
>> -Original Message-
>> From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com]
>> Sent: Thursday, March 03, 2016 4:26 PM
>> To: dev@lucene.apache.org
>> Subject: Re: Lucene/Solr 6.0.0 Release Branch
>> 
>> I cherry-picked the following missing commits. I think I got all of
>> the missing ones but another set of eyes would be good.
>> 
>> Cherry-pick successful
>>   3cbc48e LUCENE-7059: always visit 1D points in sorted
>> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
>> maxMBSortInHeap to the OfflineSorter too
>>   e1033d9 SOLR-8145: Fix position of OOM killer script when
>> starting Solr in the background
>>   ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>>   25cc48b LUCENE-7059: remove MultiPointValues
>>   8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
>>   b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
>> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
>> commit 569b6ca)
>>   6dcb01c SOLR-8764: test schema-latest.xml spatial dist
>> units should be kilometers (no test uses yet?) (cherry picked from
>> commit deb6a49)
>> 
>> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
>> <shalinman...@gmail.com> wrote:
>>> Hmm I think I created the branch without pulling the latest code. I'll fix.
>>> 
>>> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote:
>>>> This is missing a bunch of yesterday's branch_6x changes. Some of
>>>> david smiley's spatial work, at least one of my commits.
>>>> 
>>>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>>> <shalinman...@gmail.com> wrote:
>>>>> FYI, I have created the branch_6_0 so that we can continue to commit
>>>>> stuff intended for 6.1 on master and branch_6x. I have also added the
>>>>> 6.1.0 version on branch_6x and master.
>>>>> 
>>>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org>
>> wrote:
>>>>>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>>>>>>> Should we create a separate branch_6_0 branch for the feature-
>> freeze?
>>>>>>> I have stuff to push into master and that should eventually make it
>>>>>>> into 6.1, and it will be easy to forget to backport stuff if there's a
>>>>>>> week before I can do that…
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> When I saw Nick's email about branch_6x being feature frozen, my first
>>>>>> thought was that we don't (and really can't) feature freeze the stable
>>>>>> branch -- isn't new feature development (for the next minor release in
>>>>>> the current major version) the entire purpose of branch_Nx?
>>>>>> 
>>>>>> A feature freeze on a specific minor version does make sense.  I've
>> seen
>>>>>> a couple of people say that we have, but there are also a few messages
>>>>>> from people saying that they want to include new functionality in 6.0.
>>>>>> I expect that backporting almost anything from branch_6x to
>> branch_6_0
>>>>>> will be relatively easy, so it may be a good idea to just create the new
>>>>>> branch.
>>>>>> 
>>>>>> Thanks,
>>>>>> Shawn
>>>>>> 
>>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucen

RE: Lucene/Solr 6.0.0 Release Branch

[Uwe Schindler]

Hi,

could we just drop and re-create the branch? The Jenkins builds are not yet 
stable, so I am not happy to branch 6.0 NOW. See also Robert's mail.
First we should fix the Solr test failures! We have almost NO run on Jenkins 
that succeeds for 6.x (or master)! We cannot release that!!!

Uwe

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


> -Original Message-
> From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com]
> Sent: Thursday, March 03, 2016 4:26 PM
> To: dev@lucene.apache.org
> Subject: Re: Lucene/Solr 6.0.0 Release Branch
> 
> I cherry-picked the following missing commits. I think I got all of
> the missing ones but another set of eyes would be good.
> 
> Cherry-pick successful
>3cbc48e LUCENE-7059: always visit 1D points in sorted
> order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
> maxMBSortInHeap to the OfflineSorter too
>e1033d9 SOLR-8145: Fix position of OOM killer script when
> starting Solr in the background
>ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
>25cc48b LUCENE-7059: remove MultiPointValues
>8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
>b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
> com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
> commit 569b6ca)
>6dcb01c SOLR-8764: test schema-latest.xml spatial dist
> units should be kilometers (no test uses yet?) (cherry picked from
> commit deb6a49)
> 
> On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
> <shalinman...@gmail.com> wrote:
> > Hmm I think I created the branch without pulling the latest code. I'll fix.
> >
> > On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote:
> >> This is missing a bunch of yesterday's branch_6x changes. Some of
> >> david smiley's spatial work, at least one of my commits.
> >>
> >> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
> >> <shalinman...@gmail.com> wrote:
> >>> FYI, I have created the branch_6_0 so that we can continue to commit
> >>> stuff intended for 6.1 on master and branch_6x. I have also added the
> >>> 6.1.0 version on branch_6x and master.
> >>>
> >>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org>
> wrote:
> >>>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
> >>>>> Should we create a separate branch_6_0 branch for the feature-
> freeze?
> >>>>>  I have stuff to push into master and that should eventually make it
> >>>>> into 6.1, and it will be easy to forget to backport stuff if there's a
> >>>>> week before I can do that…
> >>>>
> >>>> +1
> >>>>
> >>>> When I saw Nick's email about branch_6x being feature frozen, my first
> >>>> thought was that we don't (and really can't) feature freeze the stable
> >>>> branch -- isn't new feature development (for the next minor release in
> >>>> the current major version) the entire purpose of branch_Nx?
> >>>>
> >>>> A feature freeze on a specific minor version does make sense.  I've
> seen
> >>>> a couple of people say that we have, but there are also a few messages
> >>>> from people saying that they want to include new functionality in 6.0.
> >>>> I expect that backporting almost anything from branch_6x to
> branch_6_0
> >>>> will be relatively easy, so it may be a good idea to just create the new
> >>>> branch.
> >>>>
> >>>> Thanks,
> >>>> Shawn
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Shalin Shekhar Mangar.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
> 
> 
> 
> --
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

I cherry-picked the following missing commits. I think I got all of
the missing ones but another set of eyes would be good.

Cherry-pick successful
   3cbc48e LUCENE-7059: always visit 1D points in sorted
order; fix tie-break but in BKDWriter; fix BKDWriter to pass on
maxMBSortInHeap to the OfflineSorter too
   e1033d9 SOLR-8145: Fix position of OOM killer script when
starting Solr in the background
   ddd019f SOLR-8145: mention fix in solr/CHANGES.txt
   25cc48b LUCENE-7059: remove MultiPointValues
   8eada27 LUCENE-7061: fix remaining api issues with XYZPoint classes
   b90dbd4 LUCENE-7060: Spatial4j 0.6 upgrade. Package
com.spatial4j.core -> org.locationtech.spatial4j (cherry picked from
commit 569b6ca)
   6dcb01c SOLR-8764: test schema-latest.xml spatial dist
units should be kilometers (no test uses yet?) (cherry picked from
commit deb6a49)

On Thu, Mar 3, 2016 at 7:22 PM, Shalin Shekhar Mangar
 wrote:
> Hmm I think I created the branch without pulling the latest code. I'll fix.
>
> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
>> This is missing a bunch of yesterday's branch_6x changes. Some of
>> david smiley's spatial work, at least one of my commits.
>>
>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>>  wrote:
>>> FYI, I have created the branch_6_0 so that we can continue to commit
>>> stuff intended for 6.1 on master and branch_6x. I have also added the
>>> 6.1.0 version on branch_6x and master.
>>>
>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
 On 3/2/2016 4:19 AM, Alan Woodward wrote:
> Should we create a separate branch_6_0 branch for the feature-freeze?
>  I have stuff to push into master and that should eventually make it
> into 6.1, and it will be easy to forget to backport stuff if there's a
> week before I can do that…

 +1

 When I saw Nick's email about branch_6x being feature frozen, my first
 thought was that we don't (and really can't) feature freeze the stable
 branch -- isn't new feature development (for the next minor release in
 the current major version) the entire purpose of branch_Nx?

 A feature freeze on a specific minor version does make sense.  I've seen
 a couple of people say that we have, but there are also a few messages
 from people saying that they want to include new functionality in 6.0.
 I expect that backporting almost anything from branch_6x to branch_6_0
 will be relatively easy, so it may be a good idea to just create the new
 branch.

 Thanks,
 Shawn


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

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.



-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

Since this is the first major release since cutting over to git the intent
was to first create the 6x branch and create 6_0 once Jenkins was stable
with the new branches (version changes, backcompat, etc). This meant
a slight gap between creating the 6x and 6_0 branch, and a temporary
feature freeze until everything checks out.

That being said, if everyone is comfortable with the current state of
Jenkins (I know Mike did a lot of work to ensure backcompat tests pass) I
have no problem with the creation of the 6_0 branch. We just needed to give
enough time for things to settle and people to respond.

- Nick

On Thursday, March 3, 2016, Shalin Shekhar Mangar 
wrote:

> Hmm I think I created the branch without pulling the latest code. I'll fix.
>
> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  > wrote:
> > This is missing a bunch of yesterday's branch_6x changes. Some of
> > david smiley's spatial work, at least one of my commits.
> >
> > On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
> > > wrote:
> >> FYI, I have created the branch_6_0 so that we can continue to commit
> >> stuff intended for 6.1 on master and branch_6x. I have also added the
> >> 6.1.0 version on branch_6x and master.
> >>
> >> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  > wrote:
> >>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>  Should we create a separate branch_6_0 branch for the feature-freeze?
>   I have stuff to push into master and that should eventually make it
>  into 6.1, and it will be easy to forget to backport stuff if there's a
>  week before I can do that…
> >>>
> >>> +1
> >>>
> >>> When I saw Nick's email about branch_6x being feature frozen, my first
> >>> thought was that we don't (and really can't) feature freeze the stable
> >>> branch -- isn't new feature development (for the next minor release in
> >>> the current major version) the entire purpose of branch_Nx?
> >>>
> >>> A feature freeze on a specific minor version does make sense.  I've
> seen
> >>> a couple of people say that we have, but there are also a few messages
> >>> from people saying that they want to include new functionality in 6.0.
> >>> I expect that backporting almost anything from branch_6x to branch_6_0
> >>> will be relatively easy, so it may be a good idea to just create the
> new
> >>> branch.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
>
>

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

Hmm I think I created the branch without pulling the latest code. I'll fix.

On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir  wrote:
> This is missing a bunch of yesterday's branch_6x changes. Some of
> david smiley's spatial work, at least one of my commits.
>
> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
>  wrote:
>> FYI, I have created the branch_6_0 so that we can continue to commit
>> stuff intended for 6.1 on master and branch_6x. I have also added the
>> 6.1.0 version on branch_6x and master.
>>
>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
>>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
 Should we create a separate branch_6_0 branch for the feature-freeze?
  I have stuff to push into master and that should eventually make it
 into 6.1, and it will be easy to forget to backport stuff if there's a
 week before I can do that…
>>>
>>> +1
>>>
>>> When I saw Nick's email about branch_6x being feature frozen, my first
>>> thought was that we don't (and really can't) feature freeze the stable
>>> branch -- isn't new feature development (for the next minor release in
>>> the current major version) the entire purpose of branch_Nx?
>>>
>>> A feature freeze on a specific minor version does make sense.  I've seen
>>> a couple of people say that we have, but there are also a few messages
>>> from people saying that they want to include new functionality in 6.0.
>>> I expect that backporting almost anything from branch_6x to branch_6_0
>>> will be relatively easy, so it may be a good idea to just create the new
>>> branch.
>>>
>>> Thanks,
>>> Shawn
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Lucene/Solr 6.0.0 Release Branch

[Robert Muir]

This is missing a bunch of yesterday's branch_6x changes. Some of
david smiley's spatial work, at least one of my commits.

On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar
 wrote:
> FYI, I have created the branch_6_0 so that we can continue to commit
> stuff intended for 6.1 on master and branch_6x. I have also added the
> 6.1.0 version on branch_6x and master.
>
> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
>> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>>  I have stuff to push into master and that should eventually make it
>>> into 6.1, and it will be easy to forget to backport stuff if there's a
>>> week before I can do that…
>>
>> +1
>>
>> When I saw Nick's email about branch_6x being feature frozen, my first
>> thought was that we don't (and really can't) feature freeze the stable
>> branch -- isn't new feature development (for the next minor release in
>> the current major version) the entire purpose of branch_Nx?
>>
>> A feature freeze on a specific minor version does make sense.  I've seen
>> a couple of people say that we have, but there are also a few messages
>> from people saying that they want to include new functionality in 6.0.
>> I expect that backporting almost anything from branch_6x to branch_6_0
>> will be relatively easy, so it may be a good idea to just create the new
>> branch.
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

FYI, I have created the branch_6_0 so that we can continue to commit
stuff intended for 6.1 on master and branch_6x. I have also added the
6.1.0 version on branch_6x and master.

On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey  wrote:
> On 3/2/2016 4:19 AM, Alan Woodward wrote:
>> Should we create a separate branch_6_0 branch for the feature-freeze?
>>  I have stuff to push into master and that should eventually make it
>> into 6.1, and it will be easy to forget to backport stuff if there's a
>> week before I can do that…
>
> +1
>
> When I saw Nick's email about branch_6x being feature frozen, my first
> thought was that we don't (and really can't) feature freeze the stable
> branch -- isn't new feature development (for the next minor release in
> the current major version) the entire purpose of branch_Nx?
>
> A feature freeze on a specific minor version does make sense.  I've seen
> a couple of people say that we have, but there are also a few messages
> from people saying that they want to include new functionality in 6.0.
> I expect that backporting almost anything from branch_6x to branch_6_0
> will be relatively easy, so it may be a good idea to just create the new
> branch.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Lucene/Solr 6.0.0 Release Branch

[Shawn Heisey]

On 3/2/2016 4:19 AM, Alan Woodward wrote:
> Should we create a separate branch_6_0 branch for the feature-freeze?
>  I have stuff to push into master and that should eventually make it
> into 6.1, and it will be easy to forget to backport stuff if there's a
> week before I can do that…

+1

When I saw Nick's email about branch_6x being feature frozen, my first
thought was that we don't (and really can't) feature freeze the stable
branch -- isn't new feature development (for the next minor release in
the current major version) the entire purpose of branch_Nx?

A feature freeze on a specific minor version does make sense.  I've seen
a couple of people say that we have, but there are also a few messages
from people saying that they want to include new functionality in 6.0. 
I expect that backporting almost anything from branch_6x to branch_6_0
will be relatively easy, so it may be a good idea to just create the new
branch.

Thanks,
Shawn


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

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

Gus, we are now in feature freeze for 6.0 but we should have a 6.1
soon-ish. Lucene/Solr averages a minor release every 6 weeks or so.

On Wed, Mar 2, 2016 at 9:34 PM, Gus Heck  wrote:
> Hi, just noticed this thread. I've been pushing hard to get
> https://issues.apache.org/jira/browse/SOLR-8349, which was partly funded by
> a customer into 6.0 ... I submitted it many months ago, but only got review
> a few weeks ago.
>
> On Wed, Mar 2, 2016 at 10:48 AM, Shalin Shekhar Mangar
>  wrote:
>>
>> +1 to a separate branch_6_0 for the freeze. I'm going to create a 6.1
>> section in CHANGES.txt.
>>
>> On Wed, Mar 2, 2016 at 4:49 PM, Alan Woodward  wrote:
>> > Should we create a separate branch_6_0 branch for the feature-freeze?  I
>> > have stuff to push into master and that should eventually make it into
>> > 6.1,
>> > and it will be easy to forget to backport stuff if there's a week before
>> > I
>> > can do that…
>> >
>> > Alan Woodward
>> > www.flax.co.uk
>> >
>> >
>> > On 2 Mar 2016, at 09:39, Nicholas Knize wrote:
>> >
>> > Yes! The 6x branch is in feature freeze but bug fixes are still OK.
>> > We'll
>> > let jenkins settle over the next week or so before beginning the actual
>> > release process.
>> >
>> > On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
>> >  wrote:
>> >>
>> >> Thanks Nick!
>> >>
>> >> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
>> >> Point values issues...
>> >>
>> >> Mike McCandless
>> >>
>> >> http://blog.mikemccandless.com
>> >>
>> >>
>> >> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize 
>> >> wrote:
>> >> > I created branch_6x and updated the version in master to 7.0.0 but it
>> >> > looks
>> >> > like I do not have jenkins karma to configure builds for the new 6x
>> >> > branch.
>> >> > Can someone have a look at configuring the builds?
>> >> >
>> >> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> Thanks for the info David!
>> >> >>
>> >> >> I'll likely update version labels and create the 6X branch late
>> >> >> tomorrow
>> >> >> or early the next day. Let me know if anyone has an issue with this
>> >> >> timing.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> - Nick
>> >> >>
>> >> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
>> >> >>  wrote:
>> >> >>>
>> >> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a
>> >> >>> little
>> >> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
>> >> >>> move
>> >> >>> things around / rename.  But I don't mind doing an extra cherry
>> >> >>> pick
>> >> >>> in the
>> >> >>> end if you want to go create the branch without waiting.  So I
>> >> >>> don't
>> >> >>> know if
>> >> >>> you want to call that a blocker or not.
>> >> >>>
>> >> >>> Also, FYI there's a feature LUCENE-5735
>> >> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to
>> >> >>> master
>> >> >>> (but
>> >> >>> not 5x) over a year ago but didn't quite close the issue.  I had
>> >> >>> found
>> >> >>> a bug
>> >> >>> or two but then lost the time to finish it.   I'd rather remove
>> >> >>> this
>> >> >>> feature
>> >> >>> from the 6x branch after you create the branch.  When I get more
>> >> >>> time
>> >> >>> (very
>> >> >>> likely this year) I can resolve the lingering bugs and get it into
>> >> >>> whatever
>> >> >>> 6.x release comes along then.  So nothing for you to do here but
>> >> >>> wanted to
>> >> >>> let you know.
>> >> >>>
>> >> >>> Hey thanks for pitching in to do the release.
>> >> >>>
>> >> >>> ~ David
>> >> >>>
>> >> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
>> >> >>> wrote:
>> >> 
>> >>  Thanks Uwe!  Indeed we need branch_6x (and master versions
>> >>  changed)
>> >>  first. I'll plan to get that done Monday and/or Tuesday. Let me
>> >>  know
>> >>  if
>> >>  there are any blockers and I'll send a note to the list before I
>> >>  create the
>> >>  branch.
>> >> 
>> >>  - Nick
>> >> 
>> >> 
>> >>  On Wednesday, February 24, 2016, Uwe Schindler 
>> >>  wrote:
>> >> >
>> >> > Hi Nicholas,
>> >> >
>> >> >
>> >> >
>> >> > before we start a branch_6_0 we should do the following:
>> >> >
>> >> >
>> >> >
>> >> > -  Start branch_6x as “new stable branch”
>> >> >
>> >> > -  Update version numbers in “master” to 7.0
>> >> >
>> >> >
>> >> >
>> >> > This should be done maybe early next week and then after a while
>> >> > that
>> >> > things settle (also the Jenkins Jobs for branch_6x are set up),
>> >> > we
>> >> > can
>> >> > proceed with a gap:
>> >> >
>> >> > -  Cut branch_6_0
>> >> >
>> >> > -  Update version numbers in “branch_6x” to 6.1
>> >> >
>> >> >

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

Hmm if I add a 6.1 section now, before the branch_6_0 is created, Nick
will have to manually remove the 6.1 section.

Nick, I have some stuff to commit for 6.1 but I can hold on for a bit
if you are going to create the branch_6_0 soon.

On Wed, Mar 2, 2016 at 9:18 PM, Shalin Shekhar Mangar
 wrote:
> +1 to a separate branch_6_0 for the freeze. I'm going to create a 6.1
> section in CHANGES.txt.
>
> On Wed, Mar 2, 2016 at 4:49 PM, Alan Woodward  wrote:
>> Should we create a separate branch_6_0 branch for the feature-freeze?  I
>> have stuff to push into master and that should eventually make it into 6.1,
>> and it will be easy to forget to backport stuff if there's a week before I
>> can do that…
>>
>> Alan Woodward
>> www.flax.co.uk
>>
>>
>> On 2 Mar 2016, at 09:39, Nicholas Knize wrote:
>>
>> Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
>> let jenkins settle over the next week or so before beginning the actual
>> release process.
>>
>> On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
>>  wrote:
>>>
>>> Thanks Nick!
>>>
>>> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
>>> Point values issues...
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
>>> > I created branch_6x and updated the version in master to 7.0.0 but it
>>> > looks
>>> > like I do not have jenkins karma to configure builds for the new 6x
>>> > branch.
>>> > Can someone have a look at configuring the builds?
>>> >
>>> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
>>> > wrote:
>>> >>
>>> >>
>>> >> Thanks for the info David!
>>> >>
>>> >> I'll likely update version labels and create the 6X branch late
>>> >> tomorrow
>>> >> or early the next day. Let me know if anyone has an issue with this
>>> >> timing.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> - Nick
>>> >>
>>> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
>>> >>  wrote:
>>> >>>
>>> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
>>> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
>>> >>> move
>>> >>> things around / rename.  But I don't mind doing an extra cherry pick
>>> >>> in the
>>> >>> end if you want to go create the branch without waiting.  So I don't
>>> >>> know if
>>> >>> you want to call that a blocker or not.
>>> >>>
>>> >>> Also, FYI there's a feature LUCENE-5735
>>> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master
>>> >>> (but
>>> >>> not 5x) over a year ago but didn't quite close the issue.  I had found
>>> >>> a bug
>>> >>> or two but then lost the time to finish it.   I'd rather remove this
>>> >>> feature
>>> >>> from the 6x branch after you create the branch.  When I get more time
>>> >>> (very
>>> >>> likely this year) I can resolve the lingering bugs and get it into
>>> >>> whatever
>>> >>> 6.x release comes along then.  So nothing for you to do here but
>>> >>> wanted to
>>> >>> let you know.
>>> >>>
>>> >>> Hey thanks for pitching in to do the release.
>>> >>>
>>> >>> ~ David
>>> >>>
>>> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
>>> >>> wrote:
>>> 
>>>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
>>>  first. I'll plan to get that done Monday and/or Tuesday. Let me know
>>>  if
>>>  there are any blockers and I'll send a note to the list before I
>>>  create the
>>>  branch.
>>> 
>>>  - Nick
>>> 
>>> 
>>>  On Wednesday, February 24, 2016, Uwe Schindler 
>>>  wrote:
>>> >
>>> > Hi Nicholas,
>>> >
>>> >
>>> >
>>> > before we start a branch_6_0 we should do the following:
>>> >
>>> >
>>> >
>>> > -  Start branch_6x as “new stable branch”
>>> >
>>> > -  Update version numbers in “master” to 7.0
>>> >
>>> >
>>> >
>>> > This should be done maybe early next week and then after a while
>>> > that
>>> > things settle (also the Jenkins Jobs for branch_6x are set up), we
>>> > can
>>> > proceed with a gap:
>>> >
>>> > -  Cut branch_6_0
>>> >
>>> > -  Update version numbers in “branch_6x” to 6.1
>>> >
>>> >
>>> >
>>> > Uwe
>>> >
>>> >
>>> >
>>> > -
>>> >
>>> > Uwe Schindler
>>> >
>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>> >
>>> > http://www.thetaphi.de
>>> >
>>> > eMail: u...@thetaphi.de
>>> >
>>> >
>>> >
>>> > From: Nicholas Knize [mailto:nkn...@gmail.com]
>>> > Sent: Wednesday, February 24, 2016 9:23 PM
>>> > To: Lucene/Solr dev 
>>> > Subject: Lucene/Solr 6.0.0 Release Branch
>>> >
>>> >
>>> >
>>> > With the release of 5.5 and the previous discussion re: 

Re: Lucene/Solr 6.0.0 Release Branch

[Gus Heck]

Hi, just noticed this thread. I've been pushing hard to get
https://issues.apache.org/jira/browse/SOLR-8349, which was partly funded by
a customer into 6.0 ... I submitted it many months ago, but only got review
a few weeks ago.

On Wed, Mar 2, 2016 at 10:48 AM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> +1 to a separate branch_6_0 for the freeze. I'm going to create a 6.1
> section in CHANGES.txt.
>
> On Wed, Mar 2, 2016 at 4:49 PM, Alan Woodward  wrote:
> > Should we create a separate branch_6_0 branch for the feature-freeze?  I
> > have stuff to push into master and that should eventually make it into
> 6.1,
> > and it will be easy to forget to backport stuff if there's a week before
> I
> > can do that…
> >
> > Alan Woodward
> > www.flax.co.uk
> >
> >
> > On 2 Mar 2016, at 09:39, Nicholas Knize wrote:
> >
> > Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
> > let jenkins settle over the next week or so before beginning the actual
> > release process.
> >
> > On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
> >  wrote:
> >>
> >> Thanks Nick!
> >>
> >> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
> >> Point values issues...
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize 
> wrote:
> >> > I created branch_6x and updated the version in master to 7.0.0 but it
> >> > looks
> >> > like I do not have jenkins karma to configure builds for the new 6x
> >> > branch.
> >> > Can someone have a look at configuring the builds?
> >> >
> >> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
> >> > wrote:
> >> >>
> >> >>
> >> >> Thanks for the info David!
> >> >>
> >> >> I'll likely update version labels and create the 6X branch late
> >> >> tomorrow
> >> >> or early the next day. Let me know if anyone has an issue with this
> >> >> timing.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> - Nick
> >> >>
> >> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
> >> >>  wrote:
> >> >>>
> >> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a
> little
> >> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
> >> >>> move
> >> >>> things around / rename.  But I don't mind doing an extra cherry pick
> >> >>> in the
> >> >>> end if you want to go create the branch without waiting.  So I don't
> >> >>> know if
> >> >>> you want to call that a blocker or not.
> >> >>>
> >> >>> Also, FYI there's a feature LUCENE-5735
> >> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to
> master
> >> >>> (but
> >> >>> not 5x) over a year ago but didn't quite close the issue.  I had
> found
> >> >>> a bug
> >> >>> or two but then lost the time to finish it.   I'd rather remove this
> >> >>> feature
> >> >>> from the 6x branch after you create the branch.  When I get more
> time
> >> >>> (very
> >> >>> likely this year) I can resolve the lingering bugs and get it into
> >> >>> whatever
> >> >>> 6.x release comes along then.  So nothing for you to do here but
> >> >>> wanted to
> >> >>> let you know.
> >> >>>
> >> >>> Hey thanks for pitching in to do the release.
> >> >>>
> >> >>> ~ David
> >> >>>
> >> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
> >> >>> wrote:
> >> 
> >>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
> >>  first. I'll plan to get that done Monday and/or Tuesday. Let me
> know
> >>  if
> >>  there are any blockers and I'll send a note to the list before I
> >>  create the
> >>  branch.
> >> 
> >>  - Nick
> >> 
> >> 
> >>  On Wednesday, February 24, 2016, Uwe Schindler 
> >>  wrote:
> >> >
> >> > Hi Nicholas,
> >> >
> >> >
> >> >
> >> > before we start a branch_6_0 we should do the following:
> >> >
> >> >
> >> >
> >> > -  Start branch_6x as “new stable branch”
> >> >
> >> > -  Update version numbers in “master” to 7.0
> >> >
> >> >
> >> >
> >> > This should be done maybe early next week and then after a while
> >> > that
> >> > things settle (also the Jenkins Jobs for branch_6x are set up), we
> >> > can
> >> > proceed with a gap:
> >> >
> >> > -  Cut branch_6_0
> >> >
> >> > -  Update version numbers in “branch_6x” to 6.1
> >> >
> >> >
> >> >
> >> > Uwe
> >> >
> >> >
> >> >
> >> > -
> >> >
> >> > Uwe Schindler
> >> >
> >> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> >
> >> > http://www.thetaphi.de
> >> >
> >> > eMail: u...@thetaphi.de
> >> >
> >> >
> >> >
> >> > From: Nicholas Knize [mailto:nkn...@gmail.com]
> >> > Sent: Wednesday, February 24, 2016 9:23 PM
> >> > To: Lucene/Solr dev 

Re: Lucene/Solr 6.0.0 Release Branch

[Shalin Shekhar Mangar]

+1 to a separate branch_6_0 for the freeze. I'm going to create a 6.1
section in CHANGES.txt.

On Wed, Mar 2, 2016 at 4:49 PM, Alan Woodward  wrote:
> Should we create a separate branch_6_0 branch for the feature-freeze?  I
> have stuff to push into master and that should eventually make it into 6.1,
> and it will be easy to forget to backport stuff if there's a week before I
> can do that…
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 2 Mar 2016, at 09:39, Nicholas Knize wrote:
>
> Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
> let jenkins settle over the next week or so before beginning the actual
> release process.
>
> On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
>  wrote:
>>
>> Thanks Nick!
>>
>> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
>> Point values issues...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
>> > I created branch_6x and updated the version in master to 7.0.0 but it
>> > looks
>> > like I do not have jenkins karma to configure builds for the new 6x
>> > branch.
>> > Can someone have a look at configuring the builds?
>> >
>> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
>> > wrote:
>> >>
>> >>
>> >> Thanks for the info David!
>> >>
>> >> I'll likely update version labels and create the 6X branch late
>> >> tomorrow
>> >> or early the next day. Let me know if anyone has an issue with this
>> >> timing.
>> >>
>> >> Thanks,
>> >>
>> >> - Nick
>> >>
>> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
>> >>  wrote:
>> >>>
>> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
>> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
>> >>> move
>> >>> things around / rename.  But I don't mind doing an extra cherry pick
>> >>> in the
>> >>> end if you want to go create the branch without waiting.  So I don't
>> >>> know if
>> >>> you want to call that a blocker or not.
>> >>>
>> >>> Also, FYI there's a feature LUCENE-5735
>> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master
>> >>> (but
>> >>> not 5x) over a year ago but didn't quite close the issue.  I had found
>> >>> a bug
>> >>> or two but then lost the time to finish it.   I'd rather remove this
>> >>> feature
>> >>> from the 6x branch after you create the branch.  When I get more time
>> >>> (very
>> >>> likely this year) I can resolve the lingering bugs and get it into
>> >>> whatever
>> >>> 6.x release comes along then.  So nothing for you to do here but
>> >>> wanted to
>> >>> let you know.
>> >>>
>> >>> Hey thanks for pitching in to do the release.
>> >>>
>> >>> ~ David
>> >>>
>> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
>> >>> wrote:
>> 
>>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
>>  first. I'll plan to get that done Monday and/or Tuesday. Let me know
>>  if
>>  there are any blockers and I'll send a note to the list before I
>>  create the
>>  branch.
>> 
>>  - Nick
>> 
>> 
>>  On Wednesday, February 24, 2016, Uwe Schindler 
>>  wrote:
>> >
>> > Hi Nicholas,
>> >
>> >
>> >
>> > before we start a branch_6_0 we should do the following:
>> >
>> >
>> >
>> > -  Start branch_6x as “new stable branch”
>> >
>> > -  Update version numbers in “master” to 7.0
>> >
>> >
>> >
>> > This should be done maybe early next week and then after a while
>> > that
>> > things settle (also the Jenkins Jobs for branch_6x are set up), we
>> > can
>> > proceed with a gap:
>> >
>> > -  Cut branch_6_0
>> >
>> > -  Update version numbers in “branch_6x” to 6.1
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >
>> > From: Nicholas Knize [mailto:nkn...@gmail.com]
>> > Sent: Wednesday, February 24, 2016 9:23 PM
>> > To: Lucene/Solr dev 
>> > Subject: Lucene/Solr 6.0.0 Release Branch
>> >
>> >
>> >
>> > 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, 

Re: Lucene/Solr 6.0.0 Release Branch

[Alan Woodward]

Should we create a separate branch_6_0 branch for the feature-freeze?  I have 
stuff to push into master and that should eventually make it into 6.1, and it 
will be easy to forget to backport stuff if there's a week before I can do that…

Alan Woodward
www.flax.co.uk


On 2 Mar 2016, at 09:39, Nicholas Knize wrote:

> Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll let 
> jenkins settle over the next week or so before beginning the actual release 
> process.
> 
> On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless 
>  wrote:
> Thanks Nick!
> 
> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
> Point values issues...
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
> > I created branch_6x and updated the version in master to 7.0.0 but it looks
> > like I do not have jenkins karma to configure builds for the new 6x branch.
> > Can someone have a look at configuring the builds?
> >
> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize  wrote:
> >>
> >>
> >> Thanks for the info David!
> >>
> >> I'll likely update version labels and create the 6X branch late tomorrow
> >> or early the next day. Let me know if anyone has an issue with this timing.
> >>
> >> Thanks,
> >>
> >> - Nick
> >>
> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
> >>  wrote:
> >>>
> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
> >>> things around / rename.  But I don't mind doing an extra cherry pick in 
> >>> the
> >>> end if you want to go create the branch without waiting.  So I don't know 
> >>> if
> >>> you want to call that a blocker or not.
> >>>
> >>> Also, FYI there's a feature LUCENE-5735
> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
> >>> not 5x) over a year ago but didn't quite close the issue.  I had found a 
> >>> bug
> >>> or two but then lost the time to finish it.   I'd rather remove this 
> >>> feature
> >>> from the 6x branch after you create the branch.  When I get more time 
> >>> (very
> >>> likely this year) I can resolve the lingering bugs and get it into 
> >>> whatever
> >>> 6.x release comes along then.  So nothing for you to do here but wanted to
> >>> let you know.
> >>>
> >>> Hey thanks for pitching in to do the release.
> >>>
> >>> ~ David
> >>>
> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  wrote:
> 
>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
>  first. I'll plan to get that done Monday and/or Tuesday. Let me know if
>  there are any blockers and I'll send a note to the list before I create 
>  the
>  branch.
> 
>  - Nick
> 
> 
>  On Wednesday, February 24, 2016, Uwe Schindler  wrote:
> >
> > Hi Nicholas,
> >
> >
> >
> > before we start a branch_6_0 we should do the following:
> >
> >
> >
> > -  Start branch_6x as “new stable branch”
> >
> > -  Update version numbers in “master” to 7.0
> >
> >
> >
> > This should be done maybe early next week and then after a while that
> > things settle (also the Jenkins Jobs for branch_6x are set up), we can
> > proceed with a gap:
> >
> > -  Cut branch_6_0
> >
> > -  Update version numbers in “branch_6x” to 6.1
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Nicholas Knize [mailto:nkn...@gmail.com]
> > Sent: Wednesday, February 24, 2016 9:23 PM
> > To: Lucene/Solr dev 
> > Subject: Lucene/Solr 6.0.0 Release Branch
> >
> >
> >
> > 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-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

Thanks Mike! I'll have a look at addVersion.py and see if it needs to be
updated.

On Wed, Mar 2, 2016 at 3:50 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> TestBackCompat seems angry on master ... I'll try to fix it.  Seems
> like addVersion.py got confused maybe :)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Mar 2, 2016 at 4:39 AM, Nicholas Knize  wrote:
> > Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
> > let jenkins settle over the next week or so before beginning the actual
> > release process.
> >
> > On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
> >  wrote:
> >>
> >> Thanks Nick!
> >>
> >> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
> >> Point values issues...
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize 
> wrote:
> >> > I created branch_6x and updated the version in master to 7.0.0 but it
> >> > looks
> >> > like I do not have jenkins karma to configure builds for the new 6x
> >> > branch.
> >> > Can someone have a look at configuring the builds?
> >> >
> >> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
> >> > wrote:
> >> >>
> >> >>
> >> >> Thanks for the info David!
> >> >>
> >> >> I'll likely update version labels and create the 6X branch late
> >> >> tomorrow
> >> >> or early the next day. Let me know if anyone has an issue with this
> >> >> timing.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> - Nick
> >> >>
> >> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
> >> >>  wrote:
> >> >>>
> >> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a
> little
> >> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
> >> >>> move
> >> >>> things around / rename.  But I don't mind doing an extra cherry pick
> >> >>> in the
> >> >>> end if you want to go create the branch without waiting.  So I don't
> >> >>> know if
> >> >>> you want to call that a blocker or not.
> >> >>>
> >> >>> Also, FYI there's a feature LUCENE-5735
> >> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to
> master
> >> >>> (but
> >> >>> not 5x) over a year ago but didn't quite close the issue.  I had
> found
> >> >>> a bug
> >> >>> or two but then lost the time to finish it.   I'd rather remove this
> >> >>> feature
> >> >>> from the 6x branch after you create the branch.  When I get more
> time
> >> >>> (very
> >> >>> likely this year) I can resolve the lingering bugs and get it into
> >> >>> whatever
> >> >>> 6.x release comes along then.  So nothing for you to do here but
> >> >>> wanted to
> >> >>> let you know.
> >> >>>
> >> >>> Hey thanks for pitching in to do the release.
> >> >>>
> >> >>> ~ David
> >> >>>
> >> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
> >> >>> wrote:
> >> 
> >>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
> >>  first. I'll plan to get that done Monday and/or Tuesday. Let me
> know
> >>  if
> >>  there are any blockers and I'll send a note to the list before I
> >>  create the
> >>  branch.
> >> 
> >>  - Nick
> >> 
> >> 
> >>  On Wednesday, February 24, 2016, Uwe Schindler 
> >>  wrote:
> >> >
> >> > Hi Nicholas,
> >> >
> >> >
> >> >
> >> > before we start a branch_6_0 we should do the following:
> >> >
> >> >
> >> >
> >> > -  Start branch_6x as “new stable branch”
> >> >
> >> > -  Update version numbers in “master” to 7.0
> >> >
> >> >
> >> >
> >> > This should be done maybe early next week and then after a while
> >> > that
> >> > things settle (also the Jenkins Jobs for branch_6x are set up), we
> >> > can
> >> > proceed with a gap:
> >> >
> >> > -  Cut branch_6_0
> >> >
> >> > -  Update version numbers in “branch_6x” to 6.1
> >> >
> >> >
> >> >
> >> > Uwe
> >> >
> >> >
> >> >
> >> > -
> >> >
> >> > Uwe Schindler
> >> >
> >> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> >
> >> > http://www.thetaphi.de
> >> >
> >> > eMail: u...@thetaphi.de
> >> >
> >> >
> >> >
> >> > From: Nicholas Knize [mailto:nkn...@gmail.com]
> >> > Sent: Wednesday, February 24, 2016 9:23 PM
> >> > To: Lucene/Solr dev 
> >> > Subject: Lucene/Solr 6.0.0 Release Branch
> >> >
> >> >
> >> >
> >> > 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 

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

TestBackCompat seems angry on master ... I'll try to fix it.  Seems
like addVersion.py got confused maybe :)

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 2, 2016 at 4:39 AM, Nicholas Knize  wrote:
> Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
> let jenkins settle over the next week or so before beginning the actual
> release process.
>
> On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless
>  wrote:
>>
>> Thanks Nick!
>>
>> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
>> Point values issues...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
>> > I created branch_6x and updated the version in master to 7.0.0 but it
>> > looks
>> > like I do not have jenkins karma to configure builds for the new 6x
>> > branch.
>> > Can someone have a look at configuring the builds?
>> >
>> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
>> > wrote:
>> >>
>> >>
>> >> Thanks for the info David!
>> >>
>> >> I'll likely update version labels and create the 6X branch late
>> >> tomorrow
>> >> or early the next day. Let me know if anyone has an issue with this
>> >> timing.
>> >>
>> >> Thanks,
>> >>
>> >> - Nick
>> >>
>> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
>> >>  wrote:
>> >>>
>> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
>> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
>> >>> move
>> >>> things around / rename.  But I don't mind doing an extra cherry pick
>> >>> in the
>> >>> end if you want to go create the branch without waiting.  So I don't
>> >>> know if
>> >>> you want to call that a blocker or not.
>> >>>
>> >>> Also, FYI there's a feature LUCENE-5735
>> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master
>> >>> (but
>> >>> not 5x) over a year ago but didn't quite close the issue.  I had found
>> >>> a bug
>> >>> or two but then lost the time to finish it.   I'd rather remove this
>> >>> feature
>> >>> from the 6x branch after you create the branch.  When I get more time
>> >>> (very
>> >>> likely this year) I can resolve the lingering bugs and get it into
>> >>> whatever
>> >>> 6.x release comes along then.  So nothing for you to do here but
>> >>> wanted to
>> >>> let you know.
>> >>>
>> >>> Hey thanks for pitching in to do the release.
>> >>>
>> >>> ~ David
>> >>>
>> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
>> >>> wrote:
>> 
>>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
>>  first. I'll plan to get that done Monday and/or Tuesday. Let me know
>>  if
>>  there are any blockers and I'll send a note to the list before I
>>  create the
>>  branch.
>> 
>>  - Nick
>> 
>> 
>>  On Wednesday, February 24, 2016, Uwe Schindler 
>>  wrote:
>> >
>> > Hi Nicholas,
>> >
>> >
>> >
>> > before we start a branch_6_0 we should do the following:
>> >
>> >
>> >
>> > -  Start branch_6x as “new stable branch”
>> >
>> > -  Update version numbers in “master” to 7.0
>> >
>> >
>> >
>> > This should be done maybe early next week and then after a while
>> > that
>> > things settle (also the Jenkins Jobs for branch_6x are set up), we
>> > can
>> > proceed with a gap:
>> >
>> > -  Cut branch_6_0
>> >
>> > -  Update version numbers in “branch_6x” to 6.1
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >
>> > From: Nicholas Knize [mailto:nkn...@gmail.com]
>> > Sent: Wednesday, February 24, 2016 9:23 PM
>> > To: Lucene/Solr dev 
>> > Subject: Lucene/Solr 6.0.0 Release Branch
>> >
>> >
>> >
>> > 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: 

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll
let jenkins settle over the next week or so before beginning the actual
release process.

On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Thanks Nick!
>
> Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
> Point values issues...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
> > I created branch_6x and updated the version in master to 7.0.0 but it
> looks
> > like I do not have jenkins karma to configure builds for the new 6x
> branch.
> > Can someone have a look at configuring the builds?
> >
> > On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize 
> wrote:
> >>
> >>
> >> Thanks for the info David!
> >>
> >> I'll likely update version labels and create the 6X branch late tomorrow
> >> or early the next day. Let me know if anyone has an issue with this
> timing.
> >>
> >> Thanks,
> >>
> >> - Nick
> >>
> >> On Monday, February 29, 2016, david.w.smi...@gmail.com
> >>  wrote:
> >>>
> >>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
> >>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to
> move
> >>> things around / rename.  But I don't mind doing an extra cherry pick
> in the
> >>> end if you want to go create the branch without waiting.  So I don't
> know if
> >>> you want to call that a blocker or not.
> >>>
> >>> Also, FYI there's a feature LUCENE-5735
> >>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master
> (but
> >>> not 5x) over a year ago but didn't quite close the issue.  I had found
> a bug
> >>> or two but then lost the time to finish it.   I'd rather remove this
> feature
> >>> from the 6x branch after you create the branch.  When I get more time
> (very
> >>> likely this year) I can resolve the lingering bugs and get it into
> whatever
> >>> 6.x release comes along then.  So nothing for you to do here but
> wanted to
> >>> let you know.
> >>>
> >>> Hey thanks for pitching in to do the release.
> >>>
> >>> ~ David
> >>>
> >>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize 
> wrote:
> 
>  Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
>  first. I'll plan to get that done Monday and/or Tuesday. Let me know
> if
>  there are any blockers and I'll send a note to the list before I
> create the
>  branch.
> 
>  - Nick
> 
> 
>  On Wednesday, February 24, 2016, Uwe Schindler 
> wrote:
> >
> > Hi Nicholas,
> >
> >
> >
> > before we start a branch_6_0 we should do the following:
> >
> >
> >
> > -  Start branch_6x as “new stable branch”
> >
> > -  Update version numbers in “master” to 7.0
> >
> >
> >
> > This should be done maybe early next week and then after a while that
> > things settle (also the Jenkins Jobs for branch_6x are set up), we
> can
> > proceed with a gap:
> >
> > -  Cut branch_6_0
> >
> > -  Update version numbers in “branch_6x” to 6.1
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Nicholas Knize [mailto:nkn...@gmail.com]
> > Sent: Wednesday, February 24, 2016 9:23 PM
> > To: Lucene/Solr dev 
> > Subject: Lucene/Solr 6.0.0 Release Branch
> >
> >
> >
> > 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-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

Thanks Uwe!

On Wed, Mar 2, 2016 at 3:18 AM, Uwe Schindler <u...@thetaphi.de> wrote:

> Will do that!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Nicholas Knize [mailto:nkn...@gmail.com]
> *Sent:* Wednesday, March 02, 2016 10:15 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Lucene/Solr 6.0.0 Release Branch
>
>
>
> I created branch_6x and updated the version in master to 7.0.0 but it
> looks like I do not have jenkins karma to configure builds for the new 6x
> branch. Can someone have a look at configuring the builds?
>
>
>
> On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize <nkn...@gmail.com> wrote:
>
>
> Thanks for the info David!
>
>
>
> I'll likely update version labels and create the 6X branch late tomorrow
> or early the next day. Let me know if anyone has an issue with this timing.
>
>
>
> Thanks,
>
>
>
> - Nick
>
>
> On Monday, February 29, 2016, david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
> things around / rename.  But I don't mind doing an extra cherry pick in the
> end if you want to go create the branch without waiting.  So I don't know
> if you want to call that a blocker or not.
>
>
>
> Also, FYI there's a feature LUCENE-5735
> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
> not 5x) over a year ago but didn't quite close the issue.  I had found a
> bug or two but then lost the time to finish it.   I'd rather remove this
> feature from the 6x branch after you create the branch.  When I get more
> time (very likely this year) I can resolve the lingering bugs and get it
> into whatever 6.x release comes along then.  So nothing for you to do here
> but wanted to let you know.
>
>
>
> Hey thanks for pitching in to do the release.
>
>
>
> ~ David
>
>
>
> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize <nkn...@gmail.com> wrote:
>
> Thanks Uwe!  Indeed we need branch_6x (and master versions changed) first.
> I'll plan to get that done Monday and/or Tuesday. Let me know if there are
> any blockers and I'll send a note to the list before I create the branch.
>
>
>
> - Nick
>
>
>
> On Wednesday, February 24, 2016, Uwe Schindler <u...@thetaphi.de> wrote:
>
> Hi Nicholas,
>
>
>
> before we start a branch_6_0 we should do the following:
>
>
>
> -  Start branch_6x as “new stable branch”
>
> -  Update version numbers in “master” to 7.0
>
>
>
> This should be done maybe early next week and then after a while that
> things settle (also the Jenkins Jobs for branch_6x are set up), we can
> proceed with a gap:
>
> -  Cut branch_6_0
>
> -  Update version numbers in “branch_6x” to 6.1
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Nicholas Knize [mailto:nkn...@gmail.com <nkn...@gmail.com>]
> *Sent:* Wednesday, February 24, 2016 9:23 PM
> *To:* Lucene/Solr dev <dev@lucene.apache.org>
> *Subject:* Lucene/Solr 6.0.0 Release Branch
>
>
>
> 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

[Michael McCandless]

Thanks Nick!

Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)?
Point values issues...

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize  wrote:
> I created branch_6x and updated the version in master to 7.0.0 but it looks
> like I do not have jenkins karma to configure builds for the new 6x branch.
> Can someone have a look at configuring the builds?
>
> On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize  wrote:
>>
>>
>> Thanks for the info David!
>>
>> I'll likely update version labels and create the 6X branch late tomorrow
>> or early the next day. Let me know if anyone has an issue with this timing.
>>
>> Thanks,
>>
>> - Nick
>>
>> On Monday, February 29, 2016, david.w.smi...@gmail.com
>>  wrote:
>>>
>>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
>>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
>>> things around / rename.  But I don't mind doing an extra cherry pick in the
>>> end if you want to go create the branch without waiting.  So I don't know if
>>> you want to call that a blocker or not.
>>>
>>> Also, FYI there's a feature LUCENE-5735
>>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
>>> not 5x) over a year ago but didn't quite close the issue.  I had found a bug
>>> or two but then lost the time to finish it.   I'd rather remove this feature
>>> from the 6x branch after you create the branch.  When I get more time (very
>>> likely this year) I can resolve the lingering bugs and get it into whatever
>>> 6.x release comes along then.  So nothing for you to do here but wanted to
>>> let you know.
>>>
>>> Hey thanks for pitching in to do the release.
>>>
>>> ~ David
>>>
>>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  wrote:

 Thanks Uwe!  Indeed we need branch_6x (and master versions changed)
 first. I'll plan to get that done Monday and/or Tuesday. Let me know if
 there are any blockers and I'll send a note to the list before I create the
 branch.

 - Nick


 On Wednesday, February 24, 2016, Uwe Schindler  wrote:
>
> Hi Nicholas,
>
>
>
> before we start a branch_6_0 we should do the following:
>
>
>
> -  Start branch_6x as “new stable branch”
>
> -  Update version numbers in “master” to 7.0
>
>
>
> This should be done maybe early next week and then after a while that
> things settle (also the Jenkins Jobs for branch_6x are set up), we can
> proceed with a gap:
>
> -  Cut branch_6_0
>
> -  Update version numbers in “branch_6x” to 6.1
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Nicholas Knize [mailto:nkn...@gmail.com]
> Sent: Wednesday, February 24, 2016 9:23 PM
> To: Lucene/Solr dev 
> Subject: Lucene/Solr 6.0.0 Release Branch
>
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: Lucene/Solr 6.0.0 Release Branch

[Uwe Schindler]

Will do that!

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Nicholas Knize [mailto:nkn...@gmail.com] 
Sent: Wednesday, March 02, 2016 10:15 AM
To: dev@lucene.apache.org
Subject: Re: Lucene/Solr 6.0.0 Release Branch

 

I created branch_6x and updated the version in master to 7.0.0 but it looks 
like I do not have jenkins karma to configure builds for the new 6x branch. Can 
someone have a look at configuring the builds?

 

On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize <nkn...@gmail.com 
<mailto:nkn...@gmail.com> > wrote:


Thanks for the info David!

 

I'll likely update version labels and create the 6X branch late tomorrow or 
early the next day. Let me know if anyone has an issue with this timing.

 

Thanks,

 

- Nick


On Monday, February 29, 2016, david.w.smi...@gmail.com 
<mailto:david.w.smi...@gmail.com>  <david.w.smi...@gmail.com 
<mailto:david.w.smi...@gmail.com> > wrote:

I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little 
spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move things 
around / rename.  But I don't mind doing an extra cherry pick in the end if you 
want to go create the branch without waiting.  So I don't know if you want to 
call that a blocker or not.  

 

Also, FYI there's a feature LUCENE-5735 
(NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but not 
5x) over a year ago but didn't quite close the issue.  I had found a bug or two 
but then lost the time to finish it.   I'd rather remove this feature from the 
6x branch after you create the branch.  When I get more time (very likely this 
year) I can resolve the lingering bugs and get it into whatever 6.x release 
comes along then.  So nothing for you to do here but wanted to let you know.

 

Hey thanks for pitching in to do the release.

 

~ David

 

On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize < <mailto:nkn...@gmail.com> 
nkn...@gmail.com> wrote:

Thanks Uwe!  Indeed we need branch_6x (and master versions changed) first. I'll 
plan to get that done Monday and/or Tuesday. Let me know if there are any 
blockers and I'll send a note to the list before I create the branch. 

 

- Nick



On Wednesday, February 24, 2016, Uwe Schindler < <mailto:u...@thetaphi.de> 
u...@thetaphi.de> wrote:

Hi Nicholas,

 

before we start a branch_6_0 we should do the following:

 

-  Start branch_6x as “new stable branch”

-  Update version numbers in “master” to 7.0

 

This should be done maybe early next week and then after a while that things 
settle (also the Jenkins Jobs for branch_6x are set up), we can proceed with a 
gap:

-  Cut branch_6_0

-  Update version numbers in “branch_6x” to 6.1

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de <http://www.thetaphi.de/> 

eMail:  <mailto:u...@thetaphi.de> u...@thetaphi.de

 

From: Nicholas Knize [ <mailto:nkn...@gmail.com> mailto:nkn...@gmail.com] 
Sent: Wednesday, February 24, 2016 9:23 PM
To: Lucene/Solr dev < <mailto:dev@lucene.apache.org> dev@lucene.apache.org>
Subject: Lucene/Solr 6.0.0 Release Branch

 

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

[Nicholas Knize]

I created branch_6x and updated the version in master to 7.0.0 but it looks
like I do not have jenkins karma to configure builds for the new 6x branch.
Can someone have a look at configuring the builds?

On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize  wrote:

>
> Thanks for the info David!
>
> I'll likely update version labels and create the 6X branch late tomorrow
> or early the next day. Let me know if anyone has an issue with this timing.
>
> Thanks,
>
> - Nick
>
> On Monday, February 29, 2016, david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
>> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
>> things around / rename.  But I don't mind doing an extra cherry pick in the
>> end if you want to go create the branch without waiting.  So I don't know
>> if you want to call that a blocker or not.
>>
>> Also, FYI there's a feature LUCENE-5735
>> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
>> not 5x) over a year ago but didn't quite close the issue.  I had found a
>> bug or two but then lost the time to finish it.   I'd rather remove this
>> feature from the 6x branch after you create the branch.  When I get more
>> time (very likely this year) I can resolve the lingering bugs and get it
>> into whatever 6.x release comes along then.  So nothing for you to do here
>> but wanted to let you know.
>>
>> Hey thanks for pitching in to do the release.
>>
>> ~ David
>>
>> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  wrote:
>>
>>> Thanks Uwe!  Indeed we need branch_6x (and master versions
>>> changed) first. I'll plan to get that done Monday and/or Tuesday. Let me
>>> know if there are any blockers and I'll send a note to the list before I
>>> create the branch.
>>>
>>> - Nick
>>>
>>>
>>> On Wednesday, February 24, 2016, Uwe Schindler  wrote:
>>>
 Hi Nicholas,



 before we start a branch_6_0 we should do the following:



 -  Start branch_6x as “new stable branch”

 -  Update version numbers in “master” to 7.0



 This should be done maybe early next week and then after a while that
 things settle (also the Jenkins Jobs for branch_6x are set up), we can
 proceed with a gap:

 -  Cut branch_6_0

 -  Update version numbers in “branch_6x” to 6.1



 Uwe



 -

 Uwe Schindler

 H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Nicholas Knize [mailto:nkn...@gmail.com]
 *Sent:* Wednesday, February 24, 2016 9:23 PM
 *To:* Lucene/Solr dev 
 *Subject:* Lucene/Solr 6.0.0 Release Branch



 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

[Nicholas Knize]

Thanks for the info David!

I'll likely update version labels and create the 6X branch late tomorrow or
early the next day. Let me know if anyone has an issue with this timing.

Thanks,

- Nick

On Monday, February 29, 2016, david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
> spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
> things around / rename.  But I don't mind doing an extra cherry pick in the
> end if you want to go create the branch without waiting.  So I don't know
> if you want to call that a blocker or not.
>
> Also, FYI there's a feature LUCENE-5735
> (NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
> not 5x) over a year ago but didn't quite close the issue.  I had found a
> bug or two but then lost the time to finish it.   I'd rather remove this
> feature from the 6x branch after you create the branch.  When I get more
> time (very likely this year) I can resolve the lingering bugs and get it
> into whatever 6.x release comes along then.  So nothing for you to do here
> but wanted to let you know.
>
> Hey thanks for pitching in to do the release.
>
> ~ David
>
> On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  > wrote:
>
>> Thanks Uwe!  Indeed we need branch_6x (and master versions
>> changed) first. I'll plan to get that done Monday and/or Tuesday. Let me
>> know if there are any blockers and I'll send a note to the list before I
>> create the branch.
>>
>> - Nick
>>
>>
>> On Wednesday, February 24, 2016, Uwe Schindler > > wrote:
>>
>>> Hi Nicholas,
>>>
>>>
>>>
>>> before we start a branch_6_0 we should do the following:
>>>
>>>
>>>
>>> -  Start branch_6x as “new stable branch”
>>>
>>> -  Update version numbers in “master” to 7.0
>>>
>>>
>>>
>>> This should be done maybe early next week and then after a while that
>>> things settle (also the Jenkins Jobs for branch_6x are set up), we can
>>> proceed with a gap:
>>>
>>> -  Cut branch_6_0
>>>
>>> -  Update version numbers in “branch_6x” to 6.1
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> *From:* Nicholas Knize [mailto:nkn...@gmail.com]
>>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>>> *To:* Lucene/Solr dev 
>>> *Subject:* Lucene/Solr 6.0.0 Release Branch
>>>
>>>
>>>
>>> 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

[david.w.smi...@gmail.com]

I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
things around / rename.  But I don't mind doing an extra cherry pick in the
end if you want to go create the branch without waiting.  So I don't know
if you want to call that a blocker or not.

Also, FYI there's a feature LUCENE-5735
(NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
not 5x) over a year ago but didn't quite close the issue.  I had found a
bug or two but then lost the time to finish it.   I'd rather remove this
feature from the 6x branch after you create the branch.  When I get more
time (very likely this year) I can resolve the lingering bugs and get it
into whatever 6.x release comes along then.  So nothing for you to do here
but wanted to let you know.

Hey thanks for pitching in to do the release.

~ David

On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  wrote:

> Thanks Uwe!  Indeed we need branch_6x (and master versions changed) first.
> I'll plan to get that done Monday and/or Tuesday. Let me know if there are
> any blockers and I'll send a note to the list before I create the branch.
>
> - Nick
>
>
> On Wednesday, February 24, 2016, Uwe Schindler  wrote:
>
>> Hi Nicholas,
>>
>>
>>
>> before we start a branch_6_0 we should do the following:
>>
>>
>>
>> -  Start branch_6x as “new stable branch”
>>
>> -  Update version numbers in “master” to 7.0
>>
>>
>>
>> This should be done maybe early next week and then after a while that
>> things settle (also the Jenkins Jobs for branch_6x are set up), we can
>> proceed with a gap:
>>
>> -  Cut branch_6_0
>>
>> -  Update version numbers in “branch_6x” to 6.1
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Nicholas Knize [mailto:nkn...@gmail.com]
>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>> *To:* Lucene/Solr dev 
>> *Subject:* Lucene/Solr 6.0.0 Release Branch
>>
>>
>>
>> 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

[Nicholas Knize]

Thanks Uwe!  Indeed we need branch_6x (and master versions changed) first.
I'll plan to get that done Monday and/or Tuesday. Let me know if there are
any blockers and I'll send a note to the list before I create the branch.

- Nick

On Wednesday, February 24, 2016, Uwe Schindler  wrote:

> Hi Nicholas,
>
>
>
> before we start a branch_6_0 we should do the following:
>
>
>
> -  Start branch_6x as “new stable branch”
>
> -  Update version numbers in “master” to 7.0
>
>
>
> This should be done maybe early next week and then after a while that
> things settle (also the Jenkins Jobs for branch_6x are set up), we can
> proceed with a gap:
>
> -  Cut branch_6_0
>
> -  Update version numbers in “branch_6x” to 6.1
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de 
>
>
>
> *From:* Nicholas Knize [mailto:nkn...@gmail.com
> ]
> *Sent:* Wednesday, February 24, 2016 9:23 PM
> *To:* Lucene/Solr dev  >
> *Subject:* Lucene/Solr 6.0.0 Release Branch
>
>
>
> 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
>

Re: Lucene/Solr 6.0.0 Release Branch

[Michael McCandless]

Thank you for volunteering Nick!

Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 24, 2016 at 3:23 PM, Nicholas Knize  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

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

RE: Lucene/Solr 6.0.0 Release Branch

[Uwe Schindler]

Hi Nicholas,

 

before we start a branch_6_0 we should do the following:

 

-  Start branch_6x as “new stable branch”

-  Update version numbers in “master” to 7.0

 

This should be done maybe early next week and then after a while that things 
settle (also the Jenkins Jobs for branch_6x are set up), we can proceed with a 
gap:

-  Cut branch_6_0

-  Update version numbers in “branch_6x” to 6.1

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Nicholas Knize [mailto:nkn...@gmail.com] 
Sent: Wednesday, February 24, 2016 9:23 PM
To: Lucene/Solr dev 
Subject: Lucene/Solr 6.0.0 Release Branch

 

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

Re: Lucene/Solr 6.0.0 Release Branch

[Mike Drob]

I'd really like to see LUCENE-6993 make it in, but unfortunately, I don't
have an ETA on it at this time.

On Wed, Feb 24, 2016 at 2:23 PM, Nicholas Knize  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
>

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

Hi Christian,

These look like great improvements to Kuromoji, but for the same
reasons, I think it's risky to commit these changes at the last
minute, not giving Jenkins time to chew on it, etc.

I think they should just go into 6.0 instead, which is coming out
shortly after 5.5?

A release is not the time to shove new features in.  Rather, it's the
opposite: you hold back large changes for the following release.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 10, 2016 at 4:27 AM, Christian Moen  wrote:
> Hello,
>
> I'd like to get LUCENE-6837 and LUCENE-3922 into 5.5.  I believe I can have
> them merged this week.
>
> Best,
> Christian
>
> On Feb 5, 2016, at 02:42, Nicholas Knize  wrote:
>
> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
> performance), and graduates these features from sandbox. They should be
> ready by Monday (or sooner).
>
> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>  wrote:
>>
>> I think we are in good shape now for 6.0.0?
>>
>> git cutover is done and seems to be going well except for how we name
>> branches
>>
>> Dimensional values are renamed to point values, the API is cleaned up
>> a bit, and you can now search for == (not just ranges), and
>> StoredDocument is removed.
>>
>> We should first do a 5.5.0 release to get all the goodness back-ported
>> 5.x features out, and also smoke-test our first git-based release.
>> Does anyone want to volunteer as RM?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller  wrote:
>> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>> >  wrote:
>> >>
>> >> I agree it would be nice to have cutover to git by then: are we ready
>> >> to open an INFRA issue to do the hard cutover?  Or do we still have
>> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>> >> and everyone else for pushing hard on this front!).
>> >
>> >
>> > We are fairly close - just one last thing to come to consensus on.
>> > Remains
>> > to be seen how fast INFRA reacts for us though.
>> >
>> > There will also probably be a bit to do as we work through the first
>> > release, in terms of release scripts, docs, etc. I think most of it
>> > should
>> > be fairly light weight changes though.
>> >
>> > - Mark
>> > --
>> > - Mark
>> > about.me/markrmiller
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>

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

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

On Tue, Feb 9, 2016 at 3:14 PM, Anshum Gupta  wrote:
> Thanks Mike for volunteering!

You're welcome!

> I wanted to get SOLR-8619 in for 5.5.0, I'll mark that as a blocker as it
> can potentially cause data loss. I'm currently working on that.

Hmm this is a little concerning: I don't see a patch on the issue, not
even for a test case showing the problem?  No comments for the past
1.5 weeks or so?

There seems to be a lot of design level discussion there about what
the issue(s) are, how to fix it, etc.?  It's risky to rush in a fix in
just before a release.

We can do a 5.5.1 in short order with this fix?

Alternatively, we could roll the release bits just for Lucene 5.5.0,
and Solr 5.5.0 is released later.

> I also have a bunch of Solr related stuff I wanted to commit before moving
> on the 6.0 path so back-compat wouldn't be a problem, but we can always have
> another deprecation release before 6.0 if needed, specially once we have the
> git based release process ironed out.
>
> I am not saying we WILL have another 5.x release, just a thought. It all
> depends on the release timeline for 6.0 :)

Hmm, I expect 5.5 will be the last 5.x feature release, i.e. we can do
5.5.x bug fix releases, but I don't think we should do another 5.x
feature release once we release 6.0.  The next feature release should
be 6.1 after that?  Or maybe only Solr could do a 5.6.0?

Mike McCandless

http://blog.mikemccandless.com

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

Re: Lucene/Solr 6.0.0 release

[Christian Moen]

Hello,

I'd like to get LUCENE-6837 and LUCENE-3922 into 5.5.  I believe I can have 
them merged this week.

Best,
Christian

> On Feb 5, 2016, at 02:42, Nicholas Knize  wrote:
> 
> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5: LUCENE-6930 
>  and LUCENE-6997 
>  which changes GeoPoint 
> encoding (boosting performance), and graduates these features from sandbox. 
> They should be ready by Monday (or sooner).
> 
> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless 
> > wrote:
> I think we are in good shape now for 6.0.0?
> 
> git cutover is done and seems to be going well except for how we name branches
> 
> Dimensional values are renamed to point values, the API is cleaned up
> a bit, and you can now search for == (not just ranges), and
> StoredDocument is removed.
> 
> We should first do a 5.5.0 release to get all the goodness back-ported
> 5.x features out, and also smoke-test our first git-based release.
> Does anyone want to volunteer as RM?
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com 
> 
> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller  > wrote:
> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
> > > wrote:
> >>
> >> I agree it would be nice to have cutover to git by then: are we ready
> >> to open an INFRA issue to do the hard cutover?  Or do we still have
> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> >> and everyone else for pushing hard on this front!).
> >
> >
> > We are fairly close - just one last thing to come to consensus on. Remains
> > to be seen how fast INFRA reacts for us though.
> >
> > There will also probably be a bit to do as we work through the first
> > release, in terms of release scripts, docs, etc. I think most of it should
> > be fairly light weight changes though.
> >
> > - Mark
> > --
> > - Mark
> > about.me/markrmiller 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 

Re: Lucene/Solr 6.0.0 release

[Anshum Gupta]

Thanks Mike for volunteering!

I wanted to get SOLR-8619 in for 5.5.0, I'll mark that as a blocker as it
can potentially cause data loss. I'm currently working on that.

I also have a bunch of Solr related stuff I wanted to commit before moving
on the 6.0 path so back-compat wouldn't be a problem, but we can always
have another deprecation release before 6.0 if needed, specially once we
have the git based release process ironed out.

I am not saying we WILL have another 5.x release, just a thought. It all
depends on the release timeline for 6.0 :)


On Tue, Feb 9, 2016 at 11:56 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Thanks Christine, I'll wait for SOLR-8621 before cutting the branch.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Feb 9, 2016 at 2:46 PM, Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> > +1 for 5.5.0 release.
> >
> > Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with
> collaboration and help from Shai) but a signature change for
> MergePolicyFactory will be needed to support SOLR-5730 (which ideally would
> also be included in 5.5.0 and which hopefully can be wrapped up this week
> also, patch update to follow later today).
> >
> > Sorry for not speaking up about these two tickets earlier, I had
> optimistically thought that they would be done-and-dusted by 'mid this
> week' but it didn't quite turn out like that ...
> >
> > Christine
> >
> > - Original Message -
> > From: dev@lucene.apache.org
> > To: dev@lucene.apache.org
> > At: Feb  5 2016 10:17:40
> >
> > Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
> > 5.5 issues, please mark them as such in Jira, thanks!
> >
> > I don't think we are rushing here ... it was a little under a month
> > ago when I had thought "in or week or two" let's cut the 6.x branch ;)
> >
> > I see 5.5 release as just getting all the (stable) backported features
> > out to the world before we release 6.0.0.
> >
> > I'll aim to cut the 5.5 branch mid next week...
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta 
> wrote:
> >> I have a few things I'd like to get in. I hope to get those in by next
> week.
> >>
> >> I think the 5.5 release is an important one for us as the cleanup in 6.0
> >> depends on it. We shouldn't rush it.
> >>
> >> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize 
> wrote:
> >>>
> >>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
> >>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
> >>> performance), and graduates these features from sandbox. They should be
> >>> ready by Monday (or sooner).
> >>>
> >>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
> >>>  wrote:
> 
>  I think we are in good shape now for 6.0.0?
> 
>  git cutover is done and seems to be going well except for how we name
>  branches
> 
>  Dimensional values are renamed to point values, the API is cleaned up
>  a bit, and you can now search for == (not just ranges), and
>  StoredDocument is removed.
> 
>  We should first do a 5.5.0 release to get all the goodness back-ported
>  5.x features out, and also smoke-test our first git-based release.
>  Does anyone want to volunteer as RM?
> 
>  Mike McCandless
> 
>  http://blog.mikemccandless.com
> 
>  On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>  wrote:
>  > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>  >  wrote:
>  >>
>  >> I agree it would be nice to have cutover to git by then: are we
> ready
>  >> to open an INFRA issue to do the hard cutover?  Or do we still have
>  >> things to do on our end?  (Thank you Dawid and Mark and Paul and
> Uwe
>  >> and everyone else for pushing hard on this front!).
>  >
>  >
>  > We are fairly close - just one last thing to come to consensus on.
>  > Remains
>  > to be seen how fast INFRA reacts for us though.
>  >
>  > There will also probably be a bit to do as we work through the first
>  > release, in terms of release scripts, docs, etc. I think most of it
>  > should
>  > be fairly light weight changes though.
>  >
>  > - Mark
>  > --
>  > - Mark
>  > about.me/markrmiller
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Anshum Gupta
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
>
> 

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

Thanks Christine, I'll wait for SOLR-8621 before cutting the branch.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Feb 9, 2016 at 2:46 PM, Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
> +1 for 5.5.0 release.
>
> Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with 
> collaboration and help from Shai) but a signature change for 
> MergePolicyFactory will be needed to support SOLR-5730 (which ideally would 
> also be included in 5.5.0 and which hopefully can be wrapped up this week 
> also, patch update to follow later today).
>
> Sorry for not speaking up about these two tickets earlier, I had 
> optimistically thought that they would be done-and-dusted by 'mid this week' 
> but it didn't quite turn out like that ...
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: Feb  5 2016 10:17:40
>
> Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
> 5.5 issues, please mark them as such in Jira, thanks!
>
> I don't think we are rushing here ... it was a little under a month
> ago when I had thought "in or week or two" let's cut the 6.x branch ;)
>
> I see 5.5 release as just getting all the (stable) backported features
> out to the world before we release 6.0.0.
>
> I'll aim to cut the 5.5 branch mid next week...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta  wrote:
>> I have a few things I'd like to get in. I hope to get those in by next week.
>>
>> I think the 5.5 release is an important one for us as the cleanup in 6.0
>> depends on it. We shouldn't rush it.
>>
>> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:
>>>
>>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
>>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
>>> performance), and graduates these features from sandbox. They should be
>>> ready by Monday (or sooner).
>>>
>>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>>>  wrote:

 I think we are in good shape now for 6.0.0?

 git cutover is done and seems to be going well except for how we name
 branches

 Dimensional values are renamed to point values, the API is cleaned up
 a bit, and you can now search for == (not just ranges), and
 StoredDocument is removed.

 We should first do a 5.5.0 release to get all the goodness back-ported
 5.x features out, and also smoke-test our first git-based release.
 Does anyone want to volunteer as RM?

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
 wrote:
 > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
 >  wrote:
 >>
 >> I agree it would be nice to have cutover to git by then: are we ready
 >> to open an INFRA issue to do the hard cutover?  Or do we still have
 >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
 >> and everyone else for pushing hard on this front!).
 >
 >
 > We are fairly close - just one last thing to come to consensus on.
 > Remains
 > to be seen how fast INFRA reacts for us though.
 >
 > There will also probably be a bit to do as we work through the first
 > release, in terms of release scripts, docs, etc. I think most of it
 > should
 > be fairly light weight changes though.
 >
 > - Mark
 > --
 > - Mark
 > about.me/markrmiller

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

>>>
>>
>>
>>
>> --
>> Anshum Gupta
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

Re: Lucene/Solr 6.0.0 release

[Christine Poerschke (BLOOMBERG/ LONDON)]

+1 for 5.5.0 release.

Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with 
collaboration and help from Shai) but a signature change for MergePolicyFactory 
will be needed to support SOLR-5730 (which ideally would also be included in 
5.5.0 and which hopefully can be wrapped up this week also, patch update to 
follow later today).

Sorry for not speaking up about these two tickets earlier, I had optimistically 
thought that they would be done-and-dusted by 'mid this week' but it didn't 
quite turn out like that ...

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: Feb  5 2016 10:17:40

Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
5.5 issues, please mark them as such in Jira, thanks!

I don't think we are rushing here ... it was a little under a month
ago when I had thought "in or week or two" let's cut the 6.x branch ;)

I see 5.5 release as just getting all the (stable) backported features
out to the world before we release 6.0.0.

I'll aim to cut the 5.5 branch mid next week...

Mike McCandless

http://blog.mikemccandless.com


On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta  wrote:
> I have a few things I'd like to get in. I hope to get those in by next week.
>
> I think the 5.5 release is an important one for us as the cleanup in 6.0
> depends on it. We shouldn't rush it.
>
> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:
>>
>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
>> performance), and graduates these features from sandbox. They should be
>> ready by Monday (or sooner).
>>
>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>>  wrote:
>>>
>>> I think we are in good shape now for 6.0.0?
>>>
>>> git cutover is done and seems to be going well except for how we name
>>> branches
>>>
>>> Dimensional values are renamed to point values, the API is cleaned up
>>> a bit, and you can now search for == (not just ranges), and
>>> StoredDocument is removed.
>>>
>>> We should first do a 5.5.0 release to get all the goodness back-ported
>>> 5.x features out, and also smoke-test our first git-based release.
>>> Does anyone want to volunteer as RM?
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>>> wrote:
>>> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>>> >  wrote:
>>> >>
>>> >> I agree it would be nice to have cutover to git by then: are we ready
>>> >> to open an INFRA issue to do the hard cutover?  Or do we still have
>>> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>>> >> and everyone else for pushing hard on this front!).
>>> >
>>> >
>>> > We are fairly close - just one last thing to come to consensus on.
>>> > Remains
>>> > to be seen how fast INFRA reacts for us though.
>>> >
>>> > There will also probably be a bit to do as we work through the first
>>> > release, in terms of release scripts, docs, etc. I think most of it
>>> > should
>>> > be fairly light weight changes though.
>>> >
>>> > - Mark
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>
>
>
> --
> Anshum Gupta

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

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
5.5 issues, please mark them as such in Jira, thanks!

I don't think we are rushing here ... it was a little under a month
ago when I had thought "in or week or two" let's cut the 6.x branch ;)

I see 5.5 release as just getting all the (stable) backported features
out to the world before we release 6.0.0.

I'll aim to cut the 5.5 branch mid next week...

Mike McCandless

http://blog.mikemccandless.com


On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta  wrote:
> I have a few things I'd like to get in. I hope to get those in by next week.
>
> I think the 5.5 release is an important one for us as the cleanup in 6.0
> depends on it. We shouldn't rush it.
>
> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:
>>
>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
>> performance), and graduates these features from sandbox. They should be
>> ready by Monday (or sooner).
>>
>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>>  wrote:
>>>
>>> I think we are in good shape now for 6.0.0?
>>>
>>> git cutover is done and seems to be going well except for how we name
>>> branches
>>>
>>> Dimensional values are renamed to point values, the API is cleaned up
>>> a bit, and you can now search for == (not just ranges), and
>>> StoredDocument is removed.
>>>
>>> We should first do a 5.5.0 release to get all the goodness back-ported
>>> 5.x features out, and also smoke-test our first git-based release.
>>> Does anyone want to volunteer as RM?
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>>> wrote:
>>> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>>> >  wrote:
>>> >>
>>> >> I agree it would be nice to have cutover to git by then: are we ready
>>> >> to open an INFRA issue to do the hard cutover?  Or do we still have
>>> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>>> >> and everyone else for pushing hard on this front!).
>>> >
>>> >
>>> > We are fairly close - just one last thing to come to consensus on.
>>> > Remains
>>> > to be seen how fast INFRA reacts for us though.
>>> >
>>> > There will also probably be a bit to do as we work through the first
>>> > release, in terms of release scripts, docs, etc. I think most of it
>>> > should
>>> > be fairly light weight changes though.
>>> >
>>> > - Mark
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>
>
>
> --
> Anshum Gupta

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

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

I think we are in good shape now for 6.0.0?

git cutover is done and seems to be going well except for how we name branches

Dimensional values are renamed to point values, the API is cleaned up
a bit, and you can now search for == (not just ranges), and
StoredDocument is removed.

We should first do a 5.5.0 release to get all the goodness back-ported
5.x features out, and also smoke-test our first git-based release.
Does anyone want to volunteer as RM?

Mike McCandless

http://blog.mikemccandless.com

On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller  wrote:
> On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>  wrote:
>>
>> I agree it would be nice to have cutover to git by then: are we ready
>> to open an INFRA issue to do the hard cutover?  Or do we still have
>> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>> and everyone else for pushing hard on this front!).
>
>
> We are fairly close - just one last thing to come to consensus on. Remains
> to be seen how fast INFRA reacts for us though.
>
> There will also probably be a bit to do as we work through the first
> release, in terms of release scripts, docs, etc. I think most of it should
> be fairly light weight changes though.
>
> - Mark
> --
> - Mark
> about.me/markrmiller

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

Re: Lucene/Solr 6.0.0 release

[Nicholas Knize]

+1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
LUCENE-6930  and
LUCENE-6997  which
changes GeoPoint encoding (boosting performance), and graduates these
features from sandbox. They should be ready by Monday (or sooner).

On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I think we are in good shape now for 6.0.0?
>
> git cutover is done and seems to be going well except for how we name
> branches
>
> Dimensional values are renamed to point values, the API is cleaned up
> a bit, and you can now search for == (not just ranges), and
> StoredDocument is removed.
>
> We should first do a 5.5.0 release to get all the goodness back-ported
> 5.x features out, and also smoke-test our first git-based release.
> Does anyone want to volunteer as RM?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller  wrote:
> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
> >  wrote:
> >>
> >> I agree it would be nice to have cutover to git by then: are we ready
> >> to open an INFRA issue to do the hard cutover?  Or do we still have
> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> >> and everyone else for pushing hard on this front!).
> >
> >
> > We are fairly close - just one last thing to come to consensus on.
> Remains
> > to be seen how fast INFRA reacts for us though.
> >
> > There will also probably be a bit to do as we work through the first
> > release, in terms of release scripts, docs, etc. I think most of it
> should
> > be fairly light weight changes though.
> >
> > - Mark
> > --
> > - Mark
> > about.me/markrmiller
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 release

[Anshum Gupta]

I have a few things I'd like to get in. I hope to get those in by next
week.

I think the 5.5 release is an important one for us as the cleanup in 6.0
depends on it. We shouldn't rush it.

On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:

> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
> LUCENE-6930  and
> LUCENE-6997  which
> changes GeoPoint encoding (boosting performance), and graduates these
> features from sandbox. They should be ready by Monday (or sooner).
>
> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I think we are in good shape now for 6.0.0?
>>
>> git cutover is done and seems to be going well except for how we name
>> branches
>>
>> Dimensional values are renamed to point values, the API is cleaned up
>> a bit, and you can now search for == (not just ranges), and
>> StoredDocument is removed.
>>
>> We should first do a 5.5.0 release to get all the goodness back-ported
>> 5.x features out, and also smoke-test our first git-based release.
>> Does anyone want to volunteer as RM?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>> wrote:
>> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>> >  wrote:
>> >>
>> >> I agree it would be nice to have cutover to git by then: are we ready
>> >> to open an INFRA issue to do the hard cutover?  Or do we still have
>> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>> >> and everyone else for pushing hard on this front!).
>> >
>> >
>> > We are fairly close - just one last thing to come to consensus on.
>> Remains
>> > to be seen how fast INFRA reacts for us though.
>> >
>> > There will also probably be a bit to do as we work through the first
>> > release, in terms of release scripts, docs, etc. I think most of it
>> should
>> > be fairly light weight changes though.
>> >
>> > - Mark
>> > --
>> > - Mark
>> > about.me/markrmiller
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>


-- 
Anshum Gupta

Re: Lucene/Solr 6.0.0 release

[Michael McCandless]

I don't think we should hold the major release for lots of new large
features that are not even started yet; they can just as easily be
done in a 6.x release.

Remember the counterbalance here is major new features that are done
(as far as we know!), yet not readily available to users.  And moving
away from Java 7, and lightning our back-compat burden.

At some point soonish (a week or two) I'd like to cut the 6.x branch.

I agree it would be nice to have cutover to git by then: are we ready
to open an INFRA issue to do the hard cutover?  Or do we still have
things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
and everyone else for pushing hard on this front!).

I don't think we need an umbrella Jira issue to track this ... let's
just mark the issues as 6.0 Fix Version (I just added 6.0 to Lucene
and Solr Jira).

I'll open an issue and work on removing StorableField from trunk, and
another for DimensionalTermQuery.

Mike McCandless

http://blog.mikemccandless.com


On Fri, Jan 8, 2016 at 11:45 AM, Jack Krupansky
 wrote:
> +1 for a 5.x deprecation release so 6.0 can remove old stuff.
>
> +1 for a git-based release
>
> +1 for at least 3 months for people to finish and stabilize work in progress
> - April to July seems like the right window to target
>
> -- Jack Krupansky
>
> On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
> wrote:
>>
>> +1 to that ! Do you have a planned timeline for this?
>>
>> I would want some time to clean up code and also have a deprecation
>> release (5.5 or 5.6) out so we don't have to carry all the cruft through the
>> 6x series.
>>
>> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless
>>  wrote:
>>>
>>> I think we should get the ball rolling for our next major release
>>> (6.0.0)?
>>>
>>> E.g., dimensional values is a big new feature for 6.x, and I think
>>> it's nearly ready except maybe fixing up the API so it's easier for
>>> the 1D case.
>>>
>>> I think we should maybe remove StorableField before releasing?  I.e.,
>>> go back to what we have in 5.x.  This change also caused challenges in
>>> the 5.0 release, and we just kicked the can down the road, but I think
>>> now we should just kick the can off the road...
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>
>

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

Re: Lucene/Solr 6.0.0 release

[Joel Bernstein]

I agree completely with this approach. There's always another release right
around the corner. There's some nice features waiting in trunk.

+1 moving forward fairly soon.
+1 to 6.0 being the git release if possible.

Joel Bernstein
http://joelsolr.blogspot.com/

On Fri, Jan 8, 2016 at 2:51 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I don't think we should hold the major release for lots of new large
> features that are not even started yet; they can just as easily be
> done in a 6.x release.
>
> Remember the counterbalance here is major new features that are done
> (as far as we know!), yet not readily available to users.  And moving
> away from Java 7, and lightning our back-compat burden.
>
> At some point soonish (a week or two) I'd like to cut the 6.x branch.
>
> I agree it would be nice to have cutover to git by then: are we ready
> to open an INFRA issue to do the hard cutover?  Or do we still have
> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> and everyone else for pushing hard on this front!).
>
> I don't think we need an umbrella Jira issue to track this ... let's
> just mark the issues as 6.0 Fix Version (I just added 6.0 to Lucene
> and Solr Jira).
>
> I'll open an issue and work on removing StorableField from trunk, and
> another for DimensionalTermQuery.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Fri, Jan 8, 2016 at 11:45 AM, Jack Krupansky
>  wrote:
> > +1 for a 5.x deprecation release so 6.0 can remove old stuff.
> >
> > +1 for a git-based release
> >
> > +1 for at least 3 months for people to finish and stabilize work in
> progress
> > - April to July seems like the right window to target
> >
> > -- Jack Krupansky
> >
> > On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
> > wrote:
> >>
> >> +1 to that ! Do you have a planned timeline for this?
> >>
> >> I would want some time to clean up code and also have a deprecation
> >> release (5.5 or 5.6) out so we don't have to carry all the cruft
> through the
> >> 6x series.
> >>
> >> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless
> >>  wrote:
> >>>
> >>> I think we should get the ball rolling for our next major release
> >>> (6.0.0)?
> >>>
> >>> E.g., dimensional values is a big new feature for 6.x, and I think
> >>> it's nearly ready except maybe fixing up the API so it's easier for
> >>> the 1D case.
> >>>
> >>> I think we should maybe remove StorableField before releasing?  I.e.,
> >>> go back to what we have in 5.x.  This change also caused challenges in
> >>> the 5.0 release, and we just kicked the can down the road, but I think
> >>> now we should just kick the can off the road...
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Anshum Gupta
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 release

[Mark Miller]

On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless 
wrote:

> I agree it would be nice to have cutover to git by then: are we ready
> to open an INFRA issue to do the hard cutover?  Or do we still have
> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> and everyone else for pushing hard on this front!).
>

We are fairly close - just one last thing to come to consensus on. Remains
to be seen how fast INFRA reacts for us though.

There will also probably be a bit to do as we work through the first
release, in terms of release scripts, docs, etc. I think most of it should
be fairly light weight changes though.

- Mark
-- 
- Mark
about.me/markrmiller

Re: Lucene/Solr 6.0.0 release

[Upayavira]

I'd like to see some visible improvements to the Solr UI before then.
Notably a "nodes" pane and a couple of others, so a timescale of "a few
months" would be great.

Upayavira

On Fri, Jan 8, 2016, at 02:34 PM, Noble Paul wrote:
> deprecating old API is not yet planned. both will co-exist.
> 
> 
> On Fri, Jan 8, 2016 at 7:33 PM, Jan Høydahl 
> wrote:
> > +1 for getting the ball rolling and decide a date for branch cutting...
> >
> > Regarding /v2/ api, isn’t the plan that the new api will co-exist with the 
> > old for some time?
> > If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old 
> > api in 6.y?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
> >>
> >> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 
> >> 6.0
> >>
> >> it is at least 2-3 months away. If the release is planned after
> >> march I would like to get that in.
> >>
> >> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>  I think we should get the ball rolling for our next major release 
>  (6.0.0)?
> >>>
> >>> I'd love it to be the first git-based release. :)
> >>> It'd be a nice milestone change (from infrastructural point of view).
> >>> Not a blocker, of course.
> >>>
> >>> Dawid
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> -
> >> Noble Paul
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

Re: Lucene/Solr 6.0.0 release

[Anshum Gupta]

+1 to that ! Do you have a planned timeline for this?

I would want some time to clean up code and also have a deprecation release
(5.5 or 5.6) out so we don't have to carry all the cruft through the 6x
series.

On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I think we should get the ball rolling for our next major release (6.0.0)?
>
> E.g., dimensional values is a big new feature for 6.x, and I think
> it's nearly ready except maybe fixing up the API so it's easier for
> the 1D case.
>
> I think we should maybe remove StorableField before releasing?  I.e.,
> go back to what we have in 5.x.  This change also caused challenges in
> the 5.0 release, and we just kicked the can down the road, but I think
> now we should just kick the can off the road...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

Re: Lucene/Solr 6.0.0 release

[Noble Paul]

deprecating old API is not yet planned. both will co-exist.


On Fri, Jan 8, 2016 at 7:33 PM, Jan Høydahl  wrote:
> +1 for getting the ball rolling and decide a date for branch cutting...
>
> Regarding /v2/ api, isn’t the plan that the new api will co-exist with the 
> old for some time?
> If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old 
> api in 6.y?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
>>
>> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0
>>
>> it is at least 2-3 months away. If the release is planned after
>> march I would like to get that in.
>>
>> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
 I think we should get the ball rolling for our next major release (6.0.0)?
>>>
>>> I'd love it to be the first git-based release. :)
>>> It'd be a nice milestone change (from infrastructural point of view).
>>> Not a blocker, of course.
>>>
>>> Dawid
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
-
Noble Paul

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

Re: Lucene/Solr 6.0.0 release

[Jan Høydahl]

+1 for getting the ball rolling and decide a date for branch cutting...

Regarding /v2/ api, isn’t the plan that the new api will co-exist with the old 
for some time?
If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old api 
in 6.y?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
> 
> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0
> 
> it is at least 2-3 months away. If the release is planned after
> march I would like to get that in.
> 
> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>>> I think we should get the ball rolling for our next major release (6.0.0)?
>> 
>> I'd love it to be the first git-based release. :)
>> It'd be a nice milestone change (from infrastructural point of view).
>> Not a blocker, of course.
>> 
>> Dawid
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene/Solr 6.0.0 release

[Noble Paul]

I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0

 it is at least 2-3 months away. If the release is planned after
march I would like to get that in.

On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>> I think we should get the ball rolling for our next major release (6.0.0)?
>
> I'd love it to be the first git-based release. :)
> It'd be a nice milestone change (from infrastructural point of view).
> Not a blocker, of course.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
-
Noble Paul

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

Re: Lucene/Solr 6.0.0 release

[Shawn Heisey]

On 1/8/2016 8:13 AM, Shawn Heisey wrote:
> I've only been paying attention to commits for one new major release, so
> I can offer some info on 5.0, but not any of the previous major releases.
> 
> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
> 2015/02/20.  That's five months from new branch to new major release.

Turns out I *do* have information in my email history for 4.x.  Robert
created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
2012/10/12 -- four and a half months later.

Thanks,
Shawn


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

Re: Lucene/Solr 6.0.0 release

[Erick Erickson]

What do people thing about waiting to cut the branch until someone has
something that shouldn't go into 6.0? Committing will be easier that
way.

No biggie, maybe Mike's purpose is served by the notice "get your
stuff in trunk that you want to go in 6.0 Real Soon Now" ;)

As always, since I'm not volunteering to be the RM, I'll be happy with
whatever people decide

On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
> On 1/8/2016 8:13 AM, Shawn Heisey wrote:
>> I've only been paying attention to commits for one new major release, so
>> I can offer some info on 5.0, but not any of the previous major releases.
>>
>> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
>> 2015/02/20.  That's five months from new branch to new major release.
>
> Turns out I *do* have information in my email history for 4.x.  Robert
> created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
> 2012/10/12 -- four and a half months later.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 release

[Ishan Chattopadhyaya]

Couple of items that I am working on that I would like to see in 6.0:
SOLR-5944: Updatable DocValues in Solr
SOLR-8396: Using Dimensional values in Solr

The first one needs some more tests, maybe some refactoring and reviews.
The second one requires some dev work, it is at a very early stage. I think
(please correct me if I'm wrong) we should have dimensional fields in for
Solr 6.0 since the regular numeric fields are now deprecated and
dimensional fields are the way forward.

Regards,
Ishan


On Fri, Jan 8, 2016 at 9:41 PM, Erick Erickson 
wrote:

> What do people thing about waiting to cut the branch until someone has
> something that shouldn't go into 6.0? Committing will be easier that
> way.
>
> No biggie, maybe Mike's purpose is served by the notice "get your
> stuff in trunk that you want to go in 6.0 Real Soon Now" ;)
>
> As always, since I'm not volunteering to be the RM, I'll be happy with
> whatever people decide
>
> On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
> > On 1/8/2016 8:13 AM, Shawn Heisey wrote:
> >> I've only been paying attention to commits for one new major release, so
> >> I can offer some info on 5.0, but not any of the previous major
> releases.
> >>
> >> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
> >> 2015/02/20.  That's five months from new branch to new major release.
> >
> > Turns out I *do* have information in my email history for 4.x.  Robert
> > created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
> > 2012/10/12 -- four and a half months later.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 release

[Erick Erickson]

OK, does this sound like an umbrella JIRA (maybe one for Lucene and
one for Solr) for "Things to add for 6.0" to anybody else as a way of
organizing?

On Fri, Jan 8, 2016 at 8:21 AM, Ishan Chattopadhyaya
 wrote:
> Couple of items that I am working on that I would like to see in 6.0:
> SOLR-5944: Updatable DocValues in Solr
> SOLR-8396: Using Dimensional values in Solr
>
> The first one needs some more tests, maybe some refactoring and reviews.
> The second one requires some dev work, it is at a very early stage. I think
> (please correct me if I'm wrong) we should have dimensional fields in for
> Solr 6.0 since the regular numeric fields are now deprecated and dimensional
> fields are the way forward.
>
> Regards,
> Ishan
>
>
> On Fri, Jan 8, 2016 at 9:41 PM, Erick Erickson 
> wrote:
>>
>> What do people thing about waiting to cut the branch until someone has
>> something that shouldn't go into 6.0? Committing will be easier that
>> way.
>>
>> No biggie, maybe Mike's purpose is served by the notice "get your
>> stuff in trunk that you want to go in 6.0 Real Soon Now" ;)
>>
>> As always, since I'm not volunteering to be the RM, I'll be happy with
>> whatever people decide
>>
>> On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
>> > On 1/8/2016 8:13 AM, Shawn Heisey wrote:
>> >> I've only been paying attention to commits for one new major release,
>> >> so
>> >> I can offer some info on 5.0, but not any of the previous major
>> >> releases.
>> >>
>> >> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
>> >> 2015/02/20.  That's five months from new branch to new major release.
>> >
>> > Turns out I *do* have information in my email history for 4.x.  Robert
>> > created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
>> > 2012/10/12 -- four and a half months later.
>> >
>> > Thanks,
>> > Shawn
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: Lucene/Solr 6.0.0 release

[Shawn Heisey]

On 1/8/2016 7:52 AM, Upayavira wrote:
> I'd like to see some visible improvements to the Solr UI before then.
> Notably a "nodes" pane and a couple of others, so a timescale of "a few
> months" would be great.

I've only been paying attention to commits for one new major release, so
I can offer some info on 5.0, but not any of the previous major releases.

Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
2015/02/20.  That's five months from new branch to new major release.

I do not know if that is typical, but I bet it is.  Prepping a new major
release takes quite a while.  You'll likely have all the time you need
to get your UI changes in.

Thanks,
Shawn


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

Re: Lucene/Solr 6.0.0 release

[Jack Krupansky]

+1 for a 5.x deprecation release so 6.0 can remove old stuff.

+1 for a git-based release

+1 for at least 3 months for people to finish and stabilize work in
progress - April to July seems like the right window to target

-- Jack Krupansky

On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
wrote:

> +1 to that ! Do you have a planned timeline for this?
>
> I would want some time to clean up code and also have a deprecation
> release (5.5 or 5.6) out so we don't have to carry all the cruft through
> the 6x series.
>
> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I think we should get the ball rolling for our next major release (6.0.0)?
>>
>> E.g., dimensional values is a big new feature for 6.x, and I think
>> it's nearly ready except maybe fixing up the API so it's easier for
>> the 1D case.
>>
>> I think we should maybe remove StorableField before releasing?  I.e.,
>> go back to what we have in 5.x.  This change also caused challenges in
>> the 5.0 release, and we just kicked the can down the road, but I think
>> now we should just kick the can off the road...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>

Re: Lucene/Solr 6.0.0 release

[Erick Erickson]

Some Solr stuff in 6.x that I'm familiar with:

ParallelSQL and Cross Data Center Replication

These seem like major hunks of functionality as well, so maybe it's time.

So what kind of straw-man date are you thinking? Not trying to pin
anything down, just thinking about setting priorities

Plus dropping support for Java 7...







On Thu, Jan 7, 2016 at 3:07 PM, Michael McCandless
 wrote:
> I think we should get the ball rolling for our next major release (6.0.0)?
>
> E.g., dimensional values is a big new feature for 6.x, and I think
> it's nearly ready except maybe fixing up the API so it's easier for
> the 1D case.
>
> I think we should maybe remove StorableField before releasing?  I.e.,
> go back to what we have in 5.x.  This change also caused challenges in
> the 5.0 release, and we just kicked the can down the road, but I think
> now we should just kick the can off the road...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Lucene/Solr 6.0.0 release

[Dawid Weiss]

> I think we should get the ball rolling for our next major release (6.0.0)?

I'd love it to be the first git-based release. :)
It'd be a nice milestone change (from infrastructural point of view).
Not a blocker, of course.

Dawid

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