You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "david.w.smiley@gmail.com" <da...@gmail.com> on 2016/03/01 06:01:19 UTC
Re: Lucene/Solr 6.0.0 Release Branch
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 <nk...@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 <uw...@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: uwe@thetaphi.de
>>
>>
>>
>> *From:* Nicholas Knize [mailto:nknize@gmail.com]
>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>> *To:* Lucene/Solr dev <de...@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
Posted by Nicholas Knize <nk...@gmail.com>.
Thanks Uwe!
On Wed, Mar 2, 2016 at 3:18 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Will do that!
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: uwe@thetaphi.de
>
>
>
> *From:* Nicholas Knize [mailto:nknize@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 <nk...@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.smiley@gmail.com <
> david.w.smiley@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* Nicholas Knize [mailto:nknize@gmail.com <nk...@gmail.com>]
> *Sent:* Wednesday, February 24, 2016 9:23 PM
> *To:* Lucene/Solr dev <de...@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
Posted by Uwe Schindler <uw...@thetaphi.de>.
Will do that!
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
<http://www.thetaphi.de/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: Nicholas Knize [mailto:nknize@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 <nknize@gmail.com <ma...@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.smiley@gmail.com <ma...@gmail.com> <david.w.smiley@gmail.com <ma...@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 < <ma...@gmail.com> nknize@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 < <ma...@thetaphi.de> uwe@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: <ma...@thetaphi.de> uwe@thetaphi.de
From: Nicholas Knize [ <ma...@gmail.com> mailto:nknize@gmail.com]
Sent: Wednesday, February 24, 2016 9:23 PM
To: Lucene/Solr dev < <ma...@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
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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 <gu...@gmail.com> 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
> <sh...@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 <al...@flax.co.uk> 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
>> > <lu...@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 <nk...@gmail.com>
>> >> 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 <nk...@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.smiley@gmail.com
>> >> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
>> >> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
>> >> >>>>> To: Lucene/Solr dev <de...@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
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> http://www.the111shift.com
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Gus Heck <gu...@gmail.com>.
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 <
shalinmangar@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 <al...@flax.co.uk> 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
> > <lu...@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 <nk...@gmail.com>
> 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 <nk...@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.smiley@gmail.com
> >> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
> >> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
> >> >>>>> To: Lucene/Solr dev <de...@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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
http://www.the111shift.com
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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
<sh...@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 <al...@flax.co.uk> 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
>> <lu...@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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
>>> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
>>> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
>>> >>>>> To: Lucene/Solr dev <de...@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
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
+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 <al...@flax.co.uk> 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
> <lu...@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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
>> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
>> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
>> >>>>> To: Lucene/Solr dev <de...@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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
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 <sh...@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 <rcmuir@gmail.com
> <javascript:;>> 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
> > <shalinmangar@gmail.com <javascript:;>> 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 <apache@elyograg.org
> <javascript:;>> 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-unsubscribe@lucene.apache.org
> <javascript:;>
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> <javascript:;>
> >>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <javascript:;>
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> <javascript:;>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@lucene.apache.org
> <javascript:;>
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@lucene.apache.org <javascript:;>
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Dawid Weiss <da...@gmail.com>.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Mar 3, 2016 at 11:30 AM, Shalin Shekhar Mangar
<sh...@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Mark Miller <ma...@gmail.com>.
Officially, nothing is required from a release manager and an RM has no
power beyond any other individual. It's only individual opinions that have
said otherwise. If an RM seems to be absent, best to address them directly,
everyone misses things. Apache works at a pace of days, not hours.
Let's all just be extra understanding and constructive and avoid the
alternative of competing release candidates or releases.
Mark
--
- Mark
about.me/markrmiller
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Anshum Gupta <an...@anshumgupta.net>.
Sure, I will. Thanks !
On Thu, Mar 3, 2016 at 11:20 AM, Nicholas Knize <nk...@gmail.com> 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 <an...@anshumgupta.net>
> 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 <nk...@gmail.com> 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 <sa...@gmail.com> wrote:
>>>
>>>> First, Nick, thanks for your RM work.
>>>>
>>>> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize <nk...@gmail.com> 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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>
--
Anshum Gupta
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
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 <an...@anshumgupta.net> 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 <nk...@gmail.com> 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 <sa...@gmail.com> wrote:
>>
>>> First, Nick, thanks for your RM work.
>>>
>>> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize <nk...@gmail.com> 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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>
>
> --
> Anshum Gupta
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Anshum Gupta <an...@anshumgupta.net>.
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 <nk...@gmail.com> 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 <sa...@gmail.com> wrote:
>
>> First, Nick, thanks for your RM work.
>>
>> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize <nk...@gmail.com> 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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
--
Anshum Gupta
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
> 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 <sa...@gmail.com> wrote:
> First, Nick, thanks for your RM work.
>
> > On Mar 3, 2016, at 12:53 PM, Nicholas Knize <nk...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Steve Rowe <sa...@gmail.com>.
First, Nick, thanks for your RM work.
> On Mar 3, 2016, at 12:53 PM, Nicholas Knize <nk...@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
> 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 <
shalinmangar@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
> <lu...@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
> > <sh...@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 <rc...@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
> >>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Shalin Shekhar Mangar.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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
<lu...@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
> <sh...@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 <rc...@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
>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Shalin Shekhar Mangar.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
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
<sh...@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 <rc...@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
>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Anshum Gupta <an...@anshumgupta.net>.
> 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 <sa...@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 <uw...@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: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Shalin Shekhar Mangar [mailto:shalinmangar@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
> >> <sh...@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 <rc...@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
> >>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Regards,
> >>>>> Shalin Shekhar Mangar.
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Shalin Shekhar Mangar.
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anshum Gupta
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Mar 3, 2016 at 10:48 AM, Steve Rowe <sa...@gmail.com> wrote:
> Feature freeze for a release should not block development.
+1
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Steve Rowe <sa...@gmail.com>.
-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 <uw...@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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Shalin Shekhar Mangar [mailto:shalinmangar@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
>> <sh...@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 <rc...@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
>>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Shalin Shekhar Mangar.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Lucene/Solr 6.0.0 Release Branch
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Shalin Shekhar Mangar [mailto:shalinmangar@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
> <sh...@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 <rc...@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
> >> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Shalin Shekhar Mangar.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Dawid Weiss <da...@gmail.com>.
I wouldn't read so, to be honest. This isn't so convoluted:
https://git-scm.com/docs/git-diff
Quote:
git diff [--options] <commit> <commit> [--] [<path>…]
This is to view the changes between two arbitrary <commit>.
git diff [--options] <commit>..<commit> [--] [<path>…]
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 <sa...@gmail.com> wrote:
> Nearly all of my git knowledge is from possibly wrongheaded stack overflow posts - in this case <http://stackoverflow.com/questions/9834689/comparing-two-branches-in-git> 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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Steve Rowe <sa...@gmail.com>.
Nearly all of my git knowledge is from possibly wrongheaded stack overflow posts - in this case <http://stackoverflow.com/questions/9834689/comparing-two-branches-in-git> 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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Dawid Weiss <da...@gmail.com>.
> (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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Steve Rowe <sa...@gmail.com>.
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 <sa...@gmail.com> wrote:
>
> Shalin, I will take a look.
>
> --
> Steve
> www.lucidworks.com
>
>> On Mar 3, 2016, at 10:25 AM, Shalin Shekhar Mangar <sh...@gmail.com> 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
>> <sh...@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 <rc...@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
>>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Shalin Shekhar Mangar.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Steve Rowe <sa...@gmail.com>.
Shalin, I will take a look.
--
Steve
www.lucidworks.com
> On Mar 3, 2016, at 10:25 AM, Shalin Shekhar Mangar <sh...@gmail.com> 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
> <sh...@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 <rc...@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
>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Shalin Shekhar Mangar.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Mar 3, 2016 at 10:58 AM, Robert Muir <rc...@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
> 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 <rc...@gmail.com> 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
> <sh...@gmail.com> 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
>> <sh...@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 <rc...@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
>>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Shalin Shekhar Mangar.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Robert Muir <rc...@gmail.com>.
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
<sh...@gmail.com> 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
> <sh...@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 <rc...@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
>>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Shalin Shekhar Mangar.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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
<sh...@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 <rc...@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
>> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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 <rc...@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
> <sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Robert Muir <rc...@gmail.com>.
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
<sh...@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 <ap...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
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 <ap...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Shawn Heisey <ap...@elyograg.org>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Alan Woodward <al...@flax.co.uk>.
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 <lu...@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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
> >>>>> To: Lucene/Solr dev <de...@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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
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 <
lucene@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 <nk...@gmail.com> 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
> > <lu...@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 <nk...@gmail.com>
> 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 <nk...@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.smiley@gmail.com
> >> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
> >> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
> >> >>>>> To: Lucene/Solr dev <de...@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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <nk...@gmail.com> 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
> <lu...@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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
>> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
>> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
>> >>>>> To: Lucene/Solr dev <de...@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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
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 <
lucene@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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
> >> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
> >>>>> Sent: Wednesday, February 24, 2016 9:23 PM
> >>>>> To: Lucene/Solr dev <de...@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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <nk...@gmail.com> 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 <nk...@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.smiley@gmail.com
>> <da...@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>>>>>
>>>>>
>>>>>
>>>>> From: Nicholas Knize [mailto:nknize@gmail.com]
>>>>> Sent: Wednesday, February 24, 2016 9:23 PM
>>>>> To: Lucene/Solr dev <de...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene/Solr 6.0.0 Release Branch
Posted by Nicholas Knize <nk...@gmail.com>.
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 <nk...@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.smiley@gmail.com <
> david.w.smiley@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 <nk...@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 <uw...@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: uwe@thetaphi.de
>>>>
>>>>
>>>>
>>>> *From:* Nicholas Knize [mailto:nknize@gmail.com]
>>>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>>>> *To:* Lucene/Solr dev <de...@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
Posted by Nicholas Knize <nk...@gmail.com>.
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.smiley@gmail.com <
david.w.smiley@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 <nknize@gmail.com
> <javascript:_e(%7B%7D,'cvml','nknize@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 <uwe@thetaphi.de
>> <javascript:_e(%7B%7D,'cvml','uwe@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: uwe@thetaphi.de
>>>
>>>
>>>
>>> *From:* Nicholas Knize [mailto:nknize@gmail.com]
>>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>>> *To:* Lucene/Solr dev <de...@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
>